Getting out of the reactionary design trap
Speed wins. Except when it doesn’t—like when your efforts to be agile drive you to be purely reactionary, rather than more alert and adaptable, in your approach to UX.
Filter’s recent E-book on optimizing UX practices for agile delivery models takes a look at common UX problems organizations run into when trying to adopt agile methodologies and offers ideas on how to overcome these problems. Picking up on this thread, my last blog post looked at how design teams adapting to agile, continuous-delivery product development practices can get caught in an execution-only trap, and how they can work to avoid it.
Unfortunately, all too often we are not able to set up UX best practices early or are brought in and asked to catch a train that is already rolling down the tracks.
I’m already caught in the trap!
The strategies to avoid getting stuck in reactionary design—getting upstream in the process, partnering with the business and product owners in planning and strategy development, and helping define the sprint plans—all sound well and good. But what if that is not possible and it’s too late? What about those cases where teams are already in the “execution-only trap” and struggling to keep up and rid themselves of reactionary design habits?
Here is a common scenario: you walk into sprint planning and the scrum master pulls up the backlog. It’s not well-groomed nor well-prioritized. You have a general feature prioritization, but the stories are all over the place. Or worse, they don’t exist. Sprint planning ends up being a story writing exercise.
The team starts filling the sprint with the stories that seem to make sense, seem to make progress towards several of the feature goals. But then there’s a blocking issue because the one team member who “owns” that area is out on vacation. “Hey, we should fix some bugs too” comes up, and in go some recently submitted bugs.
At the end of sprint planning, the team identifies the stories that are most immediately blocked by design, and that becomes your team’s work items (“just crank out some designs for those stories in two days”). But first, go and unpack the requirements with the PM because only about a third of the needed data is actually written down. So the sprint starts and you realize that “lean” describes your processes—and your spirits.
As the adage goes, “If you find yourself in a hole, stop designing.”
This can be a hard and contentious step, but it may be the exact right thing to do. The first step is to get from Just-In-Time to Just Ahead. Getting at least one sprint ahead of the development team will give some much-needed room to work through the requirements, design alternatives, and implications.
Just as important, it forces a conversation and collaboration with the scrum master to do backlog grooming and prioritization. For the design team to work just ahead of the development team, a well-groomed backlog must exist; there must be a solid next set of priorities and stories to work on which you have confidence will get assigned to the development team in the following sprint. If there are not stories, or if you don’t have confidence in the prioritization, then there is work to do with both the scrum master and product owner.
It is also important to take some of this time to ensure you have the right design strategy in place and a solid conceptual foundation for the experience you are creating. Teams often end up in the just-in-time, execution-only trap, working without a broader vision that guides how the disparate parts of the experience all coalesce into a holistic and coherent solution. Or the vision gets eroded and falls apart as the different micro-experiences drift through compromise and unintended consequence.
Instead, keep returning to the conceptual foundation. Assess it, test it against new needs, insights, and challenges; update and evolve it to ensure it will continue to hold together and properly guide your design decisions. Doing this will help ensure you are solving the problem with the right overall design. (Whether or not you are solving the right problem is a topic for another post…)
These steps are designed to help you avoid further pain downstream—like the pain of finding you’ve created a product where the different parts just don’t quite fit together, where there is friction instead of flow. Or the pain of realizing you have to refactor the design and development to fix usability or workflow to accommodate later requirements or scenarios. Or having to put patches and hacks in place because refactoring is too expensive now that the code is working—even if it’s not working well. Or the worst pain of all: asking users to live with poor experiences and a dissatisfying product, with a promise to fix it in some hypothetical future.
Overcoming pushback
In some cases, raising the need to do this work, invest in good backlog management and get your conceptual house in order may generate some degree of pushback from the scrum team or product owner.
One key way around this challenge is to document the potential pains that will be mitigated for the team and customers.
The more you can make the issues explicit and measurable, the better. Communicate the cost of refactoring through the number or stories or amount of development velocity is consumed by refactoring and retrofitting. Also, determine the number of stories or bugs that are in the backlog that could have been avoided with better planning and design. Even if you have to talk to the development team and get a more qualitative assessment—treat it like a micro user study.
For customer pain, document the places where the design or flow are causing friction in the experience. Often, product owners and scrum teams are simply too familiar with the product and its flaws or have internalized the reasons for those issues. They need to have the problems and consequences shown to them from a new perspective, whether that be a flow, storyboard, or journey map. If you have any data points and analytics on those, even better.
This documentation of the experience issues and pain points is the start of doing an audit of your UX debt. Like technical debt, UX debt is the collection of flaws, experience bugs, inconsistencies, inefficiencies, and other problems in the experience that reduce the value and delight customers receive when using your product.
Get a full account of your debt so you can create a plan to tackle and pay down that debt! Paying down your UX debt is a necessary cost to get out of the trap, to get the right concepts and plans in place, and to set up the team for faster, more valuable ongoing sprint delivery.
How do you know how much UX debt you are carrying? Test, test, and then test some more. You must know the prevalence and degree of debt you are carrying and what’s causing the most pain for customers. One of the values of the agile process is that it aims to generate the delivery of business value in every sprint. Take advantage of that to do rapid validation and learning.
At the end of each sprint, there should be new, value-generating features and functionality. Excellent—now take that to users and validate that the value is real and tangible. Bring that data back to the team, and importantly the product owner and product management team. Even better, bring them along to participate in the research and user testing.
Where to start
The first and most important place to start is with empathy –empathy for your teammates and the unique challenges they are facing. We owe it to our colleagues to understand their motivations, pains, preferences, and accountabilities. In addition:
- Make sure you understand agile and its principles, and how your work contributes to and enables agile practices. Every organization has slightly different agile methodologies, and different ways they leverage agile values and principles to make them work best for their business and culture. Understand how the practice of agile in your organization aligns or doesn’t align, with the agile values and principles. There are likely areas where your organization’s flavor of agile could be better, and some of those areas will align with UX best practices.
- Assess your experience debt with heuristics, rapid customer testing, and data analysis. Then communicate this assessment and the value of paying down the UX debt. Show the scope and scale of the debt, the consequences of the debt to the experience, and the cost of not fixing it. Flows, storyboards, and customer verbatims all go a long way to highlight these issues.
- Build your backlog and estimates for the work of paying down the debt, so you are able to effectively drive the business conversation about what to prioritize. This will also help determine what needs to move down the backlog, what dependencies may exist, and how to fold the UX debt work in with feature work and technical debt.
- Ask for help! You may need to get some additional support and design sprint capacity to tackle the debt and get out of the trap.
- Show the value: as a means to both get agreement on getting debt prioritized in the backlog and to get additional design support, you have to communicate the value of that investment. For the sprint team, this will likely equate to faster delivery with less rework, more value delivered out of the sprint, and happier product owners and users. For the Product Manager and business, it’s about the right design, designed right, leading to more business and market value, higher adoption and customer satisfaction, lower support and churn costs, and higher brand equity.
Some of these are quantifiable—for example, the volume of refactoring work, customer testing metrics, behavioral and market analytics. Others are more qualitative. Use both to reinforce the value of applying more UX best practices to your processes.
This is the perfect time to also push to ensure you are working with a well-groomed backlog that effectively enables you to keep working a sprint or two ahead of the development teams. Having a business conversation about priorities and tradeoffs is also an opportunity to assess how the product roadmap and business priorities are formulated, and how UX research, ideation, and validation work can help make the process work better—to be sure you are solving the right problem, not just solving it right.
Engaging in the planning and strategy gets you completely out of the reactionary design trap so that you can better participate in the product strategy and know what will be coming to the backlog before it ever gets there. Then you can truly be a strong partner to product and development—and be a conduit through which the product promise is realized.
To learn about how product teams find themselves entrapped in agile environments, read Part One of the Risks of Reactionary Design series.
Filter is helping product owners, teams and companies optimize UX practices for the rapid pace of continuous delivery, DevOps, and agile development. Discover how we can drive greater success for your business: click here to contact Filter and let us know more about your UX needs.
