UX Design in 14 Simple Steps
A Tweetstorm expanded.
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.
On Twitter, Jonathan goes by the handle @miniver, and he can occasionally be goaded into tweeting out his wisdom, as happened recently when a correspondent asked him what he would say to a bunch of 19-year-olds who wanted to learn user experience design.
The original thread can be seen here, where Jonathan recorded it in its entirety. His answers intrigued me but — as can be expected in the 140-character universe of Twitter — they were altogether too short. In this blogpost, I will attempt to expand on his 14 tips. My take on his posts may deviate from his original intent somewhat, but that is the nature of our profession and our process. However, I’ve asked Jonathan to review my work, so nothing I say contradicts it directly.
Step 1: “Find out as much as you can about your users and their goals, needs, capacities, relationships, and other circumstances.”
There’s a lot of goodness packed into this one, and that’s not surprising, as every other step will build on the results of this one. Because of that, it must be Step 1 and cannot be delayed or postponed. Some smart person once said, “If I have 9 hours to find a solution, I’ll spend the first 8 studying the problem.” This is the part where you study the problem.
UX design is all about problem solving, so identifying the problem accurately is vital to success. You cannot afford to be vague about this step, nor can you afford to be slipshod or eyewash.
The users define your solution, so pay attention to them first and foremost. Note especially that it says “find out” and does not say “assume.” You cannot perform this step adequately unless you get out of your office and observe actual (or potential) users in their natural setting.
User’s goals are critical. There are two ways to understand goals: (1) You can think of them as desired end states. Where does the user wish to be at the end? (2) Alternatively, or better yet, you can think of goals as motivations. Why does the user want to use your product/service/website/app?
Capacities actually has multiple definitions. Is this a website that will be accessed 10,000 times a day or 10,000,000? It makes a difference in how you prioritize things. Capacities also refers to the experience and situation of the user. Will they be using your product while they are driving a car, at a dining table with friends, or at a desk with a computer and screen? Jonathan says:
“The user’s capacities also includes knowledge and skills, particularly around software tools. Too many people in tech oversimplify this to stereotypes like “grandma” and “tech-savvy early adopters.” Real users have weirdly-shaped skills, like the admin assistant who just saves everything in their top-level Documents directory…but can also make an MSWord mail merge sing and dance.”
Relationships is interesting, because all of your users are humans and their ties to their colleagues and the work at hand affects how they feel about their interactions. How does it affect how they share information with their friends and co-workers? Notice how far away from functions and features we are?
Step 2: “Name what you know about your users as clearly, vividly, and succinctly as you can.”
Nomenclature is vitally important for assuring mutual understanding in any group activity and software design and development is assuredly dependent on a group. It doesn’t matter if your names are cute, goofy, or representational. Nobody laughs when you say you need to Google something, even though it’s actually very silly. Silly names are okay, because usage will give them heft and meaning over time. What matters is that everything be named, otherwise you will be hampered when you try to design for it.
The act of naming is the act of taxonomy: identifying and determining the unique characteristics of things, and what properties they do or don’t have. A key notion here is to stay high level. Details won’t help you; screen images are too detailed. At this point, you need to be thinking in terms of basic knowledge and action: “What does the user need to know?” “What do they need to do?” “What do they know now?” and “How do they learn it?”
Notice that Steps 1 and 2 can take place concurrently.
At Cooper, we create personas at this critical step and use them throughout the remaining steps. Personas are the handle you use to grab hold of what you learned from your research. They humanize the context, background, and motivations of your users.
Step 3: “Tell the story of the tool you want to give your users with the crudest pictures you can.”
I asked Jonathan to unpack this tweet a bit more and he said,
“I conceive of the systems we design as tools in service of extending a user’s abilities. Of course you want elegance and beauty, but the driving definition of the system is how it makes the user effective.”
“The kind of story you use depends on the nature of the system. It could be a usage narrative (like “day in the life” scenarios) or it could be a functional anatomy (like saying that Outlook has an email view, a calendar view, and a contacts view, but displays meeting notifications together with emails). Or it could be a high-level walkthrough of some key IxD behaviors (like Steve Jobs demo’ing how receiving a call on the iPhone automagically paused your music, then resumed it when the call ended) or a mix of these.”
By “crudest pictures,” Jonathan meant a metaphoric picture, but agreed it should also contain illustrations. My preference would be for simple diagrams showing the structure of the solution and the flow of usage and data within it.
There is great power in a simple, primitive diagram. Study the works of sketchnote artists or the writings of Sunni Brown and Dave Gray. Use simple block diagrams to show how the user will see things, assess them, make decisions, take actions, and then see the results of those actions.
Step 4: “Set aside the results of Step 3 where you can’t see them. Repeat Step 3. Try to make it better this time.”
Design is an iterative process. You will do it over and over again until you get it right. That’s why it’s so important that you work with lightweight tools creating fast, cheap, and easy-to-discard sketches. The instant you open heavyweight tools like Photoshop (or truly any kind of prototyping tool), you begin wrestling with the “Sunk Cost Dilemma Fallacy.”
Jonathan’s instructions to not refer to your previous solution is interesting. It forces you to work the problem again from first principles, which has the beneficial effect of making sure you are not depending on a mistaken assumption that may have crept into your previous working.
Of course, you will always make assumptions at some low level, so this is your opportunity to exercise them and see which ones make sense.
If you find yourself reacting negatively to having to do this task over again, then you might consider pursuing a different line of work. You should be like an actor or athlete who enjoys doing their job over and over again, perfecting it more each time.
Step 5: “Repeat Step 4 until you are saying and drawing the same thing over and over again.”
Here Jonathan is being pedantic to make a point, but it’s an important point and he’s right to emphasize it this way. You should be assaulting the problem over and over until you are certain your solution is the best one. Implied here is that you should try different approaches each time. There is more value in attempting to see the problem from different angles than there is in mere repetition.
Neither Jonathan nor I are big fans of the “test your way to a solution” approach that is popular in many places, but this is a good place to get feedback on your solutions from outsiders. Any solution you have proposed is still lightweight enough to be easy to change, yet detailed enough to communicate.
The user will need to understand what is going on inside the system, so the interaction has be revealing of process. To do this effectively, without drowning the user in details, you should have your head wrapped around exactly what information is necessary, what might be needed, what won’t be needed, and what would be just plain helpful for the user to know.
Your design solution needs to have a method of getting that information visible to the user without making them ask for it. The user will need to know what actions they can take, how to initiate them, what the consequences of starting them will be, and how to extricate themselves from it if it turns out to be a mistake.
Do it over until you get it right. Trust your own judgment and see where you end up.
Step 6: “Try different situations your users might encounter. Start with the common and important ones, [and] work your way to the weird and rare.”
Now that you have found the heart of the beast, you can proceed to finding its other parts. The bulk of the work you should do as a designer is on the daily or frequent use scenarios. The occasional use scenarios get what resources are left over, but every scenario deserves some attention. Here is where you should be inventorying the complete libretto of user tasks and situations.
Jonathan expands his thoughts here,
“One of the bits of Cooper lore that I’ve seen surprise people is how much our scenario descriptions focus on users’ subjectivity. (The X in UX!) Talking about what users do and don’t notice, what they are looking for, what they are trying to do. I always get comments about this when I do a scenario that includes a user making a mistake and then correcting it, which is a classic Cooper scenario move.”
Step 7: “Repeat until your solution is stable, and you have how it all works in your head.”
You need to know this stuff cold. During the process of working out the structure of your solution, the dialog is largely internal, between you and your design partners. The steps that follow will demand that you communicate and defend your design choices; to do that, you must have a deep understanding of how and why they work.
Getting a design to a point where you know it cold means that it has enough conceptual coherence that you hold it in your head without any conscious effort, like muscle memory. It has to become intuitive.
Step 8: “Stop resisting detail. Start resisting structural changes. Repeat repeat repeat, starting from common usage again.”
Finally, you can begin to break down the key scenarios into their digital components. You can begin to examine things at a more granular level. You should define your solutions in greater detail.
When there is any chance of making major structural changes in your proposed solution, you should avoid investing time and effort in detail design. It’s a waste of time to lay out buttons and menus for interactions that may be discarded and replaced. Once your design has achieved stability at a macro level, when your approach has been stressed enough to prove its resilience, it is time to begin blocking out the details of the various interactions. At this stage, more detail makes it better.
Step 9: “Identify 3 stories: Very common usage. The biggest change compared to your user’s life now. What exercises the IxD hard.”
It’s axiomatic that you will not have enough time to design every aspect of a product’s interactions to a satisfactory level. This is partly because you will learn about useful changes to make from deploying a minimal product, but also because businesses are fearful of investing a lot of resources in design.
Regardless of the reason, you need to carefully allocate your time and attention by prioritizing all behavior by how the user will interact with them. The highest priority design jobs are those used most frequently to perform the most important functions. The next priority are those used less frequently, but perform vital functions.
You also need to address the user’s journey from the time they first meet your solution to the time they become a regular user. You need to smooth over any obstacles that might bar their way. These real-world stories directly address the questions that developers and stakeholders will have on their minds.
Step 10: “Work out the specifics of your stories. Make them as realistic and vivid as possible.”
Humans understand the world in terms of narrative, where recognizable human actors traverse an arc of experience and undergo a transformation on the way. You will construct coherent narratives to understand who your user is and what they wish to accomplish. You will solve the user’s problems by positing other narratives showing how your solution aids them on their journey to success. You will generate more narratives to test the validity of your solution, and you will communicate to others the form of your solution through narrative.
Step 11: “Find the fastest possible way to tell each story clearly. And prepare to explain every possible detail in your stories.”
Your colleagues don’t want to repeat your work, they just want to trust that you did your work well and thoroughly. You will convince them of that by telling your story to them briefly, yet standing ready to answer their requests for more detail to demonstrate that you have covered all the possible scenarios. Your colleagues don’t want a long-winded explanation of each tiny facet of how the thing works and your methodology for arriving there.
Step 12: “Tell each story twice: once as fast as possible, once lingering over the details.”
This is complex stuff, and human behavior can be complex and counterintuitive, so set the stage with a brief overview. Once your audience has a skeleton of the plan, they can hang muscles and organs onto it as you flesh out the story.
Step 13: “Answer developers’ questions. Write down as much as you can, but being responsive & available is more important than thoroughness.”
At the beginning of any project, designers are driving the entire process. The developer’s role is to assist the designer in answering questions of feasibility and relative effort. Once the bigger pieces of the project have been determined, developers can begin their work. As time goes on, and developers begin to focus on more granular parts of the work, they take over the driver’s seat. The designer shifts to a supporting role, answering the developer’s inevitable questions about details of the interaction.
They must be attentive to the developer’s needs, actively listening to their requests, understanding that the issue isn’t closed until the developer says it is, and making sure that no issues are pending.
Once you complete a phase, a cycle, a release, your reward for doing a tough job is that you get to do it again.
Step 14: “Go learn more about your users, and start thinking about the next thing you will do for them …”
Once you complete a phase, a cycle, a release, your reward for doing a tough job is that you get to do it again. The only products that remain unchanged for long are those that are in the crosshairs of upstart competitors.
The good news is that once you have a real product in the hands of a user population, you have the best source possible for gathering high quality empirical knowledge. So, what are you waiting for?
Jonathan Korman’s awesome personal blog can be found here, his many posts on the Cooper Journal are here, and he’s on Twitter as @miniver.
There’s always lots of good, relevant stuff on the Cooper Journal.
