“It’s very easy to be different, but very difficult to be better.”—Jonathan Ive, Chief Design Officer, Apple
Deciding on the right product-development process for your team can often be a paradox. Maintaining balance amidst a proliferation of inconsistencies in product requirements and development outcomes is challenging for both large and mid-sized organizations —especially when teams lack any metrics to measure their impact on a release.
Friction arises when there is a mismatch between the user’s mental model and product features. When a development team finds itself in an untenable situation, the blame game begins. But as Mad Men’s Don Draper often said, “Move forward.”
Every systematic and consistent delivery process must be easy to learn, understand, and follow. Many designers are unsure what UX process they should use. To determine the right UX process, designers need to question their assumptions about their current process and understand the type of software development lifecycle (SDLC) their team is employing.
Design is a very reflective practice, and today’s businesses demand user-centric services that focus on delivering software for local audiences that matches the user’s mental model. Product development is not about implementing features and testing their usability, but about designing products and services that are engaging and support human needs and values. Selecting the right UX process depends on many factors, including the delivery model, time to market, user experience, resource talent, team management, technology, flexibility, control, and trends.
In deciding the best UX process for your team, it is important to tailor that process to ensure it meets your needs. But you can still start with something with which you’re already familiar and adapt it. Start off by asking a few basic questions:
How stable are the requirements?
Who are the users?
What is the scope of the project?
Where are the project teams located?
Is the budget type static or operating?
Types of UX Processes
In this article, I’ll discuss the following UX processes:
UX for waterfall
UX for waterfall is a canonical, sequential, linear method of software development in which there is no flexibility to iterate design or development. UX designers can follow a user-centered design approach, but must adhere to an agreed-on scope and timeline. Usually, there is less freedom to experiment due to this method’s sequential flow. The budget for a project is estimated and usually predetermined or limited, so the waterfall-UX approach could encounter a lot of challenges in execution, especially if there are deviations from the process. During research, it is best to glean all user stories and get necessary stakeholders involved right from the project’s inception.
When Should You Use Waterfall UX?
Use waterfall UX in the following cases:
You’re working on a short-term, fixed-bid project.
The team has good experience executing similar projects.
The requirements are stable and fixed.
The team is experienced with the technology.
The scope of the project is large.
You have a fair idea of what you need to do.
Challenges for Designers
Waterfall UX presents the following challenges to designers:
longer reviews, signoffs, and rework times
detailed deliverables followed by documentation
visual designs with detailed style guides for development
wireframe flows detailing every interaction and styles
usability testing that might have no immediate impact on the design
involving or coordinating with usability specialists early during the requirements-gathering phase
ensuring confirmation of acceptance by stakeholders
Any dichotomy between time and value depends on the execution plan. Because of waterfall’s linear approach, a UX team working in this environment is often subject to unexpected requirements and technology constraints that impact the feasibility of design solutions. Clients may worry that the product could change direction once they receive the results from UX research. Plus, budgets tend to increase toward the end of the SDLC if the team spends too little time on research at the project’s inception. Figure 1 shows the sequential design and development phases of waterfall.
There are many versions of modified waterfall models. One of the most popular variations is shown in Figure 2. In this version, teams have the flexibility to iterate previous phases and dig more deeply during certain phases. This flexibility can enable a team to redefine some of their more speculative solutions.
In recent years, agile has become the most popular software development methodology in the industry. It is best for scenarios in which requirements change frequently and teams are doing iterative development. Agile focuses on development and timelines. It also embodies a periodic, incremental development approach to solving problems.
A central team of designers, researchers, and business analysts work on the initial discovery stages, then hand over the requirements to the UX designers and Scrum team, who implement a design solution. Agile UX focuses on building a product backlog comprising the following:
business and UX strategies
usability-testing analysis for any legacy systems
Design works ahead of development by a minimum of one sprint. During sprint planning, the team prioritizes the list of features; then a Scrum team selects product-backlog items, moves them to the sprint backlog, and depending on the velocity of the team, implements them. UX designers plan and facilitate collaborative activities such as design studios and brainstorming sessions with a Scrum team, which comprises a Scrum master, developers, product owners / managers, and technical writers.
At the end of each sprint, the Scrum team demos its outcome during a sprint-review meeting. This helps the team to assess how well their overall progress aligns with the product roadmap.
When Should You Use Agile UX?
Use agile UX in the following cases:
You need to test against fixed outcomes.
You must ship products quickly, based on a timeline.
You require the ability to scope, descope, or prioritize features based on budget, quality, and value through a number of sprints.
You need to act on customer demands over time.
You must ensure user-friendly products by collaborating with customers during development.
Your intent is to achieve customer satisfaction through rapid, continuous delivery of minimum viable experiences (MVEs).
Challenges for Designers
Agile UX presents the following challenges to designers:
UX designers and project teams having a proper understanding of their role within an agile team
aligning the entire team to communicate a common vision for the product
tunnel vision due to the team’s pace. Sometimes teams are so focused on executing user stories that they don’t look at things from a broader perspective.
a development-focused approach
UX designers having too much to do within a two-week sprint
absence of UX research before the start of sprint 0
no proper induction or training for designers at the beginning of a project
staying ahead of the sprints
too many responsibilities
The success of a project’s outcome is dependent on validating designs by receiving continuous feedback from users and stakeholders either at every sprint or for key releases. When the scope of the product is large, there might be multiple Scrum teams on the project. In such cases, a central UX team governs the overall process. This UX team should also be involved during the initial discovery and in evaluation sessions throughout the SDLC.
Visualizations of the Agile UX Process
Figure 3 shows how an agile UX process works. (Click the image to view an enlarged version of Figure 3.) I’ve modified this visualization of an agile UX process from a blog post by Krish Mandal of Tallan. Figure 4 shows another visualization of the agile UX process by Jeff Gothelf.
Organizations can also consider using SAFe (Scaled Agile Framework) in the following cases:
When a team wants to replicate the success of their current agile process across multiple programs and portfolios.
When there is a need for teams to work independently, to scale agile across the organization, roles, portfolio, and programs.
When a team experiences gaps, delays, and failures with their current agile process.
When it is necessary to improve development lead times.
“What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?”—Eric Ries
Lean UX derives from Lean manufacturing, which focuses on eliminating wasteful production of unwanted features. Its build, measure, learn loop lets teams iterate their designs based on user feedback—across multiple sprints—to build a minimum viable product (MVP). Lean UX follows an Iterative, participatory design process that ensures equal participation by design and development team members and generates many ideas and possible solutions to problems. Since, as shown in Figure 5, the entire team is involved throughout the entire process, there is a lot of team learning, which prevents the emergence of silos and gurus. A set of 12 principles drives Lean UX, which focuses on co-creation and quickly iterating designs, then validating these experiments during each sprint. There are a few challenges in adopting Lean UX—for example:
When there is no requirements proliferation, consensus mechanisms can sometimes force compromise or cause team members to misjudge designs and eliminate their most innovative elements.
Lean UX may work best for collocated teams rather than distributed teams. However, you can solve this problem by ensuring the adoption of better research and design collaboration tools and approaches. A few of these tools include the following:
Dscout (Mobile UT)
For large-scale projects with multiple modules, shorter sprint cycles and a quick-fail approach may frustrate team members.
Image based on: Lean UX process from Lean UX: Applying Lean Principles to Improve User Experience, by Jeff Gothelf, with Josh Seiden
When Should You Use Lean UX?
While there are many situations in which you could use Lean UX, I’ve limited the following list to a few key points. Use Lean UX in the following cases:
When there is a need to build products at startup speed and agility is prized.
When a team needs to conduct experiments—by iteratively creating MVPs—whose outcomes result in usable products.
If a team wants to get out of the deliverables business.
If a team wants to produce less documentation.
When choosing the right approach to product success requires a large learning curve.
When most team members are collocated.
When an organization is already following an agile process.
Challenges for Designers
Lean UX presents the following challenges to designers:
continuously staying focused during iterations
creating and tracking multiple prototypes in parallel
defining project boundaries with the product owner (PO)
negotiating releases with the product manager
understanding and constantly communicating the vision for the product
choosing the right facilitation and communication techniques for the audience—especially when the team is not collocated
building a custom framework by modifying a process that works for the team
having some team members distributed across geographies
Figure 6 shows how Lean UX works in tandem with iterative design sprints. (Click the image to view an enlarged version of Figure 6.)
Image based on: Lean UX process image from Lean UX: Applying Lean Principles to Improve User Experience, by Jeff Gothelf, with Josh Seiden
Pain-Driven Design (PDD) is all about figuring out what’s causing pain before you start solving design problems—that is, predicting pain, then responding to it. PDD enables organizations’ acquisition of knowledge during the discovery phase—and lets startups fail safely. Most successful, mature organizations already follow this approach either directly or indirectly—without knowing it’s a pain-driven design process. Engineering-dominated organizations obtain feedback from their customers, then implement their customers’ requests. Often, stakeholders become biased by customers’ requests or Support or Sales teams’ feedback from the marketplace.
Directives of PDD include the following:
seeking external collaborations within the ecosystem
pain-driven design and development
PDD follows the Lean Startup approach of validating the product early to ensure its success. Both PDD and Lean UX recommend building a hypothesis and validating it with users. However, the key difference between them is the point at which validation occurs. Lean UX teams test their hypothesis through experiments during the course of a sprint cycle. PDD focuses on prediscovery, as Laura Klein suggests in her book UX for Lean Startups. There are many successful examples of teams employing PDD, but the most interesting cases are buffer and Dropbox.
Joel Gascoigne, the founder of buffer, validated his product idea by launching three screens, shown in Figure 7, to understand whether someone would be interested in paying for the idea. He had initially committed to one week and eventually launched the product in seven weeks. You can learn more from Joel Gascoigne’s blog.
A recommended approach to PDD is to focus on problems that are associated with users’ functional jobs rather than on features and functionalities. As Harvard Business School Professor Theodore Levitt has said: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”
Integrating PDD into your development process—by breaking down the complexity of pain-driven decision-making into actions lets you articulate the differences between predictable problems and unpredictable pain. Actions for quick turnarounds and building hypotheses include the following:
You’ll arrive at a process that is similar to Lean UX, but with the flexibility to modify your actions depending on your decisions. Based on my experience, I have tried to depict this approach as the process shown in Figure 8. (Click the image to view an enlarged version of Figure 8.) The result is a dedicated team whose focus is on resolving painpoints for the organization’s customers. This team consists of Champions from various departments within the portfolio, including User Experience, Technology, Sales, Marketing, Finance, and Management. The Chief Experience Officer (CXO) leads this team.
The idea for UX Runway originally came from the Scaled Agile Framework (SAFe). Many people complain that agile works well only for small-scale projects and doesn’t scale up well. SAFe can provide a solution to this problem because it adopts both Lean and Agile principles, combining them to work effectively for large-scale projects that involve multiple Scrum teams. SAFe processes let you scale efforts across teams and leverage processes at the program and portfolio level.
UX runway works best with SAFe and focuses on keeping UX lean and agile at both the team and program level. Its focus is on just-in-time design, producing just enough for development to start. The UX team itself is an agile team with different levels, including UX managers, UX product owners, researchers, strategists, and multiple interaction designers. As part of one agile team, the designers work with multiple SAFe development teams. The designers work ahead of development by two or three sprints and dedicate 10% of their capacity to design changes and integration support. Designers also work on certain research spikes in parallel.
The UX team develops a UX backlog and scopes and plans their work, as shown in Figure 10. Natalie Warnert published and popularized the UX Runway method and has detailed the process on her Web site.
To put this in simple terms: UX runway = Agile UX + SAFe + expensive Lean UX approaches.
Clearly, there is a great future for pain-driven design. This process is extremely simple and, with the advent of machine learning and artificial-intelligence agents, you can automate it to some extent and fix the highest-risk issues for the lowest total cost.
While Lean UX is a great method, most organizations tend to use a combination of Lean UX and agile UX. The flexibility that both agile UX and Lean UX provide enables teams to modify their processes as necessary.
The first step in choosing the right process for your own team starts with exploring your options and educating stakeholders and decision makers about them. Ultimately, you can institutionalize your process, test your approach, achieve small successes, then modify and scale your approach.
By taking the route of least resistance, we end up focusing on what the majority want. As UX designers, it is important to break down silos and facilitate a team’s taking the right direction and making the right decisions. What’s the best approach? Create your own!