We can talk about Design Thinking: Empathize, Define, Ideate, Prototype, Test for the uninformed. However, design is more framework and less process. It’s more guideposts, so you have a pretty good idea of where you are going, and adjust when it happens in asynchronous order.

How many times have you gotten to Test and realized you’re solving the wrong problem? It’s called learning. That’s why design thinking it’s is there so that you can back up and start again.

The gates help you have informed point of view, whether it is a start-up project or something that’s been existing for a very long time. The key is to go through the first steps of that process — Empathize and Define — in quick order, so you have a foundation to start.

Here‘s what I answer before designing a single screen.

Who are the users?

Start here: “This is the user, and the problem we are solving for them is…”

Most organizations have a pretty good starting point. Some, like Microsoft, have had personas out there for years and had the muscle memory to use them. For other organizations, especially startups that have lucked into the product-market fit, their personas are a mess. The good news is that personas are never truly finished and may change over time.

If you are designing, it’s always for someone. It’s better to get that someone out in the open so everyone has a common understanding.

Where to start

• Start with provisional personas — a baseline of who the users are so you can revise them based on further research. There’s a lot of places within organizations you can start this research. We always had a Customer Success group that conducted research on users. It doesn’t take long, other than pressing an elevator button.

The artifact

• Personas, at least three of them. They should pre-exist, and you’ve been using them to design. I wrote an article about creating lightweight personas, and don’t worry about them being right. Prioritize learning over correctness.

Estimated time investment

• Less than a day if there are no personas, and 20 minutes if there are. The story always needs to start there.

How are they going to use the feature?

What’s missing from most product development processes is how the users are going to use features within in the context of their environment. Set time duration, other personas or actors that may interact with the product, and what other processes they use. Include offline process, other products, and unforeseen delays.

We did this a lot when at Jobvite: discussing how other products like Microsoft Outlook are used to accomplish the task outside of the application. It was important to understand the hiring process, for example, and how the candidates would go through the workflow.

How important is this? If you ask more users what they want help with most, it’s to save time within in the context of their journey. They want their life to be easier.

Where to start

• Write an implementation-free user scenario. State the steps the user will have to take go through the steps of using the feature, including any details on they solve the problem today. Emphasize personas and business process, and how long it will take. The time element is important because it might mean the difference between designing a step by step wizard and a different asynchronous guided process.

The artifact

• The user scenario, ideally 500 words or less. People hate reading more than a page. A good way to test it is by reading it out loud. It should take 10 minutes to read it. Need an example? Go here.

Estimated time investment

• A good first draft of a user scenario can take less than 4 hours, and there are a lot of good examples to draw from.

Do your products have a similar feature?

The most valuable 30 minutes of this process: Screenshots and URLs of what your product does today. Set the context of not only what the product is, and how your personas use it.

If you are working on an application, you should be familiar how it works, inside and our. Use your product at least a few hours a week.

While your wireframes may be your understanding, everyone else you are working with is living in the product.

Where to start

• Document screen shots, so everyone has context. Other participants (i.e. Product Manager or Engineer) in the design process should also be able to do this. The act of documentation meets two important goals: setting the context and forcing the question, “Does this have a similar intent?” Writing and capturing content is a good thing because it forces thought much more than a verbal conversation.
• In meetings, refer to these documents all the time. Ask, “Is this a pattern we can use to shorten development time and keep a consistent user interface?”

The artifact

• Screenshots. Print them out and tape them to a wall.

Estimated time investment

• You should be able to do this in less than few hours if the Product Managers are around. Sometimes it’s as simple as asking them, “We’re trying to solve this problem. Do any of your features do this today?”

Are there other products that fit the mental model?

The internet isn’t a blue sky thing where everything should be reinvented. There are established mental models users understand intimately.

Product Managers call this competitive analysis. I call this, “Use Google.”

The rule with my teams: Find five products, and talk to five people that may have used a similar product. Takes a day or less, and you get great ideas out of it.

For example:

• Spreadsheets: The first electronic spreadsheet, VisiCalc, was invented in 1979 by software pioneer Dan Bricklin. Some spreadsheet applications date back to the 1960’s. The Excel team followed the mental model of other spreadsheets and just did it better. The pre-existing mental model forms the basis of a lot of other applications, like Google Sheets.
• Shopping Carts: Online shopping dates back to 1979. There are millions of examples. Amazon is a good place to start.
• Classified Websites: Craigslist is the baseline, but I’m sure there’s a cave wall somewhere in the world where someone etched selling an ox for corn to others in the settlement. Before the internet. Before print. Before almost everything.

Even the “new stuff” like Voice UX is not new. An acquaintance of mine, Philip Hunter, works on the Amazon Alexa team. His voice experience for automated systems predates Alexa by 20 years, and he holds patents in the field. It’s a pretty good guess he’s not making stuff up.

There are often barriers to finding examples in your domain. Our competitor’s software requires a significant purchase, which means we regularly don’t have access to competitors. So we look to other categories for the best ideas. If you understand that your users are using all kind of other applications, you can design something that’s familiar and fits their needs.

So now you know you don’t have permission to reinvent the wheel — invented in 3500 B.C. — let’s get to work.

Where to start

• Use the same process you performed for your existing product. Find five or so other products that do the same thing and do your research. Admit that you’re stealing ideas and question their context. Use them as a baseline.
• Put them in a document that everyone can access. Even better, post the screen shots on the wall in a hallway. You’ll involve more people in the design process, and they’ll suggest other “like” applications.

Artifact

• A document containing screenshots. Print them out and tape them to a wall.

Estimated time investment

• A day or less. Use Google Image Search.

Conclusion

The elements of this research are simple:

• Understand the user
• Understand environmental context
• Understanding existing tools, internal and external

They’re essential for starting any design process, but they can be done quickly and efficiently within the constraints of your environments.

The time investment you need to make before starting up a wireframe tool like Axure — i.e. doing a bit of guerilla research that sometimes involves not talking to users — is important.

Yes, during your user research you’ll uncover other applications that they use, but if you this, you’ll have a good baseline to start from, which is more than most products have.

Recommended Books

• How To Make Sense Of Any Mess
• Mental Models: Aligning Design Strategy with Human Behavior
• Writing Effective Use Cases