Maximize Your UX Process · Cogensi
Abstract illustration of one long descending cascade of planes beside a tight loop of short arcs, in magenta and turquoise on a dark ground.
Article6 min read

Maximize Your UX Process

Waterfall and agile each have a place in design work. The key is knowing when to use which: long cycles for generative research and design systems, short sprints for shipping and learning.

ProcessAgileUser Research

Software development has two fundamental methodologies, waterfall and agile. As a designer, I seek to take advantage of both approaches, as each has its benefits. The key is knowing when to use each of the two. The waterfall approach provides a longer work cycle that, in some cases, is necessary to conduct in-depth research, explore design solutions fully, and create more detailed resolutions such as design systems. In contrast, agile is characterized by short sprints that allow us to quickly develop features and release them to our customers to collect market feedback in a rapid development process.

Waterfall methodology

The waterfall methodology progresses steadily from one phase to the next, flowing downwards like a waterfall. Research feeds strategy that, in turn, kicks off a plan. The plan progresses to design, and then teams proceed through development and conclude with support. In this approach, completing one phase starts the progression to the next until the process is complete.

Today, it is not fashionable to discuss the waterfall process when agile appears to be the de facto standard. Nevertheless, I believe many design projects can benefit from following this approach, at least at certain periods in their process. This is particularly true at the beginning of the UX process, during the generative research phase. It is great to allocate more than two weeks, the standard agile sprint duration, for this essential research activity. Deep thinking and data collection take some time. The same may be said for creating a design system or, for that matter, any higher-level design project I cannot fit into a compressed time frame.

Critics of the waterfall approach say that it is devoid of customer feedback for too long. Certainly, this is not true of the waterfall approach's generative research phase. Customer input is at the heart of the matter here. Waterfall-based design work can also collect real-world feedback using internal expert opinions from our interdepartmental colleagues. One may also solicit input from the market with rapid iteration user testing while having the benefit of being able to allocate the necessary time to complete larger design efforts.

The hidden benefits of waterfall

Why do we continue to see the waterfall process in practice? The truth is that large organizations can often be slow to move. Think here of the metaphorical cruise ship attempting to turn. Because large design projects often require multiple stakeholder sign-offs, it becomes hard to make changes that impact the company within a two- to three-week sprint window. Waterfall allows the space to make complex decisions within large, centralized teams and organizations.

In addition, if you allocate significant resources to UX design at the beginning of a project, there are substantial savings at the end of the waterfall. In his 1996 book Rapid Development: Taming Wild Software Schedules, Steve McConnell estimates that a design defect ignored at the beginning of a project costs 50 to 200 times as much to fix.[1] Profitability is shorted when UX is not incorporated earlier into the project.

Line chart with two curves over three milestones, start, first release and defect-free release. Well-functioning design rises gently to about 12. Dysfunctional design reaches first release slightly sooner, marked a, then climbs steeply to about 120 at defect-free release, marked b.
Ignoring UX at the beginning of a project may result in getting to market faster (a), but significantly delays the time to a defect-free release, 50 to 200 times more (b).

Agile methodology

Regarding the agile process, I like to remind myself that the competitive environment is fierce and requires constant adaptation. Iteration is part of the designer's process for exactly this reason. A project's requirements are not fixed and are likely to change in response to external realities. Several factors can lead to changes in project direction:

  • External changes in the marketplace, including the competition
  • New knowledge and insights gathered from within the organization
  • The evolving nature of software projects in general; one is constantly learning more about the problem over time

These considerations lead teams to seek a more flexible approach: designing with fewer initial features in shorter cycles. Agile, in essence, is a response to the increased speed and interconnectedness we see across all touchpoints in our lives. It is a design and development approach that seeks to respond to an ever faster-changing environment by working in smaller cycles at an increased pace to reduce those risks.

The UX team member takes on the representative customer role in this context. Our job is to stand in as a proxy for the customer, someone who can speak to their needs and ensure the project's success in return. Successful projects are the ones that meet customer needs, and it is the UX designer and researcher who best understand those needs.

From a practical point of view, UX in agile means that we are working faster and in smaller chunks with lots of ever-improving iterations. Typically, I have seen elegant UX created when making smaller incremental changes to an existing product. In this case, it is about fine-tuning and making improvements. I usually work in close contact and in a highly collaborative manner with the product manager and developer. Wireframes are my primary deliverable. I sometimes omit visual design, and we rely on an internal design system or style guide. Documentation is light as well, because it is understood that I am available, usually online via Slack these days, to answer questions as they arise.

Conclusions

No matter which method you choose, the reality is that companies that prioritize customer experience succeed. I have had the pleasure of working on many projects across different industries and verticals. My experience shows that one process is not necessarily better than the other.

The key is knowing when to utilize which of these approaches. I know this may seem a bit heretical in this agile day and age, but my experience shows that waterfall is fine in some situations. This is especially true during the generative research phase, because designers and researchers are heavily involved in gathering real-world feedback. That is what generative research is all about, after all. It is never fine to develop software in a void, which is a valid criticism of waterfall.

On the other hand, I enjoy designing with agile too. Short sprints that allow us to work quickly in an iterative manner enable us to get a product to market quickly and test our hypotheses. Choosing a process that suits your team and their needs is essential. In summary, I select the method that allows my teams to maximize their success.