More Than Pixels: Selling Design Discovery
As designers, we know that research should play a pivotal role in any design process. Sadly, however, there are still a lot of organizations that do not see the value of research and would rather jump straight into the visual design stage of the design process.
The excuses given here tend to be:
“We already know what our customers want.”
“We don’t have the time/budget/people.”
“We’ll figure out the flaws in BETA.”
As designers, it is important that we are equipped to be able to have conversations with senior stakeholders to be able to sell and justify the importance of the so-called “Design Discovery” within the design process.
In this article, I’ll demystify what is meant by the term “Design Discovery” to help you better establish the importance of research within the creative process. I’ll also be giving advice on how to handle common pushbacks, along with providing various hints and tips on how to select the best research methods when undertaking user research.
My hope is that by reading this article, you will become comfortable with being able to sell “Design Discovery” as part of the creative process. You will know how to build a “Discovery Plan” of activities that answers all the questions you and your client need to initiate the design process with a clear purpose and direction.
Design With A Purpose
Digital design is not just about opening up Photoshop or Sketch and adding colors, shapes, textures, and animation to make a beautiful looking website or app.
As designers, before putting any pixels on canvas, we should have a solid understanding of:
- Who are the users we are designing for?
- What are the key tasks those users want to accomplish?
Ask yourself, is the purpose of what you are producing? Is it to help users:
- Conduct research,
- Find information,
- Save time,
- Track fitness,
- Maintain a healthy lifestyle,
- Feel safe,
- Organize schedules,
- Source goods,
- Purchase products,
- Gather ideas,
- Manage finances,
- Or something entirely different?
Understanding the answers to these questions should inform your design decisions. But before we design, we need to do some research.
Any design process worth its salt should start with a period of research, which (in agency terms) is often referred to as a “Discovery Phase”. The time and budget designers can allocate to a Discovery phase is determined by many factors such as the amount of the client’s existing project research and documentation as well as the client’s budget. Not to mention your own personal context, which we will come to later.
Business And User Goals
In a Discovery phase, we should ensure adequate time is dedicated to exploring both business and user goals.
Yes, we design experiences for users, but ultimately we produce our designs for clients (be that internal or external), too. Clients are the gatekeepers to what we design. They have the ultimate say over the project and they are the ones that hold the purse strings. Clients will have their own goals they want to achieve from a project and these do not always align with the users’ goals.
In order to ensure what we design throughout our design process hits the sweet spot, we need to make sure that we are spending time exploring both the business and user goals for the project (in the Research/Discovery phase).
Uncovering Business Goals
Typically, the quickest way to establish the business goals for a project is to host a stakeholder workshop with key project stakeholders. Your aim should be to get as many representatives from across different business functions as possible into one room to discuss the vision for the project (Marketing, Finance, Digital, Customer Services, and Sales).
Tip: Large organizations often tend to operate in organizational silos. This allows teams to focus on their core function such as marketing, customer care, etc. It allows staff to be effective without being distracted by activities where they have no knowledge and little or no skills. However, it often becomes a problem when the teams don’t have a singular vision/mission from leadership, and they begin to see their area as the driving force behind the company’s success. Often in these situations, cross-departmental communication can be poor to non-existent. By bringing different members from across the organization together in one room, you get to the source of the truth quicker and can link together internal business processes and ways of working.
The core purpose of the stakeholder workshop should be:
- To uncover the Current State (explore what exists today in terms of people, processes, systems, and tools);
- To define the Desired Future State (understand where the client wants to get to, i.e. their understandig of what the ideal state should look like);
- To align all stakeholders on the Vision for the project.
There are a series of activities that you can employ within your stakeholder workshop. I tend to typically build a full workshop day (7-8 hours) around 4-5 activities allowing 45mins uptil 1 hour for lunch and two 15-min coffee breaks between exercises. Any more that than, and I find energy levels start to dwindle.
I will vary the workshop activities I do around the nature of the project. However, each workshop I lead tends to include the following three core activities:
|Business Model Canvas||To explore the organizations business model and discuss where this project fits this model.|
|Measurement Plan||Define what are the most important business metrics the business wants to be able to measure and report on.|
|Proto Personas and User Stories||Explore who the business feels their users are and what are the key user stories we need to deliver against.|
Tip: If you’re new to delivering client workshops, I’ve added a list of recommended reading to the references section at the bottom of this article which will give you useful ideas on workshop activities, materials, and group sizes.
Following the workshop, you’ll need to produce a write up of what happened in the workshop itself. It also helps to take lots of photos on the workshop day. The purpose of the write-up should be to not only explain the purpose of the day and key findings, but also recommendations of next steps. Write-ups can be especially helpful for internal communication within the organization and bringing non-attendees up to speed with what happened on the day as well as agreeing on the next steps for the project.
Uncovering User Goals
Of course, Discovery is not just about understanding what the organization wants. We need to validate what users actually want and need.
With the business goals defined, you can then move on to explore the user goals through conducting some user research. There are many different user research methods you can employ throughout the Discovery process from Customer Interviews and Heuristic Evaluations to Usability Tests and Competitor Reviews, and more.
Having a clear idea of the questions you are looking to answer and available budget is the key to helping select the right research methods. It is, for this reason, important that you have a good idea of what these are before you get to this point.
Before you start to select which are the best user research methods to employ, step back and ask yourself the following question:
“What are the questions I/we as a design team need answers to?”
For example, do you want to understand:
- How many users are interacting with the current product?
- How do users think your product compares to a competitor product?
- What are the most common friction points within the current product?
- How is the current product’s performance measured?
- Do users struggle to find certain key pieces of information?
Grab a pen and write down what you want to achieve from your research in a list.
Tip: If you know you are going to be working on a fixed/tight budget, it is important to get confirmation on what that budget may look like at this point since this will have some bearing on the research methods you choose.
Another tip: User research does not have to happen after organizational research. I always find it helps to do some exploratory research prior to running stakeholder workshops. This ensures you go into the room with a baseline understanding of the organization its users and some common pain points. Some customers may not know what users do on their websites/apps nowadays; I like to go in prepared with some research to hand whether that be User Testing, Analytics Review or Tree Testing outputs.
Selecting Research Methods
The map below from the Nielsen Norman Group (NNG) shows an overview of 20 popular user research methods plotted on a 3-dimensional framework. It can provide a useful guide for helping you narrow down on a set of research methods to use.
The diagram may look complicated, but let us break down some key terms.
Along the x-axis, research methods are separated by the types of data they produce.
Quantitative data involves numbers and figures. It is great for answering questions such as:
- How much?
- How many?
- How long?
- Impact tracking?
Qualitative data involves quote, observations, photos, videos, and notes.
- What do users think?
- How do users feel?
- Why do users behave in a certain way?
- What are users like?
- What frustrates users?
Along the y-axis, research methods are separated by the user inputs.
- Behavioral Data
This data is based on what users do (outcomes).
- Attitudinal Data
This data is based on attitudes and opinions.
Finally, research methods are also classified by their context. Context explains the nature of the research, some research methods such as interviews require no product at all. Meanwhile, usability tests require users to complete scripted tasks and tell us how they think and feel.
Using the Model
Using your question list, firstly identify whether you are looking to understand users opinions (what people say) or actions (what people do) and secondly whether you are looking to understand why they behave in a certain way (why and how to fix) or how many of them are behaving in a certain way (how many and how much).
Now look at this simplified version of the matrix, and you should be able to work out which user research methods to focus in on.
If you’re looking to understand users’ attitudes and beliefs and you don’t have a working product then ‘Focus Groups’ or ‘Interviews’ would be suitable user research methods.
If you want to understand how many users are interacting with the current website or app then an ‘Analytics Review’ would be the right research method to adopt. Meanwhile, if you want to test how many people will be impacted by a change, A/B testing would be a suitable method.
No Silver Bullet
By now you should realize there is no shortcut to the research process; not one single UX research method will provide all the answers you need for a project.
Analytics reviews, for example, are a great low-cost way to explore behavioral, quantitative data about how users interact with an existing website or application.
However, this data falls short of telling you:
- Why users visited the site/app in the first place (motivation);
- What tasks they were looking to accomplish (intent);
- If users were successful in completing their tasks (task completion);
- How users found their overall experience (satisfaction).
These types of questions are best answered by other research methods such as ‘Customer Feedback’ surveys (also known as ‘Intercept Surveys’) which are available from tools such as Hotjar, Usabilla, and Qualaroo.
In order to build a holistic view of the user experience, the Research/Discovery process should typically last around 3 to 4 weeks and combine a combination of the different research methods.
Use your list of questions and the NNG matrix to help you decide on the most suitable research methods for your project. Wherever possible, try to use complimentary research methods to build a bigger picture of users motivations, drivers, and behaviors.
Tip: The UX Recipe tool is a great website for helping you pull together the different research methods you feel you need for a project and to calculate the cost of doing so.
Which brings me on to my next point.
Contexts And Budgets
The time and budget which you can allocate to Discovery will vary greatly depending on your role. Are you working in-house, freelance, or in an agency? Some typical scenarios are as follows:
Clients employ agencies to build projects that generate the right results. To get the right results, you firstly need to ensure you understand both the business’ needs and the needs of the users as these are almost always not the same. Agencies almost always start with a detailed Discovery phase often led by the UX Design team. Budgets are generally included in the cost of the total project, as such ample time is available for research.
- In-House: Large Company
When working in a large company, you are likely to already have a suite of tools along with a program of activity you’re using to measure the customer experience. Secondly, you are likely to be working alongside colleagues with specialist skills such as Data Analysts, Market Researchers, and even a Content Team. Do not be afraid to say hello to these people and see if they will be willing to help you conduct some research. Customer service teams are also worth befriending. Customer service teams are the front line of a business where customer problems are aired for all to see. They can be a goldmine of useful information. Go spend some time with the team, listen to customer service calls, and review call/chat logs.
- In-House: Smaller Company
When working as part of an in-house team in a smaller company, you are likely to be working on a tight budget and are spread across a lot of activities. Nevertheless, with some creative thinking, you can still undertake some low-cost research tasks such as Site Intercept surveys, Analytics reviews, and Guerilla testing, or simply review applied research.
When working freelance, your client often seeks you out with a very fixed budget, timeline and set of deliverables in mind, i.e. “We need a new Logo” or “We need a landing page design.” Selling Discovery as part of the process can often be a challenge freelancers typically undertake since they mostly end up using their own time and even working overtime. But it doesn’t have to be like this. Clients can be willing to spend their time in the Discovery pre-project phase. However, you need to be confident to be able to sell yourself and defend your process. This video has some excellent tips on how to sell Discovery to clients as a freelancer.
Selling Design Discovery
As you can see from the above, selling Design Discovery can be a challenge depending on your context. It’s much harder to sell Design Discovery when working as a freelancer than it is working within an agency.
Some of the most commons excuses organizations put forward for discounting the research process are:
“We don’t have the budget.”
“We’ll find it out in BETA.”
“We don’t have time.”
“We already know what users want.”
When selling Design Discovery and combating these points of view, remember these key things:
It doesn’t have to be expensive.
Research does not have to be costly especially with all of the tools and resources we have available today. You can conduct a Guerilla User Testing session for the price of a basic coffee. Furthermore, you can often source willing participants from website intercepts, forums or social media groups who are more than willing to help.
It’s much harder to fix later.
The findings that come as an output from research can be invaluable. It is much more cost and time effective to spend some of the project budgets up front to ensure there are no assumptions and blind spots than it is to course correct later on if the project has shifted off tangent. Uncovering blockers or significant pain points later into the project can be a huge drain on time as well as monetary resources.
Organizational views can often be biased.
Within large organizations especially, a view of ‘what users want’ is often shaped by senior managers’ thoughts and opinions rather than any applied user research. These viewpoints then cascade down to more junior members of the team who start to adopt the same viewpoints. Validating these opinions are actually correct viewpoints is essential.
There are other cross-company benefits.
Furthermore, a Discovery process also brings with it internal benefits. By bringing members from other business functions together and setting a clear direction for the project, you should win advocates for the project across many business functions. Everyone should leave the room with a clear understanding of what the project is, its vision, and the problems you are trying to fix. This helps to alleviate an enormous amount of uncertainty within the organization.
I like to best explain the purpose of the discovery phase by using my adaptation of the Design Squiggle by Damien Newman:
See how the Discovery phase allows us time to tackle the most uncertainty?
Waterfall And Agile
A Discovery phase can be integrated into both Waterfall and Agile project management methodologies.
In Waterfall projects, the Discovery phase happens at the very start of the project and can typically run for 4 to 12 weeks depending on the size of the project, the number of interdependent systems, and the areas which need to be explored.
In Agile projects, you may run a Discovery phase upfront to outline the purpose for the project and interconnect systems along with mini 1 to 2-week discovery process at the start of each sprint to gather the information you need to build out a feature.
The next time you start on any digital project:
Make sure you allow time for a Discovery phase at the start of your project to define both business and user goals, and to set a clear vision that sets a clear purpose and direction for the project to all stakeholders.
Be sure to run a Stakeholder workshop with representatives from a variety of different business functions across the business (Marketing, Finance, Digital, Customer Services, Sales).
Before selecting which user research methods to use on your project, write down a list of questions you wish to understand and get a budget defined. From there, you can use the NNG matrix to help you understand what the best tool to use is.
If you found this article interesting, here is some recommended further reading:
- “Practical Design Discovery,” Dan Brown, A Book Apart
- “Just Enough Research,” Erika Hall, A Book Apart
- “Business Goals vs. User Goals,” Brett Marshall, Medium
- “When to Use Which User-Experience Research Methods,” Christian Rohrer, NNG
- “Practical Design Discovery,” Dan Brown, A List Apart
- “The Business Model Canvas,” Strategyzer
- “How to Create a Measurement Plan and Why You Really Need One,” Julian Erbsloeh, FreshEgg
If you are interested in running Stakeholder workshops, I’d highly recommend reading the following books. Not only will they give you useful hints and tips on how to run workshops, they’re packed full of different workshop exercises to help you get answers to specific questions.
- “Value Proposition Design: How to Create Products and Services Customers Want ,” Alexander Osterwalder
- “Innovation Games: Creating Breakthrough Products Through Collaborative Play,” Luke Hohmann
- “Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers,” Dave Gray
- “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers,” Alexander Osterwalder
(cc, ra, yk, il)