duh moment 2367b

Why do we have to fight so hard to convince clients (and that can include bosses and/or coworkers) […]

Why do we have to fight so hard to convince clients (and that can include bosses and/or coworkers) that we should think about the problem before we start designing the solution? And that we should test out solution while it’s still in a cheap and easy-to-change form (say, paper prototypes) before spending a ton of time and money building the wrong thing?

Reading through Jeff Rubin’s terrific Conceptual Design: Cornerstone of Usability I kept going, “Well, of course. Well, yes, of course.” Sometimes because I’ve been doing user-centered design for a while now and I’m familiar with the techniques, but too often because he was

saying one needs to fight for the right to research the problem, sketch out a few solutions, test a prototype and then start building the product.

Is this a shocking protocol?

1. Study the problem, including the competitors’ solutions.

2. Sketch out a couple of different solutions.

3. Test a rough protype of your solutions with the people who will use the product to see if you have a good solution.

4. Revise the solution based on what you learned.

5. Build a prototype that is close to the finished thing.

6. Test with the people who will use it.

7. Make fixes based on what you learned.

8. Ship the product. Include a feedback devise so you can make the next version even better.

Can anyone read that and find it a revelation? Do we really need to proselytize common sense?

Don’t answer that…


Add Yours
  1. 2

    I have been living the downside of this the past few weeks again. Getting demanded to tell how you would program the to get the information out of a new database and demanded that we did not ever need to worry about the user. I could not believe I was hearing this from a supposed tech veteran with a software development background. There was no way the application was going to get done in time or to scale if we went down the path she was demanding. I was either going to quit or go down the proven development path. I chose to ignore her demands and think, test, design, and develop a prototype that we know will get us the components we need to then work on an interface that we will know the limitations of what can or can not be done.

Comments are closed.