TC Design
How the MAHCD process can fit into a sprint
- Allison Batoff
- Dan Larmour
- 1 Lean UX methods
- 1.1 Make the biggest investment when there is the greatest amount of uncertainty
- 1.2 Tackle assumptions and mitigate risk
- 1.3 Build relationships with users
- 1.4 Build trust with stakeholders
- 1.5 Focus on answering specific questions
- 1.6 Keep research activities lightweight
- 1.7 Invest in unmoderated research methods
- 1.8 Get team members outside of the UX role involved in research activities
- 1.9 Tap into existing UX research
- 1.10 Get quick feedback using wireframing
- 2 Other ideas
- 3 Conclusion
- 4 Example
- 5 Resources
When we start transitioning our UX activities into short sprint cycles, one of the things that often poses the greatest challenge is finding time for research and discovery.
In traditional waterfall projects, UX research is a phase. The process can often take many weeks or months by the time we plan our research activities, seek approvals, recruit participants, receive participant consent, conduct the research, collect the results and analyze the findings for patterns and insights. But in agile projects, we often do not have this kind of time, and instead should use Lean UX principles and methods.
“Many little bits of user research are easier to insert than a single significant discovery phase.” A Pragmatist’s Guide To Lean User Research — Smashing Magazine
Lean UX methods
Make the biggest investment when there is the greatest amount of uncertainty
There is something useful to learn at every stage of the project. However, the earlier the research, the more impact the findings will have on your product. This does not necessarily require doing a large-scale research phase but could rather be handled by conducting small, continuous research activities to reduce the unknowns at each step.
David Marquet connects this learning to the agile process in his book Leadership is Language. He advises creating more frequent opportunities for reflection and learning early in the project when there is the most uncertainty (For more information, see the Complete Play IBLI OnePagers The Plays Summarized.pdf).
Tackle assumptions and mitigate risk
UX research can also be an incredibly powerful risk mitigation tool. This research can provide insight into what users need so that the team does not invest effort building something that will not be useful. But how do we know how accurate our research is, especially if we only have time to test with a small portion of our user group? One approach to this is using a confidence-interval calculation. The NNGroup and the Interaction Design Foundation both have excellent articles on this subject.
Confidence Intervals, Margins of Error, and Confidence Levels in UX (nngroup.com)
Confidence Intervals and UX Research | IxDF (interaction-design.org)
Another approach when evaluating how much research is needed can be to map your assumptions on an assumption grid. A visual tool like this can highlight risky assumptions that would benefit from further research or identify areas where the risks are low, and we can more freely experiment. This is a great activity to perform together with your team and project stakeholders as everyone may have their own perception on what is an acceptable level of risk.
Assumption Grid Template & Example for Teams | Miro
Build relationships with users
One of the most time-consuming parts of the research process is participant recruitment. It is not feasible to go through a lengthy recruitment process when we are working in short sprint cycles. One technique that has been successful in Marine and Civil Aviation has been creating working groups. This has been shown to help build closer relationships with users and promote more user engagement. Working groups also send the message that we want to have a reciprocal relationship where we help each other and have a shared sense of ownership over the product. For researchers, these working groups are invaluable because they give us access to a pool of participants whenever we need feedback.
One thing to be cautious about is user fatigue. While getting user feedback is critical to our work, it is also important that our users understand that they have the freedom to opt out at any time. It is always a good idea to check in with your working group at regular intervals, to ensure that people still have the capacity to participate. One approach is to ask for a short-term commitment, for example, participating for 3 months, and then rotating in a new group at that time.
Build trust with stakeholders
Getting your research plan, recruitment communications and research materials approved by project stakeholders can be time-consuming and may delay your research activities.
An effective way we have seen researchers approach this challenge is by pulling back the curtain on the research process. Some ways to do this are by involving project stakeholders in writing the goals for the research plan or by inviting them to participate in a mock research session as you are testing your materials. This can help create a shared sense of ownership and provide further visibility into the research process.
Every stakeholder is different, and often the best thing we can do is facilitate an open conversation about their fears so that they trust us to conduct these activities and understand the value they bring. Once this trust is built, it is often quicker for us to get the necessary approvals in the future. There is a helpful chapter on this called “Stakeholders are People Too” in Articulating Design Decisions by Tom Greever.
Focus on answering specific questions
The Lean UX framework can be a useful tool when we are dealing with time constraints. A core principle of Lean UX is to reduce waste. One way to do this is by focusing research efforts on answering one specific question at a time.
Unfortunately, UX research does not have an infinite self-life. Things are constantly evolving in the user environment. This can be the result of external factors but also because of the changes we make with our software and service solutions. When planning research efforts we can ask, “Can our team act on these insights in the next three months?” If not, we may want to narrow the focus of our research to ensure we get the greatest return on investment.
Keep research activities lightweight
How do we handle situations where we are working in short sprint cycles, but we need to test the usability of a solution? This article, A Pragmatist’s Guide To Lean User Research, highlights 4 key questions to answer:
Did users see it?
Did users understand it?
Can people use it?
Will they like it?
Some methods that can be used for lightweight usability testing include:
A 5-second test (Five second testing guide);
A first click test (First click testing guide); or
A semantic differential survey (Explaining Semantic Differential Scales).
Invest in unmoderated research methods
In addition to keeping research activities lightweight, another technique can be to set up unmoderated insight gathering. One example is setting up usage analytics for capturing data like:
Time spent per page;
Active engagement time;
Scroll rate;
Where users are clicking within pages;
How users are getting to the site;
Errors and missing fields users are being presented with;
What devices are being used to access the site; and
Drop off points.
Another option can be running user surveys within the application and asking one or two simple questions in context. Please see an example from the Canadian Revenue Agency (CRA) below. Both methods can be run without active involvement from the UX researcher, and they also require little or no additional time from the user’s perspective.
When there are time constraints to user research, these methods can be very effective in narrowing down where research investment should be made.
Get team members outside of the UX role involved in research activities
On most of our product teams, we only have one UX designer or researcher. We often feel pressure to quickly deliver results and insights to our team and stakeholders to guide the product direction. But we do not need to do this alone. We have seen teams have great success involving the entire development team in research activities, not just as flies on the wall but as active participants with assigned responsibilities.
In addition to allowing the research process to be conducted more quickly, this has also been effective in developing a shared understanding and sense of ownership over the solution.
Tap into existing UX research
Unfortunately, we do not yet have one central repository for UX research results. However, teams in Marine and Civil Aviation are regularly conducting research activities and gathering valuable insights that may be helpful for your team. We always recommend reaching out to the UX and Service Design Teams channel or raising any research questions you have during a Marine and CivAv Design Meetup to see if there is existing research you can leverage.
Get quick feedback using wireframing
If we work with an iterative design mindset and make frequent improvements based on user feedback, there is less pressure to answer every question up front. Often simple wireframing will allow us to verify that we are on the right path and get our solution into the implementation phase. While we can get feedback from user testing with interactive design prototypes, these tools often have limitations in emulating an authentic browser experience. If we leverage lightweight wireframing tools and move more quickly into implementation, we can get valuable real-world feedback when users apply our features in their work environment.
Free Low-Fidelity Prototype Template for Teams | Miro
Other ideas
Here are a few other ideas of techniques teams have used to keep their design process lean:
Conduct solutioning with the entire development team to reduce the need for detailed requirements documentation and additional design review meetings;
Use existing design systems, like the Canada.ca Design System and MAACE Design System, for high fidelity components, when needed;
Encourage your development team to use the Centrally Deployed Template Solution (CDTS) and Telerik UI components for rapid development; and
Encourage and support your team to focus on solving one problem at a time.
Conclusion
When working in sprints, teams have integrated lightweight user research by connecting with users early and often, building relationships with project stakeholders, having open conversations about risks and assumptions and collecting the minimum information they need to get started. When streamlining our research activities, we must be mindful that we do not sacrifice participant quality, getting consent or managing research results.
Stay tuned to this space for templates and supporting educational materials to guide conversations with project stakeholders on the benefits of these research activities.
Example
Here is an example scenario of what this might look like:
During a usability testing session for your digital product, you learn that the users want to be able to be able to run a report to see a list of clients with outstanding account balances.
Sprint 1
Discover
Dig deeper to understand the specified context of use and where this new requirement is coming from. Activities like the 5 Why’s are incredibly powerful to understand what a user (or business) is trying to achieve when they request new functionality.
Refer to existing research and information such as personas, journey map, and/or service blueprint to understand both the situation and the context of use for the users.
Define the problem statement.
In this example, you may discover that the reason users need the report is because they do not want to create new requests for clients who have outstanding balances.
Sprint 2
Design
Get together with the entire team to present the context and problem statement. Host a mini-ideation workshop with the team to come up with many possible solutions, then converge on one or two ideal solutions.
In this example, the team may decide to design system validation to prevent new requests from being created for clients who have outstanding balances.
Implement
Use a 2-week sprint to build the solution and confirm success metrics so that you and the team will know if and when the implemented solution is successful.
In this example, the success metric you define may be that the amount of time spent by administrators to review new service requests to see if the client has an outstanding balance has been reduced to zero.
Sprint 3
Test
Have users try the solution in a sprint review to get their feedback. Use app analytics, Google Analytics, or other methods such as usability testing or satisfaction surveys to collect metrics.
In this example, you may ask a user to create a new service request in the system for a client who has an outstanding balance and collect feedback on whether your team’s solution adequately solved the original problem.
Sprint 4
Evaluate
Determine if the solution is successful. Did you hit your target metrics? If yes, you can move on to the next priority.
If the solution was not successful and the desired metrics were not achieved, begin again at Discovery to understand why and try a new solution.
In this example, you may use time on task tracking to measure the amount of time spent by administrators to review new service requests.
It can be tempting to move on to a new priority while waiting to evaluate the solution's success. But this is an opportunity to focus on improving and strengthening how your team works so that you can deliver even more effectively in the future. This can be a great time to pursue learning and skill development or to tackle action items from your recent retrospective.
Resources
TC Design