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 is focused on easy wins, but without sufficient context and articulation of the overall intent and value for the customer and the business.

Soon, the product team is echoing an all-too-common refrain: “Once we get a sprint or two done, we’ll step back and do more planning and customer validation.” But that luxury of a little more breathing room never comes. The next sprint is always just around the corner and that next set of incremental design updates demands to be addressed ASAP.

This trap is more likely to happen when user experience design is viewed as just another step in the implementation process, rather than 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, tackling whatever is on the immediate dev sprint backlog. Speed to market—not value to users— becomes the delivery priority; the design team does not 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 the 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 whether the design decisions they make daily are sound, 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 the business owners and product management team gives you the opportunity to establish UX best practices upstream, and to set 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 as well, delivering 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 you are 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 doing research and are deeply involved in the strategy and planning process—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, but rather the creation of a strategic and conceptual framework in which product and feature design and execution are done. Finding the balance between upfront design planning and sprint-based detailed design execution is key and can be more of an art than a science. 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 you are co-located with your sprint team, use the physical space: post work up on walls and ask for input (put a stack of sticky notes and sharpies next to the wall). If you are not co-located, or fully co-located, posting work on team collaboration channels like Slack or Teams, or even assigning review tasks in Jira, are all ways to get visibility and action. 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 greater 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 simply left delivering more code with each sprint, not more 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.