6 tactics to maximize UX research in Agile

This article is for those who familiar with the Agile work environment and UX research.

If you are new to design terms like ‘design discovery’ or ‘UX research’, I recommend visiting this article as well.

Most designers I met feel the struggle within the agile working team because they can not do research in their working environment. Research is part of the discovery and an important factor to design a great product or service. Without research, the designer has to guess what is the best experience or get the stakeholder requirements which mostly — not leads to a great product for the user or the business.

When designers work in an Agile environment, we are expected to deliver the UI so the developer can continue their work. We became a bottleneck if we spend too much time on research.

Maximize Design Research

Business wants to make money and money comes from customers. Customers pay for things that make their life better. Simple logic yet hard to accomplish. The designer makes the product meet customer needs/context/usability. This is why we need to Discover what kind of value proposition we can do and how do we do it.

Research is one tool designer use to uncover the unknown (eg. customer insights, usability check, etc.). Here are tactics to maximize research.

1. Manage to start research as upfront as possible.

Be enthusiastic with little time you have before the upcoming iteration.

If the project is a fresh start, at the beginning of the project, your devs can not start to code on their first day. They need time to set up how they work as well. Take this period seriously and talk to your BA, PM, PO what is it you think should be validated and why it might impact the design.
BA and PO are the keys to help you get more time to research. BA and PO plan the upcoming story. The story should start with something generic and focus on the beginning of the user journey. For example, login, you don’t need much research from that because you already have the best practice all around the internet.
Make sure the first research you pick helps you shaping the overall high-level user journey AND the upcoming research-priority story. I will cover what is research-priority in topic No. 4

2. Reframe your research deadline: Designers are NOT doing research base on two weeks iteration.

If your team is doing scrum base on 2 weeks iteration, the only thing that bases on 2 weeks deadline is UI for a specific story. But designers don’t design UI base on story but entire experience flow. So you don’t need to limit your plan for your discovery activity base on that timeline.

After you have a high-level journey and a rough deadline of iteration story, now you start a research plan for THE WHOLE FLOW of that feature. Your first research base on validating the flow as the first priority, then specific interaction for the upcoming UI deadline.

If your first story is basic login flow= you can skip user research and do desk research for best practice because you don’t want to reinvent the wheel! Now you can cut it out from your user research list and do quick desk research which saves more time and resources. This research deadline follows the iteration deadline because the unknow is uncovered enough from desk research so you can start UI design. After you finished the UI design, you should do a usability test but with your colleague sitting next to you.

If the second story is “As a user, I want to see notification of xxx.” and you not sure what is the best moment to send user notification or should it be something else like email notification? You are not sure about the flow at all. Now you have to do research to uncover ‘what is the best way to do notification?’ This deadline should NOT follow the iteration deadline because when you research to uncover, it might end up a different form of solution which effects story prioritization.

If you want to have time to uncover this, it’s your job to notice this more than 1 iteration ahead. It the unknow a lot more eg. ‘Does notification brings value to customer’ you might need more iteration to finished it.
But if the deadline is coming near you have to deliver your best guess (‘best guess’ is our nightmare I know!) and do the learning from what you delivered. Propose a solution after learning to the decision-maker with strong why. Add the backlog with your stakeholder agreement. Don’t consider the end of an iteration is the end of your research. Remember that Agile shape their work this way to help us learn faster!

3. Research goal over research method.

DON’T EVER start research with methodology. Always start with the research goal then decide how to get the result.

Bad example start with research method: We are doing a usability test which prototype is easier to find feature X (you might end up produce a lot of prototype=waste of time)

Take a step back, Reframe Goal: 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. It could be a quick poll on which menu tab do you think the feature X live in and you don’t waste much time.

I read an interesting explanation from Matthew Godfrey which illustrate how different purpose of the research impacts our research scope.

4. Research on the biggest impact & least time-consuming.

You can’t do research to cover 100% unknown of the flow but you can research on the most critical flow to cover 80% unknown.

List out all the unknown into research bits — You have a lot of things in your design you which you can validate. Mapping out your design and list all the flow and feature. For example, you have a check-out flow of an eCommerce website. You listed out the Flow then have a look what are the feature involved.

Example flow and list of features within it. You should list as much as possible.

Prioritize list item starting with 2 criteria — “If this was gone wrong, how big is the impact?” and “time spends to do research”. I recommend you to do the “impact” first then “time” because in “time” you have to think of how to do the research to estimate time.

Then… Score the impact if things go wrong. You can score with number or something else.

Let’s say you think of each feature impact this way. You might say Cash on delivery and Internet banking is not an important impact because this flow has been used and went well. But you think a list of items has a high impact because if users select quantity wrong because of bad UX it could be a big consequence.

Now add the second criteria — time. You will find it easier to spot which area makes sense to pick up first. So if you have 1 day to do research, pick up the top right corner!

But you must not forget the top left corner. These are important but consume time. 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 make we usually work like we are not the team. From my experience, we are going slower if we don’t have research support for our UI confidence.

Yes, the research leader should give some defined UI work to your teammate and focus on unknown discovery. If it’s waterfall world, Having one less UI maker but one more Design researcher is way more beneficial to the team. We know for the fact that having uncovered flow ready we can deliver the UI work so much faster.

The concept is to have someone own responsibility for design research and have capacity enough to cover important hypothesizes. You have to set up this with your team. Determine how much capacity should this person use between research and UI delivery.

Research leader responsibility

Keep harvesting the unknown list from the design team. You can use a workshop or go to each UX and ask what flow/interaction they feel unconfident.
Put the list in criteria and plan the research. (see ‘4.research on biggest impact’ above)
Do effective research. You have more time doesn’t mean you can do a long interview. Always do lean.
Make sure you balance your research work with UI work since you still have to feed the pipeline yourself.

The teammate still has to research. But they don’t have to invest as much time and energy to manage the entire process. They have to involve because at the end, we all deliver UI for the devs. So make sure your teammate involve during their UI research so they can go back and continue UI development.

6. You might not need a real end-user to test your design.

Some validation doesn’t need a real end-user to be your respondent. You have to know when do we need real users and when you aren’t.

You need to recruit real end-user when…

It needs a specific end-user context to understand the research artifacts (eg. customer service portal)
The goal is to empathize with the user context and needs. (eg. How sick Elderly in homecare in Bangkok value x,y,z feature?)

For example, you are designing a B2B service website for big corporate HR. You would like to validate…

“What kind of pricing content leads to more conversion rates?” >> you have to validate with HR or someone with a similar context. you can not validate with the first jobber who works as a copywriter because he/she won’t have a big corporate HR mindset about what they want to see in pricing content.
“Does the copy confusing between button X and Y together on this page?” >> This you can ask your teammate next to you. Don’t need an HR background to validate unless the button naming is something HR-related.
BUT, If you know the end user’s goal/motivation/context is very clear from previous research >> you can test with anyone similar or neutral background. Give the respondent the context background (role play) before research. (the result is not as precise as end-user themselves but you can use in an emergency)

Key take away

Plan to do research upfront. You are the one responsible to know the iteration plan ahead to allocate research time.
Design research does not necessarily base on the iteration deadline. UI does.
Don’t ever plan the research base on methodology. Research can be any form base on research goals.
Prioritize what to research with 2 criteria — impact if fail and time spends to research. Pick the important less time. Also, plan for important long time!
Have a research leader if you have more than one designer in a team.
You might not need to spend time to recruit a real user. Check what context you would like to research.

Hi! I’m Kuppy, an Experience designer from Thailand. This is my first article and I hope you find it’s helpful 🙂 Please feel free to comment/discuss/connect with me. My twitter | My Linkedin

6 tactics to maximize UX research in Agile was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

from UX Collective – Medium https://uxdesign.cc/6-tactics-to-maximize-ux-research-in-agile-c68093e098ff?source=rss—-138adf9c44c—4