Speed wins. Except when it doesn’t—when we move so fast we forget where we’re headed, or what we wanted to do when we got there.
In Filter’s recent E-book on optimizing UX practices for agile delivery models, we discuss some of the major challenges to UX success that organizations often face on the path to continuous delivery, DevOps, and other agile methodologies. In this post, we’ll dive deeper into one of the most critical and painful issues: reactionary, just-in-time design.
It’s a trap!
When moving to agile, continuous delivery product development practices, the drive for speed and the pressure to get demonstrable change swiftly into the hands of customers can ultimately lead to an execution-only trap. UX designers launch immediately into tackling the “low-hanging fruit” and “obvious problems” — but without strategic forethought, research, or analysis and insight, and based on unvalidated assumptions. This work focuses on easy wins without sufficient articulation of the overall intent for the customer and the business.
Soon, the product team will echo an all-too-common refrain: “After we complete a sprint or two, we’ll step back, plan more, and evaluate customer validation.” But that luxury of a little more breathing room never comes. The next sprint is always just around the corner, with the next incremental design updates demanding to be addressed ASAP.
Your team is most likely to fall into this trap when user experience design is viewed as just another step in the implementation process. UX should be viewed as a critical part of the strategy and planning phase of the product lifecycle.
The team ends up in a cycle of rapid incremental changes, doing reactionary, just-in-time design; the team’s focus is on tackling whatever is on the immediate dev sprint backlog. Speed to market—not value to users— becomes the delivery priority. The design team doesn’t want to be the bottleneck or cause the development team to sit idle, work on random tasks, or create features without design input. So, we resign ourselves to crank out work to get the dev team whatever they need to deploy new code.
But is it the right input? As much as the design team knows they’re cutting dangerous corners, they don’t know if they’ve made sound design decisions, or if they’ve just designed the team into a corner. And so, they’re left to wonder: Is a major design refactor just over the edge of the horizon? Are there big flow or concept usability issues just waiting for a customer to find? Will our team’s passionate labor just sit unused and unloved?
Avoid the trap
Avoiding this costly trap requires engaging with product and engineering teams in a more effective way. Working more closely with both business owners and product management provides an opportunity to establish UX best practices upstream. This will also establish expectations on how design fits into the agile process in a more impactful way. Developing partnerships with product managers and participating in the planning and roadmap creation process gives you the ability to influence what gets into the delivery backlog in the first place.
Many product management teams focus on your organization’s value proposition of the product and features: sales and revenue, market share and competitive positioning, customer retention, and support cost reduction. These are all essential parts of proper business prioritization, but they tend to drown out the conversation of the customers as people—people with needs, motivations, preferences, and, most importantly, the emotional drivers of behavior which are often not as rational as the business team would like to believe.
Without this understanding, the expectation that the product will deliver the desired adoption and loyalty is based on hopeful optimism, not grounded in user data or even clear-eyed realism. How often have we all brought a product or feature to market only to discover that our users don’t perceive it the way we intended?
Don’t assume: test & validate
One key question to ask of the business and product managers, then, is “What assumptions are we making?” We make large and small suppositions all the time but are often unaware of them because they seem so obvious to us or are fundamental to our views of the world. However, as countless research studies have demonstrated, very often we are very wrong about the motivations, decisions, and behaviors we assume of others.
When working with product owners and managers, it’s crucial to clearly communicate how user research will provide the insight needed to create products people truly need and want. Validation—early and often—will enable the team to learn and refine best practices along the way. Planning and strategy development should be agile too. Deliver outputs that can be validated and invalidated with customers via testing before investing the time and resources required to build and deliver the product.
Ask yourself and your product teams: “What assumptions are we making?” and identify which ones are essential for the success of the product. Then ask, “Why do we believe this assumption is right? Why might it be wrong?” and “How can we know?” Applying targeted research to these questions can provide answers that move the team from hoping to planning for success.
If you are already deeply involved in the research, strategy, and planning processes—great! Testable concepts set the overall experience strategy and direction and enable you to develop a holistic view of the product and plan—which in turn makes detailed, sprint-based design and delivery work more effective.
To be clear: this is not a full, upfront waterfall design. This is how to create a strategic and conceptual framework that also addresses product and feature design and execution. It’s more of an art than a science to finding the balance between upfront design planning and sprint-based detailed design execution. It takes practice, through cycles of failures and successes, and is often dependent on the organization and delivery teams with whom you are working. It takes practice, through cycles of failures and successes, and is often dependent on the organization and delivery teams with whom you are working.
Collaborate & communicate
Any designer that has worked in agile teams knows working a sprint (or ideally two) ahead of the development teams is imperative. Just-in-time design is a recipe for failure and frustration for everyone involved.
Delivery teams, however, don’t always understand why this is important since they often have little or no visibility into all the work that must happen before the creation of final design artifacts. They may look at final prototypes, comps, or redlines and think, “Really? How long could that take?” Inviting the delivery team into the design process exposes the entire design process and provides an opportunity to add their input and ideas to the mix. Take advantage of their experience and perspectives!
Finding time to do this during a sprint can be challenging, but there are some relatively easy ways to drive conversation and visibility. Start by asking for a few minutes of feedback after standup, put quick-fire conversations on the schedule, and show interim work during sprint demos.
If your team sits onsite, take advantage of your physical space; post your work on walls and ask for input (put a stack of sticky notes and sharpies next to the wall). For a remote team, leverage team collaboration channels like Slack or Teams, or even assign review tasks in Jira for visibility and action across your dispersed team. When using design collaboration tools such as InVision, UXPin, Frontify, Justinmind, Protoshare, or Confluence, post not only designs but also flows, concepts, and sketches for feedback and conversation. If you are using design collaboration tools such as InVision, UXPin, Frontify, Justinmind, Protoshare, or Confluence, post not only designs but also flows, concepts, and sketches for feedback and conversation.
When creating detailed designs in sprints, planning for rapid customer testing drives validation and learning into the sprint process. To take this forward, have a planned cadence of customer interactions with a pool of customers willing and able to provide rapid scheduling for feedback sessions; leverage asynchronous feedback via any number of design sharing and testing tools such as UserTesting, UserZoom, Validately, TryMyUI, and others. For an even easier (and cheaper) approach, identify representative users in your own organization—so long as you remain aware of the inherent biases that exist inside your own walls.
The speed and iterative power of agile, continuous delivery and other accelerated development practices should never come at the cost of customer learning. Otherwise, you’re delivering more code with each sprint, rather than value for each customer. In part two of this discussion, I’ll look at how product teams already stuck in the “agile trap” of reactionary design can begin to dig themselves out, and how to pay down the UX debt they may have incurred along the way.
To learn how to get out of the agile trap, read Part Two 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.
