Old tweetstorms

I used to rant about UX design on Twitter a lot, and of course most of those are lost beneath the waves now. At least a couple worth saving:

Interaction design in 14 simple steps

This old thread has turned up in all kinds of places. Alan Cooper expands on it nicely, and says some nice things about me there.

My long-time Cooper colleague, Jonathan Korman, has worked with me for nearly 20 years. He’s seen as much of the UX world as there is to see from the client side as well as the consulting role: He’s worked for startups and big companies, including Flip Video and Docusign. He is remarkably intelligent and has helped formulate how I think about interaction design, product management, and many other subjects.

Here’s the essential original:

  1. Find out as much as you can about your users and their goals, needs, capacities, relationships, and other circumstances.
  2. Name what you know about your users as clearly, vividly, and succinctly as you can.
  3. Tell the story of the tool you want to give your users with the crudest pictures you can.
  4. Set aside the results of Step 3 where you can’t see them. Repeat Step 3. Try to make it better this time.
  5. Repeat Step 4 until you are saying and drawing the same thing over and over again.
  6. Try different situations your users might encounter. Start with the common and important ones, work your way to the weird and rare.
  7. Repeat until your solution is stable, and you have how it all works in your head.
  8. Stop resisting detail. Start resisting structural changes. Repeat repeat repeat, starting from common usage again.
  9. Identify 3 stories:
    • Very common usage.
    • The biggest change compared to your user’s life now.
    • What exercises the IxD hard.
  10. Work out the specifics of your stories. Make them as realistic and vivid as possible.
  11. Find the fastest possible way to tell each story clearly. And prepare to explain every possible detail in your stories.
  12. Tell each story twice: once as fast as possible, once lingering over the details.
  13. Answer developers’ questions. Write down as much as you can, but being responsive & available is more important than thoroughness.
  14. Go learn more about your users, and start thinking about the next thing you will do for them …

Product & service development in 6 difficult steps

It should be obvious that wherever I talk about “product” I actually mean product, service, or weird centaur tech thing that is part-product-part-service ….

  • The Genesis phase, Step Negative One, is the tricky bit that most organizations don’t talk about. How does the org get to the point where it decides there is a project to be done? Who is involved? What do they think about?
  • The Mandate phase, Step Zero, is where you decide what the question is to which the product is the answer. This includes the business problem for the org and the needs of users & customers. (You knew that users are not the same as customers, right?)
  • The Vision phase is describing the product you want to make clearly enough that everyone is actually talking about the same thing. (Many executives think that coming up with this is their job. It isn’t. Choosing a vision, committing to it, and aligning folks with it is.)
  • The Plan phase is describing the product you want to make clearly enough that you will know if the thing you built is the thing you meant to build. This requires categorically more detail and specificity than the Vision.
  • The Build phase is making the product. One thing that is not obvious: prior to this, the development team serves the design team with answers about what is possible (not easy, possible), but during Build designers serve the development team.
  • The Refine phase is when you have a product in users’ hands and can learn from which of your design predictions came true and which were wrong. As Josh Seiden says, every product is a hypothesis you are testing, and you are sure to be surprised.

One political problem with talking about phases of design + development is that the organizational time and energy devoted to each phase is not equal, but naming a phase hints that it is. Early phases demand modest resources but are disproportionately important to get right.

Agile software culture at its worst imagines that if you just get really good at Build & Refine you don’t need to worry about the earlier phases of design + development. But those phases ALWAYS happen, even if only implicitly, and if you ignore them they happen badly.