UX Design Process Best Practices: Documentation for Driving Design Forward — Part 2
This is the UX Design Process Best Practices ebook, written by Jerry Cao, Ben Gremillion, Kamil Zięba, and Matt Ellis, and originally published on UXPin.com.
Informing Initial UX Requirements
If we were all mind readers, UX documentation wouldn’t be necessary. We wouldn’t need to decipher what our users want, and we could understand our teammates’ ideas clearly. But, sadly, we’re not mind readers, so we do the next best thing: make records about the minds of our users and our teams.
As we escape of the deliverables business, we become susceptible to poor planning. In order to continue designing great products without the paper trail, we must make sure to create the right documents, instead of more documents — especially in the early stages. This chapter will explore the documents that help us build momentum without weighing down the project in busywork.
As we mentioned in the previous chapter, the first stage of the process should be the research, which is itself divided into collecting data and organizing it. This chapter deals with how to collect data.
But even before that, you must know why you’re collecting data. Every UX project has its own unique requirements, and research is used to determine what they are. We can divide the requirements into three categories: business, user, and technical.
1. Business Requirements
Larger companies will usually have more requirements, sometimes completed by business analysts or product managers. In either case, these requirements can be better understood through stakeholder interviews.
2. User Requirements
What the user wants is central to design thinking, so these requirements should have an enormous influence on the UX design. While using your own empathy will help, you shouldn’t guess at user requirements — these should be gathered through testing like user interviews, surveys, field or diary studies, etc.
3. Technical Requirements
The technical requirements can be separated into functional and nonfunctional categories. The functional specifications outline what the product should be able to do, such as authentication and administrative functions, and can be organized into a specs document like this one from Product Hunt. Nonfunctional specifications describe how well the product performs, such as usability, performance, data integrity, and maintenance.
- and maintenance.
The entirety of the design process will be shaped around these requirements, so the better you understand them from the onset, the more precise your final product will be in satisfying them.
To help inspire critical thinking about your goals for a project, Michael Margolis posted these questions to ask before starting user research.
One of the best first steps to any UX project is to interview your stakeholders. They are the ones who define the basics of the project, especially the criteria for success. Kevin Hoffman of Goodkickoffmeetings.com even suggests doing this before the initial kickoff meeting so that you have a better “behind the scenes” understanding by the time everyone comes together.
The point of stakeholder interviews is mainly to be clear on the business and technical requirements of a project. Getting a straightforward answer on these early on will set you in the right direction going forward, and making a record of these answers will give you ground to stand on later in defending some design choices.
Additionally, stakeholder interviews make the stakeholders feel heard, validating that their opinions matter. You can’t deny the reality of politics in any design process.
2. Best Practices
If your company has a Product Requirements Document, jotting down notes from this is a good starting point before composing the questions.
The questions you ask will vary depending on the type of stakeholder you’re speaking with. As a starting point, we recommend following the templates of Kim Goodwin from her book Designing for the Digital Age, with excerpts published on Boxes and Arrows.
She breaks up the types of questions based department:
• Marketing Stakeholders — brand promoters looking for new, viable markets.
• Engineering Stakeholders — design engineer, system architect, or GUI, if applicable. For hardware, heads of manufacturing and electrical or mechanical engineering.
• Sales Stakeholders — in addition to a marketing head, it’s advisable to talk to a sales head, as the two often have different goals.
• Executives and SMEs — the decision-makers with authority over the different branches.
Before beginning, ask the rest of the design team for their input. They have their own questions that they want answered, too. We suggest opening a collaborative document like a shared folder in Google Docs that everyone can add to on their own.
While conducting the interview, don’t feel you need to be “all business.” Creating a casual atmosphere and friendly rapport will produce better results, not to mention make the experience more enjoyable. It will also help when the time comes to ask the risky questions about their fears and personal opinions concerning the project.
Pay particular attention to the following:
• Lists of requirements
• Prescriptive solutions
When these are brought up, probe with follow-up questions. These areas tend to be complicated, so extra effort is needed to clarify them.
At the end of the interview, Chris Cashdollar (VP of Design at Happycog) suggests asking them if they’d like to mention anything.
Beyond just being polite, this opens up the door to any unanticipated information that could benefit the project.
Chances are there will be some areas of contradiction, whether in their own statements or between different stakeholders. Be sure to clarify these at the moment, before they cause even bigger problems later on in the design process.
In terms of time, we’ve found that 45–60 minutes is usually sufficient. If you find this isn’t enough time to answer all your questions, it’s better to schedule a followup meeting than to exhaust someone with a two- or three-hour interview.
Recording the interview is critical — it’s what makes this documentation, and safeguards against misinterpreting the data. The recording can then be shared with other team members who weren’t there, and can be referenced later to settle disputes.
Don’t forget to ask the stakeholder to provide you with any relevant background documents that could help with the project. What the stakeholder sends over will also indicate where their priorities lie.
To understand the all-important user requirements, you need to understand the users themselves. While there are many different methods for connecting with your target audience, simply sitting down and talking with them is one of the most reliable.
The main purpose is to narrow your design focus by solidifying what your users want. The responses from your user interviews will reveal which design ideas will work, which won’t, and may even inspire new ones.
The data collected from user interviews will feed directly into the creation of personas, which dictate other documents like user scenarios and journey maps. For this, interviews should be as thorough as possible.
As described in The Guide to Usability Testing, user interviews also validate the other areas of research. Here you can either confirm or deny the problems and potential solutions that arose from stakeholder interviews or brainstorming sessions.
2. Best Practices
Before the interview, we suggest creating an overview document (again, Google Docs) describing the event. This is the easiest way to keep your team informed and elicit their input — just like with stakeholder meetings, your other teammates will have their own questions and concerns they want brought up. Furthermore, it will keep stakeholders feeling in the loop.
The overview document should contain the following:
• Goal — What you hope to gain from the interview (keep it concise).
• User Background — The user’s demographic information: job title, gender, age, web experience, etc.
• Behavioral Questions — Your intended questions about the user’s particular habits and processes.
• Product Questions — Questions specific to a preexisting, related, or theoretical product, such as why they (would) use it or how it might be improved.
Every project will have different goals, which means the actual questions should be different. However, there are some general guidelines that can apply to all situations.
• Instead of only asking what users like and dislike, ask what they do, how they do it, and what frustrates them. Asking open questions, such as “why?” questions, give the user the opportunity to expand on their thoughts and feelings and yield data that simplistic “yes or no” questions cut short. An appropriate amount of silence on the part of the interviewer will also gently encourage the user to elaborate.
• Remember that the answers your user gives are merely opinions, so don’t necessarily accept what they say as gospel. Cross-reference it with other interviews and studies first.
• Just as with the stakeholder interviews, keep it casual and light. Since the user is likely a stranger, helping them relax will give you better, more honest responses.
• Also, like with the stakeholders, make a record of the interview for documentation to share with the team and as a reference later on.
We suggest going a step further with collaboration than just sharing the list of questions. Try inviting along developers, product managers, or marketers so they can ask their questions in their own words. While you don’t want to gang-up on the user, a small team is acceptable — just be sure to select a leader beforehand, so you don’t confuse the user.
As for the location, different options will suit different purposes. Conducting interviews in your user’s natural environment (contextual interview) will put them more at ease, make it easier to schedule, and provide additional observational insights (such as distractions in their work or home, and clues to their personality). However, these require more effort and time on the interviewer’s part.
If resources are an issue, you can even conduct interviews remotely with Skype or Google Hangouts, which makes it easier to record.
For more practical advice on user interview best practices, check out these resources:
• Interviewing Humans by Erika Hall
• My Best Advice for Conducting User Interviews by Whitney Hess
You can think of user surveys as “user interviews light” — if you’re short on time or resources, they’re the next best option for understanding your users. While their data is not as in-depth or reliable as interviews, they can still shed light on your customer base.
In addition to a lighter version of the benefits of user interviews, surveys provide a few special advantages on their own.
As we mentioned, surveys take a quantitative approach to qualitative data. This allows you to recognize patterns more quickly. They also come readymade for graphs and statistical analysis, which create helpful documents to pass around.
Surveys can also reach a wider range of people since they are cheaper and less intrusive. You can even choose from several testing sites (download our free Guide to Usability Testing for a complete list) to target a specific set of criteria for whom you reach.
2. Best Practices
Surveys are generally low maintenance — your involvement is limited to writing the questions and analyzing the data. While surveys are a time-saving option, you should still be diligent when writing them to get the results you want.
• First, shorter is better, so only ask the questions you need to. Users will give better data to a 3-minute survey than a 20-minute one. Try creating a list of all potential questions, then editing them down to 5. If you have 8 questions, that’s fine, but any more and you should start cutting.
• Pay attention to phrasing. Closed questions (yes/no, multiple choice) will give you data that’s easier to analyze, while open questions allow you to discover new information — however, Jonathan Kochis, partner at Treble Apps, advises to be highly selective with your open questions. Regardless, you want your questions phrased as succinctly as possible.
• Consider the order of your questions, with the most important first. If you’d like to follow up, mention this at the end, after they’re more familiar with you. For more concrete guidelines, check out these addition survey resources:
• 20 Tips for Writing Web Surveys by David Travis, CEO of Userfocus
• Writing Surveys that Work by Diane Loviglio, UX Researcher at Mozilla
• Sample Survey Template from SurveyMonkey
The level of competitive analysis can vary depending on your needs, from hiring a heuristic researcher, to simply browsing around related sites one night. Either way, it helps to know what you’re up against.
Competitive analysis helps flesh out your business and (nonfunctional) technical goals, if not inspire new ones. What is your competitor doing that works, and where is their room for improvement — knowing these will come in handy when designing.
Understanding your competition will also help understand your users. If every other product you’re up against has a certain feature, users will expect that on your product, too, for better or worse. What you discover can also provide material for your interview or survey questions, such as how they felt about this or that aspect.
2. Best Practices
If you want to take an analytical approach, we suggest this four-step method from our free ebook Principles of Visual Consistency:
1. Determine which fields to evaluate — Common areas are the visual impact, navigation, or clarity of copy — but customize your approach to the project (Leigh Howells’ spiderweb heuristic above is a great starting point).
2. Evaluate — Try to get 5 people to critique your competitors based on the selected fields, but in a pinch, you can conduct the evaluation yourself.
3. Diagram the results — Plot out the results in a way that’s easy to visualize. Michael Hawley recommends the spider-web graph.
4. Compare the results — Compare your competitors' results with each other, or with your preexisting product. What areas do your competitors do similarly? Where is the most effective area to break-in to the market?
Note the consistencies and inconsistencies in the market, so you know when to follow suit and when to break the mold.
Some UX documents collect and officialize data for reference. These documents are optional, but recommended, meaning that if you’re trying to streamline the process as much as possible, you can cut them out, but if you have the time, they’ll prove valuable.
1. Specs Document — lists concretely the (functional) technical requirements. It’s a useful reference for the entire team to have throughout the process, especially during brainstorming and stakeholder interviews.
2. Style Guide — organizes all the project-wide choices for areas like color, typography, brand usage, layout, etc., and can even include bits of code. Download the free Critical Components of Web UI Style Guides for best practices.
3. Mood Boards — Showcases more abstract mood of the product, usually through collages, and sometimes with minor style guide elements. Great for communicating a consistent product atmosphere during the early stages.
4. Change Log — Somewhat of a relic from the waterfall days, but occasionally useful for settling disputes or general record-keeping.
Since the less documentation the better, ask yourself whether or not these will actually help you generate better designs before committing to any of them.
There is no shortage of methods for collecting this pre-design data, and each one brings something special and potentially useful. Card sorting, focus groups, participatory design — these all lend their own type of insight to the process. The methods we mentioned above, however, are just the most essential. They are the tried and true methods that any company can implement.
Now that you have all your data, what do you do with it?
In the next chapter, we’ll show you how to map out your user information.