This is Part 4 of the complete UI/UX Playbook. Strategy and interface craft matter little if the team can’t work together effectively to deliver them. UX governance describes how teams of people with different skills and specialisms should collaborate to produce the best user experience. Two truths frame this entire part: developing a digital product is a complex process, people are complex beings — and the only certainty in a project is change.
The Management Approach: Waterfall vs Agile
There are two broad approaches to collaboration on a project. The Waterfall approach offers a more comfortable management experience, while the Agile approach minimises risk and produces a far better UX outcome.
In Waterfall, because the work passes between teams of different skills and people, knowledge and experience must be very well documented and handed to the next team. Testing is generally done toward the end of the project. Roles — strategy specialists, content UX, back-end/front-end developers, UI/UX, testing, QA — work in sequence.
In Agile, cross-functional teams collaborate every sprint. This is typically around 5–9 people fully dedicated to a project, ideally sharing the same location. Testing happens as part of every sprint. A user-focused Agile approach produces an excellent UX outcome — which is why it’s the recommended default in this playbook.
Methodologies in Detail
Waterfall is a classic development process — linear and sequential with a fixed scope. It carries high risk when time, innovation, and budget changes come into play, because it’s hard to change long-term plans when user needs or technology evolve.
Agile uses an incremental, iterative approach. A core feature set is defined, then short sprints are planned and developments are made progressively, with features added along the way. From the project’s core structure through all its sprints, work is completed by people with mixed skills from all teams. UX work can be done both while building the core structure and in every sprint — producing a product with a good user experience and high usability.
Failure Risk
The two approaches distribute risk very differently.
- Waterfall is scope-focused. Scope is fixed, but time and cost are estimates — which leaves the risk in time and cost changes. User acceptance testing (UAT) and UX analyses happen in the later stages of the process.
- Agile fixes time and cost, but scope changes as the project develops. Risk decreases as the project progresses, and UAT and UX analyses are carried out during every sprint.
Transitioning from Waterfall to Agile
Moving from Waterfall to Agile is a shift across several dimensions — from one mindset to another:
- From technology-dependent to user-centred
- From scattered standards to defined standards
- From silo-bound skills to a working practice of broad, cross-functional teams
- From a single time-and-budget plan to experience goals
- From being tied to a single project strategy to being tied to business strategy
User Story Maps
A user story map analyses and organises user stories into a useful model to help you understand your product’s functionality and effectively plan releases that add value to users and the business in each version. It works across two dimensions — sequence and priority — letting you see the big picture of your backlog and helping you make prioritisation decisions. (The classic reference here is Jeff Patton’s work on user story mapping.)
- Epic — a large activity with user value, like “I want to buy a washing machine.” It’s made up of a large portion of features and needs, and covers a general user group.
- Theme — a collection of related user stories.
- User Story — a description of the desired functionality, told from the user’s point of view.
User stories are a simple way of framing a problem by focusing on the triggering event or person, the intended action, and the intended outcome. Written on cards, they describe the type of user, what they want, and why. It’s best to write stories collaboratively and keep them simple and concise — start with epics, then break them into smaller, more detailed stories. Stories shouldn’t be too large, and you should be able to determine what “completes” a story.
Sprinting and Backlogs
To do Agile successfully, it’s important to prioritise features for each sprint. One of the things that makes Agile so powerful is the ability to validate early and often with end users. But too many variables can muddle usability testing, and scope confusion and creep can become an internal challenge.
The backlog, in summary:
- The backlog is a list of opportunities, and anyone can add to it.
- Being on the backlog doesn’t mean something will become part of the product.
- The highest-priority items are more detailed; low-priority items are not — don’t waste time detailing low-priority items until necessary.
- Backlog work can include user stories, bugs, tasks, epics (large stories), prototypes, features, theme research, and more.
UX Governance Summary
Waterfall uses siloed teams; Agile governance uses cross-functional teams. In Agile, scope is flexible but time and budget are fixed; in Waterfall, scope is fixed but budget and time are flexible. Agile uses an iterative approach to maximise quality and reach a working MVP sooner or later, while Waterfall is easier to manage but offers a longer timeframe to develop a working build. Agile supports adaptive planning, evolutionary development, early delivery, and continuous improvement, and encourages fast, flexible responses to change. Use user story maps to define the MVP, keep user stories simple and concise, and use backlogs to track future opportunities and monitor progress.
Previous: ← Part 3 — UI Tactics · Next: Part 5 — UX Tools & Deliverables →
Part of the complete UI/UX Playbook, developed and authored by Gökhan Meriç. Get in touch.