A Practical Guide to Uniting UX and Agile
8 min readFusing UX and Development
There are no magic fixes for integrating user experience principles and best practices into your development process. It’s a thorny problem that can’t be solved overnight. Before we dive in, keep two things in mind:
1. Commitment is Essential
Without total dedication to making user-friendly apps, sites, or software, no UX guidance will work. So it’s best to be sure.
If you’re feeling unprepared for the challenge, first read up on the importance of integrating UX into your process. Next, get a better understanding of the types of UX resources you can bring to your team, then come back for the practical process advice.
2. No Process is Perfect
Most dev teams employ some form of iterative (at least somewhat Agile) development process. No two styles are quite alike. Our UX team has been working with dev teams going on 30 years. We’ve never encountered two teams developing products in quite the same way.
While there is no one-size-fits-all process, the bedrock principles of creating solid user experiences are the same regardless of the flavor or style of Agile you use.
Rules and Guidance
Non-waterfall processes were created to solve development problems. By default, they do not address user experience at all. This makes integrating UX quite a challenge. But you can do it. Below are the key lessons we’ve learned over decades of working with talented development teams on substantial digital products.
Ubiquity and Continuity
If you want to ship products known for their stellar user experience, UX resources must be involved from end-to-end of your process, collaborating extensively with dev and business teams along the way.
Ensure a Continuous UX Presence
UX resources usually lead early Discovery and user research but wholly disappear when business and technical requirements are formed (when major implementation decisions that affect the user experience are being made). A UX lead must inform and review business requirements (initial and rolling) and contribute to functional/data discussions with the dev team.
Demand the Same from the Development Team
Key development resources (e.g., dev team lead, front-end specialists) should participate in “creative activities” usually led by UX resources. This means being present for Discovery/user research and reviewing all early UX deliverables. Early strategy always influences development choices. When developers are present early on, later discussions effecting both experience and underlying technology are far more efficient.
Foster Cross-Discipline Collaboration
Essentially, both UX and dev resources should be present for all project definition and deliverable activities, even if that participation sometimes feels tangential. If UX and dev resources are involved in all aspects of a project together, they will always be positioned to collaborate well.
Demand UX-Informed Planning
A UX presence is critical for all planning. This includes everything from early, high-level experimental iteration to later formal sessions (e.g., backlog, grooming, retrospectives).
If user experience professionals are not involved, key decisions will be driven largely from a development perspective and dominated by a trained, even certified, Agile process leader with little or no UX background or experience. Without UX input, you cannot create quality user experiences.
UX-Informed Requirements
Producing effective product requirements is never easy. Bringing UX to the table adds complexity. But the effort is worth it. UX-powered requirements will help you radically level-up product quality.
Secure a Strong Business Analyst
Your project needs a dedicated business analyst (BA) who owns business requirements and stays active throughout the project. This may sound fundamental, but many firms run significant projects without dedicated BAs. This absence puts a heavy burden on the dev team and product stakeholders.
Encourage a BA/UX Partnership
Your BA must develop a close working relationship with your project’s UX leader (usually the lead product designer or lead UX strategist). Together, BAs and UX pros will connect the needs of the business to the needs of real-world users. They should each participate in and review each other’s foundational work (e.g., early prototypes, business requirements, user research, user stories).
Recognize the Limits of Traditional User Stories
User stories are a staple of most development processes, but they have several drawbacks:
- Focus — User stories are often not actually about users. They are usually written from the internal perspective of the business.
- Authorship — User stories are often written by BAs, who almost always lack UX training and experience.
- Detail — By their nature, user stories lack detail about interface behavior.
Give User Stories a UX Upgrade
The lead UX pro should review all user stories and bolster them with a UX perspective, which typically includes:
- UX Tasks — What the UX team must do.
- UX Effort — Estimate what it takes to fulfill the story.
- Success Metrics — Define success for users.
Add UX Requirements to the Mix
Development teams need more than user stories and functional specs. They also need UX requirements, detailed descriptions of specific interface interactions (e.g., navigation and form behavior). These requirements can be added directly to wireframes and/or visual design files before front-end development begins. Your UX team can demonstrate.
This approach is new for most dev teams but is well-suited to iterative processes. UX requirements ensure developers adhere to interface design standards and maintain fidelity to evolving design systems during development.
Tackle Changing Requirements Together
Product requirements and business imperatives inevitably change during development. All disciplines, including UX, must contribute to discussions surrounding this natural product evolution. UX professionals will focus on the broader experience implications of change, offering essential user-centered guidance.
Context, Cadence, and Evolution
Day-to-day UX process inputs are not well understood by development teams, but they form the backbone of satisfying, usable products.
Global Context Comes First
Despite the glorious promise of the Agile manifesto, products cannot be effectively designed and developed in tiny chunks from the get-go. Some aspects of product design are always global. UX teams must begin by defining and designing this global context (e.g., overall navigation structure, overall layout parameters, and visual design).
A comprehensive look at design provides a launching point for successful work on smaller, more focused components, screens, or functionality. Global design will evolve later, but it must be created first.
Iterate Early Together
The truly adventurous product team (all disciplines working together) will create low-fidelity prototypes exceedingly early, test them with real users, and make rapid adjustments. This process helps refine high-level requirements while the global design context is formed.
Think of this as product iteration before development begins. Some product teams use this collaborative process to drive development itself, defining epics and the user stories that form the project process backbone.
Not all teams are ready to devote the time and resources necessary to do this. But you can work toward it. Start with early collaborative sketching. Take and early stab at the product together. It will make a difference.
UX Stays Ahead of Development
Once development has begun in earnest, the UX team should always work slightly ahead (but not too far ahead) of the dev team. Chunks of work should go through wireframes, visual design, and even front-end code before developers merge everything into a functional whole.
In a scrum-based process, the UX team should work at least one sprint ahead of development. More than this risks disruption. Discussions and decisions about requirements, wireframes, design, and front-end code can easily evaporate from short-term memory, and the project can get out of sync.
Developers Must Review UX Work in Progress
Developers should regularly review all product wireframes and visual design, no matter how early the iteration. This keeps them connected to product evolution from the start, helps them flag potential issues extraordinarily early, and makes later review of final UX deliverables far easier.
Ensure Developers Painstakingly Adhere to UX Details
The integrity and consistency of the user experience depends on careful adherence to details. Because front-end and back-end developers are not used to sophisticated wireframes or visual design files, they don’t always pay sufficient attention to these details, particularly UX requirements.
Simply handing over artifacts is never enough. The UX and dev teams must meet prior to the development of any feature or component. The UX lead should give a walkthrough of relevant UX requirements to ensure clarity and mutual understanding.
The UX Team Must Review Development in Progress
Developers are not trained or experienced in UX, design, or content strategy. They are usually not (despite protests to the contrary) front-end specialists. The UX team must monitor, review, and comment on all development work and milestones. These reviews should be both formal (checkoffs) and informal (ongoing discussions). This is the only way to ensure the final product conforms to UX specifications.
Monitor Use of Your Design System
A high-functioning product team will collaborate to define, create, and update a design system. This system may begin with early sketches and must evolve to become modular, functional components. The best component libraries are deeply informed by UX, design, content, and front-end professionals.
UX and dev leads should team up to police this process. Appropriate use of components speeds up development, reduces redundancies, and helps promote good UX throughout.
Plan on Rework
Iterative processes assume a certain level of rework. As projects move forward, teams learn more about feasibility, scope, design, and (hopefully) user acceptance. We clarify requirements as we go and adjust previously completed features. It is all very normal.
Refinement is equally standard for UX deliverables. Don’t assume that wireframes, visual design, content, or front-end code are fully complete the first time they are delivered. Revisions will always be necessary.
Users and Testing
Get Constant User Feedback
Presenting early work to users (even in a loose, ad hoc fashion) helps ensure user acceptance down the line and keeps the team headed in the right direction. A user research specialist should organize and facilitate user sessions as often as possible. It is never too early to get user feedback.
When testing work with users, the project team should observe then meet afterward to identify immediate adjustments. (Don’t forget to invite those annoying stakeholders.)
Interpret User Feedback Wisely
Not everything users say should be taken at face value. UX professionals are experts at interpreting user feedback and distilling that feedback into concrete action. No other product team member will be sufficiently trained or experienced enough to do this.
UX Has a Role in Product Testing
Make sure the UX team tests finished work during user acceptance or quality assurance testing. Even with careful, consistent, cross-team collaboration, significant deviation between design and the finished product can always occur. The rule of thumb is simple: If a feature is about to be delivered to a user, the UX team must review, comment, test, and approve.
Make UX Central to Your Process
This list is neither perfect nor complete. No list reflecting a complex process can be. But the guidance here has been derived from deep experience working with development teams. It is a starting point if you are determined to bring UX values, roles, and activities into your development process.
Iterative, rolling, Agile processes thrive on openness and constant communication and the breaking down of silos. This means UX must become a thorough and deep part of everyday product definition, design, and development.
If you want to make user-friendly products that are adopted, efficiently used, and even loved, UX can never be a mere add-on to your process. The stewards of user experience can never be on the outside looking in.