Archive for the ‘methods’ Category

Shepherds of Design

Thursday, October 15th, 2009

Margret Schmidt from Tivo discusses how designers can flourish by taking responsibility for their work while understanding that they are not their designs.

Some highlights:

Designers do not “own” the design
Feedback is not personal
Share early and often
This is NOT design by committee
Build your design gut
Celebrate the design that ships

Kick-off prep

Wednesday, June 17th, 2009

Tomorrow I am kicking off a really large initiative that will be exciting, fast and possibly crazy. Everyone has an opinion, much is based on personal preferences rather than user needs. I’ve set up goals, tasks and milestones, and so far am planning lots of exploration to begin with, followed by lots of user-driven iteration. I’ve also set up checkpoints with the many levels of stakeholders, so that there is at least the appearance of consensus. Deep breath.

Ooh la la prototyping

Monday, June 15th, 2009

Just had a really great conversation with my team about innovation, mental models, navigation and visual hierarchy. What helped spark all this great thinking? An interactive prototype showing three slightly different versions of an idea. The designer worked with a prototyper – it took about a week to turn around, because as it was coded she began to codify the design and work through the interactions. The team topped it all off with an interesting design review where we openly discussed the various model’s successes and failures, what we might change/add, and how we might use the prototypes to sell our idea.

Now this may not seem out of the ordinary for many of you, but our development model here has been not to waste effort, and that means prototype using reusable code. For me, that just defeats the purpose, but changing how things are done is not an easy feat. I am working to sell the idea of prototyping at all levels – from designers and dev to PMs and biz folks. But its slow.

In the past, I’ve been all about prototyping – from quick and dirty paper sketches to throw-away html. Or full-color mocks linked to mimic an interactive experience. Depending on what we were trying to learn of course. We are designing interactive experiences – we need to think about those interactions, and only using mocks/wireframes doesn’t always cut it. We have to think about the entire experience.