Archive - agile ux RSS Feed

Moo Flickr Mini Cards + Getting Real

September 22, 2006 in agile ux,case studies,interaction design,UCD process with 1 Comment

moo cards
Moo Flickr Mini Cards launched recently, as you may have read elsewhere. I’m stoked to see so many people checking them out and enjoying them because I had the pleasure of working with the Moo Team on the design of the service.
It was interesting that Signals vs Noise wrote them up, because the design process that Moo undertook is really quite similar to the Getting Real methodology that the 37 Signals guys espouse.
Moo took a really inclusive and user centric approach to the development of this interface – doing user research and testing in a range of different environments throughout the design and development lifecycle. It’s really great to see that some of the things that we at Flow found when we were working with them are now part of the design – and it’s been great to see the design evolve over time as more and more people got involved in the Moo project.
So, designing, and developing and feedback were locked into a really fast and iterative process – and the end result is a process of selecting, designing and ordering cards that is – I think, and others seem to agree – really easy and enjoyable.
Based on what I know of their ethos and approach, I feel confident that Moo will continue to evolve and improve the interface and user experience of Moo Flickr Mini Cards over time.
It’s been really great working with the guys at Moo because of the responsiveness and user centric approach that they’ve taken to this project. I look forward to seeing how this product evolves and where else Moo shows up – they’re a really smart crew, doing really smart work! Yay Moo! :)
Technorati Tags: , , ,

getting real.. with clients? (can agile methodologies work in agencyland?

March 2, 2006 in agile ux,UCD process,web 2.0 with 4 Comments

37 Signals BackPack Logo

everyone I know who loves agile-type methodologies has three things in common:

  • they work in a small team. Like, less than 10 people. Usually less than 5.
  • they don’t have to do monthly profit reports to management
  • they don’t have (external) clients.

That kind of environment makes it really easy to love a methodology where you don’t have to accurately define the scope of a project (what the client is going to ‘get’ at the end), and where iteration and collaboration is a way of life.

Consequently, over the last 12 months or so I find myself getting into lots of heated discussions with people over the value of functional specifications. The cool kids say that func. specs. are a waste of time, that they are creativity killers, and that there is no place for them in application design and development today.

I love the sound of that. Hell. I’d love to ditch functional specs if I thought it would give a good outcome. I don’t like writing them. Does anyone like writing them?!

But, can my clients cope without documentation? Without bits of paper that they rarely read but that allows them to feel comfortable throughout the development process – makes them feel that there is a process, there is a scope, and that we have it all under control. Tells them what they’re going to get for their money.

(more…)

Page 5 of 5«12345