What To Answer Before Designing Anything
Usability CountsUsability Counts
We can talk about Design Thinking and the five step process all we want: Stanford’s DSchool’s Emphasize, Define, Ideate, Prototype, Test for the uninformed. The reality is that design is more of a framework and less of process. It is a set of guideposts so you have a pretty good idea of where you going, and adjust when it happens in asynchronous order.
Seriously, how many times have you gotten to Test and realized you’re solving the wrong problem? That’s why the process is there, so you can back up the truck and design again. That is called iteration.
These 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, Emphasize and Define in fairly quick order. This way you have a foundation to start from. I start every conversation there before we talk about anything else.
Here are things I answer before designing a single screen.
Who are the users?
At the very start (and continuously during the project), always say this: “This is the user, this is the problem we are solving for them.” Avoid I think’s or I feel’s, and turn it into this statement. It has to be stakeholder free.
Most organizations have a pretty good starting point here. Some, like Microsoft, have had personas out there for years and have the muscle memory to use them. For other organizations, especially startups that have lucked into 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
- You should at least have a set a 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. Where I work at now and in previous organizations, we had a Customer Success group that’s a wonderful place to conduct research on users. It doesn’t take long to at least start the process, other than pressing the elevator button.
The Artifact
- Personas, at least three of them. Hopefully they’re already written at least six months before you read this article and you’ve been using them to design. I wrote an article about creating lightweight personas, and don’t worry about them being right. Think in terms of learning versus correctness.
Estimated time investment
- Less than a day if there are no personas, and 20 minutes if there are. The story always needs to starts there.
How are they going to use the feature?
What I see missing from most product development processes most of the time is how the users are going to use features within in the context of their environment. This should include time duration, other personas or actors that may interact with the product, and what other processes they may come in contact with. This may also include offline process, other products, and delays that may not be foreseen.
We did this a lot when at Jobvite, discussing the other products like Microsoft Outlook they may use to accomplish the task outside of the Jobvite application. It was important to discuss the process of hiring, for example, and how the candidates would go through the workflow. Some hiring processes would take a month, so we would include where the user was in that journey.
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. Software can do that.
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. Most importantly, 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.
Artifact
- A written user scenario, ideally 500 words or less. People really 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 any of your existing products have a similar feature?
This is probably the most valuable 30 minutes for this process: Take screen shots and include URLs of what your product does today. You have to set the context of not only what the product is, but how you think it will be used by personas you are serve.
There’s another point that I’ll make here: if you are working on a product, you should be familiar with the how the product is used. Use your product on a regular basis, 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 performs 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?”
Artifact
- A document containing screen shots. Ideally they are also printed on the 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 are other products that fit the mental model?
Again, the internet isn’t a blue sky thing where everything needs to be reinvented. There are a ton of applications and websites that have established the mental model for certain user activities for years.
Product Managers call this competitive analysis. I call this “Go use Google, it’s a great resource.”
For example:
- Spreadsheets: The first electronic spreadsheet, VisiCalc, was essentially 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 literally millions of examples to draw from. Amazon is a good place to start.
- Classified Websites: Craigslist is the baseline, but it really dates much further back. 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, is working 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 find examples in your domain. I work in an domain where our competitor’s software requires a really big purchase, which means we regularly don’t have access to competitors. So we look to other domains for the best ideas. If you understand that your users are using all kind of other applications, you can design something that’s familiar for them and fits their needs.
So now you know you don’t have permission to reinvent the wheel — that was invented in 3500 B.C. — let’s get to work.
Where to start
- Using the same activities 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 and comment on. Even better, post them on the wall in a hallway. That way, you’ll involve more people in the design process, and they’ll suggest other “like” applications.
Artifact
- A document containing screen shots. Ideally they are also printed on the wall.
Estimated time investment
- A day or less. Go use Google Image Search. It’s good for this.
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 opening up a wireframe tool like Axure — i.e. doing a bit of guerilla research that sometimes involves not talking to users — is very 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
The post What To Answer Before Designing Anything appeared first on Usability Counts.