Asking the right questions

How UX Design Discovery Works

“What dat?” asked my two year old niece twenty or so times as she pointed at almost every item in the room. I happily answered every inquiry to the best of my ability and watch the little gears turn in her head. Imagine starting from scratch, trying to understand the world one item at a time with a single question — the mixture of frustration and excitement is clearly visible on her face.

I often feel a bit like my niece as we begin a new project, trying to understand a world that I’m not yet familiar with. Luckily this isn’t my first rodeo, I come prepared with an arsenal of focused questions to get to the root of the problem we are setting out to solve. At Perficient Digital Labs, we employ a methodology designed to break down even the most complex of problems in the most complex of industries into simple, surmountable elements. Let’s talk about how to perform one of the most fundamental parts of the design process: how to ask questions.

Discovery

Before beginning a single sketch, choosing a typeface, or writing a single word of code, we launch every project with a phase called Discovery. Discovery can last from a day to a few weeks and can take many forms, but essentially, it is the method of understanding a client’s business, its customers and the specific problems at hand.

Why do discovery?

As consultants, we’ve worked in nearly every industry you can imagine from healthcare to finance to journalism. Even with an extensive catalog of experience, it’s impossible to know all the ins and outs of a client’s business off the bat. One of the great privileges of being a consultant is the chance to learn about how a particular business works. You don’t know what you don’t know, and the only way you can know is by speaking with the experts on the subject, client stakeholders.

Sometimes, the jargon and veils of industry complexity can be roadblocks to a successful project. While it’s important to understand the language of a client’s business, you can easily break through any roadblocks by resetting and viewing the project through the lens of the customer. User experience design is inherently user-focused, heck it’s right there in the name. Every activity in the design process must consider the user first and foremost. Discovery is your chance to meet your client’s customers and get to know as much as possible about them.

How it works

Discovery isn’t cookie-cutter—it could be anything from a multi-day workshop to a 1-hour phone call. Each project’s discovery phase should be tailored based on several factors:

• client — is this a new client or someone you’ve worked with before?
• size of project — is this a multi-phase project or a short sprint?
• complexity — how complex is the problem? is it a brand new product or a redesign?

Once a format has been established, the next step is gathering the right people. A team generally consists of 3-4 members. A director runs the sessions and guides conversation. A producer tracks project logistics like scope and timeline and captures detailed notes. A designer and/or engineer also takes detailed notes and aids in running the sessions. Client teams work best when project leaders and subject matter experts join forces to give a full picture of the task at hand. Project leaders answer big picture questions and subject matter experts answer the nitty-gritty detailed questions.

A discovery session can be made up of any number of these activities:

• Q & A — A round-table question and answer session aimed at gathering background and requirements.
• Demo — A client subject matter expert (SME) walks through the product to demonstrate key functionality and pain-points. During this walkthrough, the design team asks follow-up questions and captures requirements that arise.
• Observation — The design team shadows a SME, or more ideally, a customer as they go about their duties and interact with the product. Questions are asked to identify use cases, priorities, and pain-points.
• Concept sketching — Whether in a workshop setting with clients or back at the office, the design team guides a rapid sketching exercise that focuses on key requirements. The goal is to generate a ’silhouette’ of what the product could be before diving into detailed wireframing sprints.
• Prioritization — Clients participate in a requirement ranking exercise to focus in on the most pressing issues from a business and customer perspective.
• Technical discovery — Engineers meet with relevant technical SMEs to determine systems, data components, limitations etc. Note: In this article, I will not dig into technical discovery, instead focusing primarily on user experience design.

At the root of every activity is the basic methodology of asking the right questions. You cannot expect your clients or their customers to lay everything out on the table for you. Even the most organized clients cannot possibly present a 100% crystal-clear picture of what they need. It is our role as designers to facilitate and guide this process, focus where necessary, and avoid unproductive traps. This doesn’t happen magically, one must come prepared.

How to ask the right questions

Every industry and business is unique, but when it comes to user experience there are similarities all over the map. We don’t start from scratch every time we start a new project because there are core issues every project shares. With a common set of questions that aid in establishing goals, understanding users and defining product components, you can turn complex problems into elegant digital solutions.

Setting Goals

The most fundamental thing to understand is what you are building and why you are building it. You may have a pretty good grasp on the answers to these two questions before starting the project, but it’s important that all parties get on the same trajectory before embarking. For example, a project leader may understand the reason why a project is being undertaken from a business perspective (to gain users, to expand feature set, to cut revenue losses) but a technical SME may understand how the codebase needs to change in order to accommodate a shift in user experience. For this reason, ask these fundamental questions with all stakeholders in the room. It’s extremely important that all voices are heard and expectations are set early to avoid issues down the road.

Some of the common goal-oriented questions to ask are:

• Why are we doing this project? Pretty basic right? But you will often get differing answers from different stakeholders and it’s crucial these answers are heard.
• What are the biggest obstacles we need to overcome? Often the reason you are being hired for a project is to solve issues that could not be solved internally. You need to locate these pitfalls and find ways to avoid or bridge them.
• What does success look like? This question does more to define project goals than any other in this list. Clients usually know what they want, they just need your help to get there.
• How could we fail? The counterpart to the success question, a question about failure helps understand where to focus attention to come away with a win.
• What is the story we want to tell about this project 3 months/6 months/1 year down the road? Ask clients to visualize a press release or an article after the project has launched — what is the headline? what are the key takeaways from the article? what will people be talking about long after your product is introduced to the world?

These questions help establish goal statements that all parties can agree on. Every requirement, concept, or design component that arises should align with these statements. You should be able to point to these statements at the very end of a project and confirm that what was built has fulfilled the project goals.

Understanding users

All good design is empathetic. It is our charge, as user experience designers, to center everything we make on the people that use it day in and day out. The term “user” is a bit robotic, but for lack of a better option, I’ll be using it to represent these folks. A user-centered design process doesn’t always require creating detailed persona profiles, down to what variety of apples they like (though that might be very useful if you’re creating an app for apple critics). But it does require a detailed understanding of how they do their job, what frustrates and excites them, and how they might ultimately use the product you’re building. The first activity is to list every type of person that might use this product, no matter their level of involvement. In order to focus conversation, prioritize these user types. This has long-term importance as well, especially if you define your sprint schedules based on user types. For example, a team may focus more design cycles on the everyday user (90% of user base) than they would on the admin user (10% of user base). The next step is building a profile for each user type.

To learn about the users and their behavior, ask questions like:

• What tasks does this tool help the user accomplish? How does the user accomplish these tasks today? This is how to determine areas of functionality to build for each user type. You should also understand current user behavior to inform new functionality. Maybe the user employs an excel sheet to track some data today. You will want to know this in order to assess whether it’s functionality that can be incorporated into the new product.
• How often will the user use this product? What actions does the user take on a minute/hourly/daily/weekly/monthly/yearly basis? Time-based questions help define priority as well as understand behavior. If a user is spending their entire workday in the product, there are ergonomic considerations that don’t exist for a user that checks the tool once a month. Frequency questions help determine priority within the product — things that are done more frequently generally require more attention.
• What does the user ask for help on most often? By identifying user pain points, you can further refine your focus on solutions that will have the biggest impact.
• Has the user created any work-arounds to remedy current user experience problems? Often, folks have created clever work-arounds when a product isn’t working for them. Sometimes these solutions are analog, sometimes digital. Identifying them helps determine desired functionality.
• What does this user need to be able to communicate to other users? Is this a solo or collaborative product? What functionalities will help users communicate?
• What are the most typical pathways this user might take through the product? This question acts as a segue between user questions and functionality questions. You will probably spend the most time discussing this question in your discovery sessions. It requires a bit of foresight in order to visualize potential user scenarios. Focus your functionality questions on the user flows outlined in the client’s answer.

At this point, you should have a solid understanding of the key users, why they use the product, and how they might use it. Next, you’ll examine potential functionality for each user type.

Features and Functionality

As a result of the user-based questions, you have identified at least a few key functional components or features for each user type. The team then dives deep into each of these components. This is where sketching exercises may be incorporated to get some early functional ideas on paper, but at the root, you’re still asking questions. You are trying to understand the same things you need to understand about the overarching project, but on the feature level — What is the purpose? Who uses it? What is the flow?

Focusing on one key functional component at a time, ask questions like:

• What is the purpose or goal of this feature? A seemingly basic question that can sometimes determine whether or not a feature is worth building. The purpose of any feature should also align with the goals of the product.
• Which user type(s) will use this feature? Is authorization required? Who uses a feature gives you an indication of how important it is and where it should live in the product. It also may determine how complex it can be, based on the user type’s skill level. If authorization is required, there may be unique states of the component to be designed as well as a method for assigning permissions.
• At what point in a user’s process would this feature be most useful? You can assess whether a component has permanence or is a temporary state.
• How does this feature change over time? Much like authorization, this question helps determine the states required and how the system changes based on each user’s process.
• What are the available options in this feature? How can it be customized? In addition to determining component states, this question may dictate whether you will need to design a method for customization.
• Demonstrate a simple and complex usage example of this feature. This may require some imagination, but it helps the team visualize the range of experience that must be accounted for.

Data usually plays a key role in the products we design. To get a solid understanding of how data will flow in and out of the product, ask:

• How will a user use this data? Are they scanning it quickly to find anomalies? Are they correcting fields? Are they inputing data in forms? There are many answers to this question and all of them change user experience significantly.
• What are the minimum / maximum / average number of items? A component containing 5 data points would be designed quite differently than a component with 1000 data points. This question also helps determine the variability of data.
• What are the options for filtering/sorting? Determine the most useful tools for slicing and dicing the data.
• What artifacts/output would be useful to a user? A user might need to share a PDF report with their boss. In this case, you’ll want to provide a method for easily sharing the data.

It’s rare that every question for every feature is answered during the formal discover sessions, but the primary goal is to build a basic scaffolding that features can be built upon. The kick-off meeting of each design sprint is another great opportunity to dive further into functionality that was not defined during the discovery sessions.

Moving forward

I’m going to avoid the nitty gritty details of the post-discovery design process for this post, but it is crucial to understand that the answers gathered in discovery become the guideposts for all work that follows. Every overarching system you create, every component you design, and every button you detail is a result of asking the right questions. I feel strongly that this process is the only way to guarantee a tailored, innovative user experience, designed in an efficient, intelligent way. Sure, you could start a project based on an email containing some basic requirements, and it might look pretty good. But chances are, that resulting product will lack true understanding of a client’s business and customers and be nothing more than a pretty piece of wallpaper.

The user experience design process requires that clients are active and engaged in the work being done. The most successful projects we’ve experienced are truly collaborative starting with an energetic, mind-melding discovery phase and carrying that spirit through design and engineering sprints. Design consultants bring the experience of working with dozens of clients on hundreds of projects, each one informing the next. Clients bring their wealth of industry, customer, and process knowledge. All of this knowledge combined can create beautiful, innovative things — but it all starts with the right questions.

If you’d like to get to know our process a little better or have an idea you’d like to make a reality, please say hello at hello@perficientdigitallabs.com

Tyson Damman is Creative Director at Perficient Digital Labs. Read more about how Perficient Digital Labs uses Emerging Technology to create innovative experiences that transform the way our clients do business here.