Eivind

It's better to be roughly right, than precisely wrong.

User requirements usually are just raw data that describes a symptom or a limited solution. Therefore they should be translated into need statements.

5 Guidelines for writing need statements:
1. "What" not "How" <= Translate the solutions to problems
2. Specificity <= Specify the problem
3. Positive not negative phrasing <= Conditions of satisfaction
4. An attribute of the product
5. Avoid "must" and "should" words

Next steps:
• Design some concepts and force them to prove its value
• Code the winner(s)

February 2010 Permalink Filed under prototyping, modelling, design

The innovator's DNA

Five “discovery skills” separate true innovators from the rest of us.

The Innovator (1) talks with 10 people—including an engineer, a musician, a stay-at-home dad, and a designer—about the venture, (2) visits three innovative start-ups to observe what they do, (3) samples five “new to the market” products, (4) shows a prototype he’s built to five people, and (5) asks the questions “What if I tried this?” and “Why do you do that?” at least 10 times each day during these networking, observing, and experimenting activities.

Reference: Harvard Business Review

December 2009 Permalink Filed under innovation, design, process

When asking questions, be prepared for obvious answers.

If I'd asked my customers what they wanted, they'd have said a faster horse.
-Henry Ford

You cannot only ask the right questions, you have to ask them the right way as well.

Reference: Wikiquote and somewhere in dialog.

Permalink Filed under planning, productivity, innovation, design

Like buildings, applications break at the joins.

It’s the journey between pages or screens, not the pages and screens themselves, that can cause the most problems for users. Plus - problems with the journey are the most expensive problems to fix.

Design the journey between states first, before designing the states.

Reference: 101 things I learned in interaction design school

November 2009 Permalink Filed under design, process, development

Designing with constraints

Design depends largely on constraints. … Here is one of the few effective keys to the design problem—the ability of the designer to recognize as many of the constraints as possible—his willingness and enthusiasm for working within these constraints….

—Charles Eames

UX matters

November 2009 Permalink Filed under design, usability, process

In general, People are stupid.

TOP GOOGLE UK SEARCHES 2009