Most of us employ Agile processes to define and validate products in digestible chunks. This should help us find usability flaws early and often, right? This should help us make more user-friendly sites, apps, and software?

Not really, no.

Agile is a development approach created to solve development problems. It addresses issues like chronically overbudget projects, delay culture, poor communication, feature bloat, wasted effort, testing chaos, you name it. The Agile Manifesto proclaims that more efficient, collaborative, accountable teams will make and ship better products. Fix the process and you fix the product.

But something fundamental is missing. User experience is conspicuously left out of the Agile equation.

The Missing Ingredient

UX is still something of a mystery to the development community and methodologies reflect this. Agile processes are not conceived with user experience in mind and so do not inherently solve user experience problems.

This is why Agile teams often fail to embrace UX principles, activities, deliverables, and team members. This is also why we remain awash in hard-to-use apps, sites, and software.

Boosting UX in Agile

Agile teams can drive toward higher quality user experiences by embracing and integrating UX. Here’s how:

Include UX professionals on your Agile team.

Agile processes feature a sophisticated array of project roles and responsibilities. But rarely, if ever, do these roles include user experience professionals. Users are typically represented by “the business” in the form of the product owner, stakeholders, or business analysts.

This approach is fundamentally flawed. Despite claims to the contrary, most “user” input comes primarily from customer representatives and stakeholders. We shouldn’t be shocked by this. Agile teams are simply acting as development teams always have. They identify what the customer wants/needs then build it. This is an old-fashioned model shoehorned into a new, Agile process.

Members or leaders of Agile teams, including folks advocating for the business, are almost never conversant with the principles of user behavior. Nor are they experienced with user research or user testing, the monumental pillars of user-centered design and development.

The fix is simple. If you don’t have a UX pro on your Agile team, get one. Now.

Get your UX resources involved in early planning.

If you care about user experience (and if you are reading this, you do), bring in your UX pro early. Make sure they contribute to foundational project planning.­

A UX lead will identify essential UX touch points that inevitably pepper the design and development process, driving the creation of more user-friendly products. They will ensure crucial and commonly omitted activities like user research and testing are accounted for. Without this user-centered input, development teams will be left to their own devices, with predictable results.

Project planning is a broad subject, encompassing more than plugging in UX leadership. The following essential points must be planned from the beginning as well.

Allow for definition sprints.

Set aside a “sprint zero” for the express purpose of defining overall product user experience strategy. This definition will become your road map for all subsequent sprints from a UX perspective.

Here you’ll define UX goals (and how they’ll be measured), prepare user personas, and brainstorm high-level UX requirements. You may even do broad-based user research. In some cases, early design of global interface elements occurs in this stage.

Next, get a jumpstart on development. Critical UX deliverables like wireframes or prototypes must get out in front of development by at least one sprint. Then, as the traditional sprint process kicks in, UX definition moves to the next feature and remains ahead of the game throughout. This process allows for better collaborative definition (it’s still a team effort) and provides time for user validation.

Keep UX resources involved in key meetings.

Every Agile meeting (ceremony, event, whatever) has a specific purpose and name. Take sprint planning. Some call this backlog planning, backlog grooming, or perhaps even story time (which sounds way more fun than it probably is). Whatever you call it, key decisions about requirements, priorities, estimates, and new ideas are happening. Every one of these decisions will have an impact on user experience.

Imagine a bit of functionality. During sprint planning, the development team rates the implementation effort at two points. But the UX lead speaks up, clarifying an easily missed interaction requirement. This key tidbit raises the developers’ bid to five points, which in turn affects prioritization. This user experience give and take happens all the time—unless of course you have no access to UX resources, in which case it never happens.

Requirements are forged and evolved in the various sprint meetings. The strength of your user experience rises and falls on these requirements’ details and strategy. UX professionals also define UX requirements, a vital part of the product equation rarely discussed by development teams. No one on traditional Agile teams owns such requirements. They are the province of the UX practitioner.

UX resources must have a voice. Without their input, development will continue apace without a true usability perspective. This is a major reason why most digital products end up being frustrating and hard to use.

Allow flexibility to revisit UX decisions.

Digital interfaces are made up of reusable UI components and distinct screens. Digital products also include global elements like navigation and the design “shell.” In a flexible Agile process, anything done to a component, screen, or global element in later sprints can have an effect on previous work in earlier sprints.

What if a critical form component is revised in a late-project sprint? Imagine this component touches many screens and has several variants. The project is complex, including wireframes (still active), visual design (completed for this component), and established front-end code. A change to this component affects everything done before. What is the single source of truth? What do we develop against? How do we even account for evolution?

You can’t let this go. Any adjustments that affect UX-specific deliverables like wireframes (until obsolete), visual design, microcopy, or UX requirements must be retouched as a part of your standard iteration process. Revisiting and revising earlier work ensures product consistency, and honestly, source-of-truth sanity. This is particularly important with UX, since Agile teams are largely unpracticed in working with UX deliverables.

Perhaps most important, you must carve out time to conduct a thorough review of all UX artifacts before testing your product. Testing is done in part based on documented requirements and standards. And some requirements are decidedly UX-specific. They may be encased in, say, wireframes. If those wireframes are casualties of rapid sprinting and have not been kept up to date, expect testing chaos.

And you guessed it, truing up UX deliverables is best led by UX resources.

Rely on UX guidance through launch.

Often, UX input is relegated to early and middle portions of projects. At some point, development kicks into high gear, and UX influence fades into the background. Agile teams that retain a UX presence through development and testing do much better on the user experience front.

UX guidance helps teams handle inevitable issues that arise during development. Features evolve, new interactions are introduced, and usability problems emerge. UX professionals keep products on track by handling everything on the spot.

This valuable input extends through testing. Expert UX practitioners are trained to look for highly specific issues related to usability and interaction. They will find inconsistencies with UX requirements that would otherwise easily be missed.

We call the retention of UX guidance the “UX Hold-Back.” User experience pros remain connected to the project to provide UX oversight. This is something of a secret weapon in the fight to make user-friendly products. Continuing to draw upon your UX resources all the way through release radically increases your chances of launching a user-friendly product.

Add the missing ingredient.

No one wants poor user experience. No one intends to make difficult-to-use products. But processes and resources are determinative. As a development-centered solution, Agile doesn’t account for user experience, an indispensable metric of digital product quality. Agile leaves it out of the mix.

But UX is not optional if you want to make better digital products. Agile teams must embrace the very concept of user experience. They must take immediate steps to integrate UX resources and principles deeply into their processes.

No organization can be instantaneously transformed into a UX-savvy powerhouse. But change is possible. Every organization can begin.