This article is written for those who are familiar with the agile work environment and user experience (UX) research. If you are new to design terms like ‘design discovery’ or ‘UX research’, I recommend reading this article as well.
Most designers I meet struggle to work in an agile team because they don’t know how to do great research. Research is an essential part of the discovery and a key factor in designing a great product or service. Without research, the designer has to guess what the best customer experience is, or get the stakeholder requirements, which most of the time leads to a poor product for the user or the business.
When designers work in an agile environment, they are expected to deliver the visual user interface (UI) so that the developer can build the functional aspects of the application. Designers therefore become a bottleneck if they spend too much time on research.
However, if the second story is “As a user, I want to see notification of XXX,” it’s difficult to know when the best moment is to send a user notification as well as how it is sent (e.g. email notification). It’s difficult to be sure about the user flow at all. So now you have to research to find out “What is the best way to design notifications for the user?” In this instance, this deadline should not follow the iteration deadline because the findings from your research might form a different solution which will affect the story prioritization.
When you start with the ‘research method’, you might end up performing a usability test to determine which prototype is easier to find feature X. To do this, you’ll need too develop a lot of different prototypes, which might be a complete waste of time.
However, if you decide to start with the ‘research goal’, you’ll instead focus on finding answers to a question like, “Where is the best place for feature X to be discovered for a one-time user?” Now you can think of a much better way to validate this goal; for example, you could create a quick poll to find out which menu tab users think feature X should be in.
Here’s also an interesting explanation from Matthew Godfrey, which illustrates how different purposes for the research impacts our research scope.
You can’t do research to uncover 100% of the unknown in the flow but you can research the most critical part of the flow to uncover 80% of the unknown.
You have a lot of things in your design which you can validate so list out all of the unknowns into individual research items. Map out your design and list all of the flows and features. For example, let’s say you have a check-out flow for an eCommerce website; List out the flow then take a look at what features are involved (see the diagram below).
Prioritize the list of items starting with two criteria; on the left-hand side, consider the “impact” (i.e. if something goes wrong, how big is the impact?) and on the right-hand side, consider the “time” (i.e. how long will it take me to do the research?). In the left-hand side column, allocate a numerical score (or colour) to each item based on how significant the impact is if things do go wrong (see the diagram below). I recommend you start from the left-hand column because you need to first consider what needs to be researched and how in order to determine how long it will take you.
Here’s what the flow diagram will now look like:
Let’s say that you've come up with the impact for each feature this way. You might say that “cash on delivery and internet banking” have “lower impact” because this flow has already been used and performed well. However, you might consider a “list of items” has a “high impact” because if users select the quantity incorrectly because of a bad user experience it could have a significant consequence.
Now go ahead and add the second criteria “time”. You will find it easier to spot which area makes sense to pick up first. So if you have only one day to do research, pick up the top right corner!
But be careful you don’t forget to look at the top left corner. These are items that are important but time-consuming. To tackle these, you have to plan ahead and use the tactics I mentioned earlier to maximize your time.
When everyone has their own UI to develop designers will usually work individually. From my personal experience, working as a solo designer means that you have less support for your research, which leads to less confidence in your UI, and overall decreased productivity. Instead, there should be a research leader who should give some defined UI work to a teammate so that they can focus on discovering the unknowns.
If your project is using the waterfall approach, having one less UI designer and one more design researcher is way more beneficial to the team. We know for a fact that having done the research ahead to uncover significant unknowns enables us to deliver the UI work so much faster.
The concept is to have someone own the responsibility for the design research and have enough capacity to cover important hypotheses. This will be something you have to set up with your team. . Determine how much capacity this person should have to use between research and UI delivery.
A research leader’s responsibility should include:
You need to validate with a real end-user when:
Key takeaways
Most designers I meet struggle to work in an agile team because they don’t know how to do great research. Research is an essential part of the discovery and a key factor in designing a great product or service. Without research, the designer has to guess what the best customer experience is, or get the stakeholder requirements, which most of the time leads to a poor product for the user or the business.
When designers work in an agile environment, they are expected to deliver the visual user interface (UI) so that the developer can build the functional aspects of the application. Designers therefore become a bottleneck if they spend too much time on research.
Ways to Maximize Design Research
Businesses make money from customers, and customers pay for things that make their lives better. Simple logic yet hard to accomplish. The designer’s role is, therefore, to make the product meet the customers’ needs, context and usability. This makes research essential; it helps designers uncover customer insights, validate ease for use, and more so that they can help clients deliver their promise to customers through great user experience. Here are some tactics I’ve learnt over the years to help you maximise your research.1. Start your research as early as possible.
Make the most out of the little time you have before the upcoming iteration.- If you’re starting a new project, your devs can not begin coding on their first day as they need time to set up their infrastructure first. Take this opportunity to talk to your Business Analyst (BA), Project Manager (PM) and Product Owner (PO) to understand what assumptions you need to find out and validate, and understand why it might impact the design.
- Your BA and PO are key to helping you get more time to do research as they plan the upcoming story which should start with something generic and focus on the beginning of the user journey. For example, for creating a login, you won’t need a lot of time for research because the best practices are widely available on the internet.
- Make sure the first research you pick helps you shape the overall high-level user journey AND the upcoming ‘research-priority’ story. I will cover what makes something a ‘research-priority’ later in this article.
2. Reframe your research deadline: Designers don’t do research in two-week sprints.
- If your team is doing scrum based on two-week sprints, this means that a specific user story needs to be completed within this time period. However, designers don’t design the UI based on a single user story - they design for the entire experience. So you shouldn’t limit your plan for your discovery activity based on the length of your sprints.
- After you have a high-level journey and a rough deadline of the iteration story, you can develop your research plan for the whole flow of that feature. Your first research will focus on validating the user journey, then you should focus on the specific interaction (UI) for the upcoming iteration/sprint deadline.
However, if the second story is “As a user, I want to see notification of XXX,” it’s difficult to know when the best moment is to send a user notification as well as how it is sent (e.g. email notification). It’s difficult to be sure about the user flow at all. So now you have to research to find out “What is the best way to design notifications for the user?” In this instance, this deadline should not follow the iteration deadline because the findings from your research might form a different solution which will affect the story prioritization.
- If you want to have time to research this, it’s your responsibility to plan this more than one sprint ahead. If there are a lot more unknowns e.g.”‘Do the notifications bring value to the user?” then you might need more iterations to complete your research.
- However, if you’re close to your deadline then you might have to deliver based on your ‘best guess’ (I know, this is a designer’s worst nightmare!) and learn from what you have delivered. And based on what you’ve learnt, propose a solution to the decision maker and give them a strong reason. Add to the backlog with your stakeholder agreement. Remember that using an agile approach helps us shape the work by learning fast and iterating!
3. Research goal over research method.
Never start with the research methodology. Always start with the research goal then decide on how to get the result. For example, let’s say that your research goal is to help the user find feature X.When you start with the ‘research method’, you might end up performing a usability test to determine which prototype is easier to find feature X. To do this, you’ll need too develop a lot of different prototypes, which might be a complete waste of time.
However, if you decide to start with the ‘research goal’, you’ll instead focus on finding answers to a question like, “Where is the best place for feature X to be discovered for a one-time user?” Now you can think of a much better way to validate this goal; for example, you could create a quick poll to find out which menu tab users think feature X should be in.
Here’s also an interesting explanation from Matthew Godfrey, which illustrates how different purposes for the research impacts our research scope.
4. Prioritize well by researching what has the biggest impact and is least time-consuming.
You can’t do research to uncover 100% of the unknown in the flow but you can research the most critical part of the flow to uncover 80% of the unknown.You have a lot of things in your design which you can validate so list out all of the unknowns into individual research items. Map out your design and list all of the flows and features. For example, let’s say you have a check-out flow for an eCommerce website; List out the flow then take a look at what features are involved (see the diagram below).
Example of a flow and the list of features within it. You should list as much as possible.
Prioritize the list of items starting with two criteria; on the left-hand side, consider the “impact” (i.e. if something goes wrong, how big is the impact?) and on the right-hand side, consider the “time” (i.e. how long will it take me to do the research?). In the left-hand side column, allocate a numerical score (or colour) to each item based on how significant the impact is if things do go wrong (see the diagram below). I recommend you start from the left-hand column because you need to first consider what needs to be researched and how in order to determine how long it will take you.
Here’s what the flow diagram will now look like:
Let’s say that you've come up with the impact for each feature this way. You might say that “cash on delivery and internet banking” have “lower impact” because this flow has already been used and performed well. However, you might consider a “list of items” has a “high impact” because if users select the quantity incorrectly because of a bad user experience it could have a significant consequence.
Now go ahead and add the second criteria “time”. You will find it easier to spot which area makes sense to pick up first. So if you have only one day to do research, pick up the top right corner!
But be careful you don’t forget to look at the top left corner. These are items that are important but time-consuming. To tackle these, you have to plan ahead and use the tactics I mentioned earlier to maximize your time.
5. If you are not solo UX in the team, have a research leader.
When everyone has their own UI to develop designers will usually work individually. From my personal experience, working as a solo designer means that you have less support for your research, which leads to less confidence in your UI, and overall decreased productivity. Instead, there should be a research leader who should give some defined UI work to a teammate so that they can focus on discovering the unknowns. If your project is using the waterfall approach, having one less UI designer and one more design researcher is way more beneficial to the team. We know for a fact that having done the research ahead to uncover significant unknowns enables us to deliver the UI work so much faster.
The concept is to have someone own the responsibility for the design research and have enough capacity to cover important hypotheses. This will be something you have to set up with your team. . Determine how much capacity this person should have to use between research and UI delivery.
A research leader’s responsibility should include:
- Continually harvesting the unknown list from the design team. They can use a workshop or go to each UX designer and ask what flow/interaction they feel unconfident about.
- Prioritize the list against the criteria and plan the research (as previously covered above).
- Research effectively. Just because you have more time doesn’t mean you can conduct a lengthy interview. Always practice Lean.
- Make sure you balance your research work with UI work since you still have to feed the pipeline yourself.
6. You might not need a real end-user to test your design.
Some validations don’t need a real end-user to be your respondent. So learn to determine when you do need real users and when you don’t.You need to validate with a real end-user when:
- You need a specific end-user’s context to understand the research artifacts (e.g. customer service portal); and
- The goal is to empathize with the user’s context and needs. (e.g. how do sick elderly people in homecare in Bangkok value XYZ features?)
- “What kind of pricing content leads to more conversion rates?” In this case, you have to validate with HR or someone with a similar context. You can not validate this with a first job seeker who works as a copywriter because they won't have the right experience and/or knowledge to know what they want to see in a pricing content.
- “Do the copy for buttons X and Y make sense when together on this page?” In this case,you can ask your teammate next to you to help validate. You don’t need someone with an HR background unless the copy for the button is very specific to the HR industry. But, if you know the end user’s goal, motivation or context is very clear from the previous research then you can test with anyone similar. Give the respondent the context background (role play) before research. Note:the result may not be as precise as validating with an end-user but you can do this in an emergency.
Key takeaways
- Plan to do the research upfront. Be responsible for knowing the iteration plan and allocating research time ahead.
- Design research should not necessarily be limited to on the iteration deadline. UI does.
- Start with the research goal, not the method. The goal should dictate the method, not the other way around.
- Prioritize what to research by using two criteria including (1) the impact if something fails and (2) time spent to do the research. — prioritize the items which are the most important and less time-consuming. However, make sure you plan for those that have high impact and are time-consuming.
- Have a research leader if you have more than one designer in a team.
- You might not need a real end-user to test your design. Check what context you would like to research.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
