When Change Is Constant: A Spiral UX Design Model

Gradual Discovery of a Problem Space

Often, facts that are hidden in plain sight are very hard to extract. Anthropologists are trained to be strategic and patient when going into the field. They foster relationships and build trust with the indigenous people they study. It is tempting to answer a problem at hand with exotic observations. However, the underlying facts and rules of the inner workings of a social group can reveal themselves to us only once the group has accepted us. When William Whyte—the anthropologist who pioneered participatory observation and author of The Street Corner Society—went to Boston’s Cornerville to do his doctoral research on street-corner societies in the slum of the 1930s, his work progressed very little over the first year and a half. Then, finally, he was introduced to a street-corner gang leader who, fortunately, liked his idea and granted him access to insider information about the gang—such as ritualistic activities and power struggles. [1]

Stories like these are common in anthropological studies. It is probable that they also reflect the experiences of many user researchers in the field, who need to investigate user needs in foreign lands or subcultures that are outside the boundaries of their own experience. A touristic survey of a study site just skims the surface and probably generates a large volume of superficial information that won’t be very informative to design. But until our target group of users accepts us, there are few profound user insights that we can draw from our work. In user research, the discovery of a problem takes time.

The Systematic Investigation of a Solution Space

Finding the perfect solution to a problem is sometimes purely a game of chance. However, the fact that there is a degree of randomness in the process should not discourage our systematic exploration of a problem’s solution space. This is perhaps better illustrated by design thinking from German engineering design schools:

“Systematic design provides an effective way to rationalize the design and production processes. In original design, an ordered and stepwise approach—even if this is on a partially abstract level—will provide solutions that can be used again.”—Gerhard Pahl, Wolfgang Beitz, Jörg Feldhusen, and Karl-Heinrich Grote [2]

Great designers of technical or human systems are systems thinkers—masters of the art of solution decomposition, the identification of the principal solution components, and the systematic evaluation of every possible combination of those components.

Elements of a Design Process Model

UX design, at its essence, involves two simultaneous processes of mutual adaptation: a systematic design process and a spontaneous user-research process, involving a systematic designer and spontaneous user researcher.

On good projects, these two adaptive processes work seamlessly together. Deep user insights lead to good design, and systematic design and evaluation inspire even deeper queries into the lives of users. On bad projects, the user research and design processes counteract one another, block each other’s progress, undermine each other’s value, and lock the researcher and designer into a constant struggle.

A good design model mitigates conflicts between the modes of investigation of the problem and solution spaces and facilitates the collaboration of the people engaging in these processes. To guide and synchronize these two forces in the design process, a good design model should

• facilitate the creation of a tacit contract between user research and the user interface and technical design teams. Points of agreement should define concrete deliverables that the members of all teams understand.
• adapt to a gradual, yet unpredictable pace of problem discovery
• support systematic exploration of the solution space
• have a simple visual representation that facilitates communication and alignment across teams

Development Process Models

Design and development processes share many commonalities in terms of their organizational dynamics and  team communication patterns. Thus, it is natural to begin with a survey of the prevailing development process models. We should consider what characteristics of a model have made it successful, what pitfalls exist, and most importantly, how we might adapt it to a UX design process. Table 1 provides a comparison of these development models.

Table 1—Comparison of development models

	Contract Point	Support for Problem Discovery	Systematic Solutioning	Communication
Waterfall Model	Yes. The waterfall model rationalizes software development into distinct steps that you must plan and staff.	No. The waterfall model assumes a given and fixed problem space.	No. The waterfall model has no explicit emphasis on finding an optimal solution. The exploration of the solution space often stops at solutions that are ‘good enough.’	Yes. The waterfall model’s simple visual form makes it easy to understand by every team member.
Engineering Design Model	Yes. Similar to the waterfall model, the engineering design model also rationalizes software development into distinct phases.	No. The engineering design model relies on effective problem decomposition, which, in turn, demands a concrete problem definition.	Yes. The essence of the engineering design model is to systematically design and evaluate every possible alternative solution.	No. This model originally served the mechanical design community. It cannot be applied to UX design without adaptation.
Spiral Model	No. The original spiral model focused on reducing risk in software development. Thus, it defines no concrete contract points.	Yes. The underlying concept of the spiral model is progression in concept discovery.	Partially. The spiral model focuses on eliminating errors and unattractive alternatives early in the software development process. Because continuous refinement is part of each development cycle, it leaves room for systematic investigation of the solution space.	Partially. The spiral model has a complex visual representation. We should explore its adaptation to UX design further.

Waterfall Model

Winston Royce introduced the waterfall model of software engineering to rationalize its design process. Royce’s phased model is a great step forward in comparison to the just-write-it approach to coding that previously existed. The waterfall model provides clear steps in planning a design project. Each step is distinct from the others and is planned and staffed accordingly. Iteration is also anticipated, but with a limited scope.

“The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps, but rarely with the more remote steps in the sequence.”—Gerhard Pahl, Wolfgang Beitz, Jörg Feldhusen, and Karl-Heinrich Grote [2]

The waterfall model clearly defines contract points between its steps, or phases. The results of one step must be well documented before proceeding to the next step. The simplicity of the model ensures that it is readily teachable to novices and that everyone on a team can understand its structure.

However, the simplicity of this model also undermines its usefulness in UX design. The waterfall model requires a fixed problem definition—often in the form of requirements list—at the beginning of a project and assumes that problem definition will remain unchanged throughout the design and development process. The phased progression of this model also limits opportunities for the systematic exploration of the solution space, because finding a solution is considered a one-time effort in the design process. In this approach, teams allocate no conscious effort to iterative review and refinement of the solution.

Engineering Design Model

The engineering design model is representative of design approaches that emphasize the process of design and the systematic exploration of a solution space. The key to this design method is discovering viable ways of decomposing the solution space into semi-independent components. The team can then carry out the design of each component with some degree of independence from the designs of others. [3] By comparing different combinations of components, engineering design transforms problem solving into a process of optimization or quasi-optimization within the boundaries of alternative solutions.

The systematic nature of engineering design is very useful to UX design—in particular, creating multiple design alternatives for user interface components. For example, one could decompose the design of an error notification for a mobile application into the following components:

1. message tone—official or friendly
2. message specificity—brief or elaborated
3. presentation—modal message box, persistent display, or transitory display—as in a toast box

Design, in this sense, involves finding optimal combinations of the components shown in Table 2.

Table 2—Example of a design matrix in engineering design

Alternatives	Message Tone	Message Specificity	Presentation
1	official	brief	modal message box
2	official	brief	persistent display
3	official	brief	toast box
4	official	elaborated	modal message box
5	official	elaborated	persistent display
6	official	elaborated	toast box
7	friendly	brief	modal message box
8	friendly	brief	persistent display
9	friendly	brief	toast box
10	friendly	elaborated	modal message box
11	friendly	elaborated	persistent display
12	friendly	elaborated	toast box

The engineering design model ensures that every possible design alternative gets considered during the design process. However, an overemphasis on optimization has prevented the wide acceptance of the engineering design model for UX design. Since optimization happens only within a fixed problem space, engineering design tends to seek the best or a good-enough solution to the problem as we currently know it. Thus, this tends to obstruct changes to the team’s understanding of the problem definition during the design process.

Spiral Model

“The waterfall model is dead.” “No, it isn’t, but it should be.”—Barry W. Boehm [4]

The spiral model aims to find a cure for some of the toughest challenges of the waterfall model:

• gradual progression of requirements discovery
• lack of flexibility in accommodating unplanned, evolutionary paths during software development
• emphasis on detailed documentation as a completion criterion for each step in the model

Source: Boehm, Barry W. “A Spiral Model of Software Development and Enhancement.” Computer, Volume 21, Number 5, 1988.

The spiral model reflects the underlying ideal that each development cycle should progress the product concept and involve the same sequence of steps that comprise the overall spiral model:

• requirements definition
• requirements validation
• design alternatives
• validation of design alternatives
• prototyping

In comparison to the waterfall model, the spiral model affords a mechanism of institutionalizing the incorporation of changes into requirements throughout the software development process.

Originally, the spiral model focused on reducing risks in the software development process. Thus, it emphasizes eliminating errors and unattractive design alternatives early during software development. It specifies no contract points between its steps and lacks sufficient emphasis on the systematic exploration of a solution space. Adaptations would be necessary to achieve the spiral model’s full potential for UX design.

Adapting the Spiral Model for User Experience Design

Of the development models that I’ve surveyed, only the spiral model supports gradual discovery of the problem space as part of its core concept. Figure 2 shows one possible way of adapting the spiral model to a UX design process.

1. The team analyzes user needs and brainstorms product concepts. A lead designer consolidate ideas rather than the team’s attempting to achieve group consensus.
2. The lead designer communicates concepts to the team through personas and usage scenarios and gets their feedback.
3. The lead designer explores alternative designs with the team, then produces the final design through a convergent process.
4. The team reviews the design.
5. The lead designer or team creates prototypes—from lo-fi to hi-fi.
6. The team selects the right evaluation methods for the fidelity of the prototype and decides what questions to answer.
7. The team incorporates the evaluation results into refined user needs.

Here is a description of how this model works, as well as its fundamental rhythm—the divergent and convergent process of design:

• Refine user needs. During the divergent phase, the team discusses ideas and brainstorms to come to an initial, common understanding of user needs and business requirements. Group brainstorming generates ideas, but more importantly, develops a common understanding and aligns team members. During the convergent phase, a lead designer consolidates ideas and requirements into concrete personas and scenarios as contract objects.
• Review concepts. The entire team reviews concepts and contract objects and signs off on them. Often, I find this step easier said than done, especially when working with unfamiliar development teams. Members of the team may question the validity of a persona or scenario—drawing evidence from their own life experience instead—change current definitions, or create new ones. Discussions in the UX community suggest that data-driven personas and scenarios may mitigate this problem, because the data will make these artifacts more convincing to stakeholders in design. However, in practical design processes, there are often way too many decision points embodied in personas and scenarios to prove all of them with empirical user-research data. I have found that choosing to build trust and synergy with team members and supplementing the team’s discussions with empirical research data is more feasible than trying to use data to drive the entire design process.
• Design the solution. During the divergent phase, brainstorm alternative design solutions with the entire team—or if resources permit, use parallel design methods, creating a design competition within the team and taking different approaches to exploring the solution space. The spiral model affords open-ended design during every spiral cycle. This opens up opportunities for the systematic exploration of the solution space, following the engineering design approach, Depending on a project’s schedule, it may be necessary to complete this exploration over time. Often, time-pressed design teams do not have time to explore all potential combinations of design components. During the convergent phase, the lead designer brings together all of the ideas into a single design solution, in the form of wireframes or mockups. Viewing product mockups as a communication medium between designers and stakeholders, the conceptual integrity of a design that comes from a single mind is the most important factor in determining a product’s ease of use.

New user insights may arise at any time during the design process. This model institutionalizes the incorporation of new user insights into the design process. Having a single person be responsible for a design solution lets you avoid unnecessary communications to ensure that the product design reflects changes in the team’s understanding of user needs.

This adaptation of the spiral development model to UX design helps to break organizational silos between user research, UX design, and technical design and implementation teams. Organizational silos build fortresses between teams, increase communication costs, and slow down the overall progress of a project. Implementing the spiral UX design model requires that there first be a shift in an organization’s attitude toward the division of labor among its people. Instead of defining the boundaries of job roles according to functional areas and their individual expertise, this new approach values everyone in design and considers everyone’s opinions. This model suggests the efficacy of bringing developers into discussions about user research, as well as hearing user researchers’ concerns when talking about technical architecture. However, this approach should not result in more meetings for everyone, and you should avoid group design or design by committee at any cost.

Summary

The representation of an actual UX design process with a design model probably presents an overly simplified view of the process. However, the design model serves a descriptive function. Additionally, having an abstract representation of the design process in the form of a design model highlights the essential forces driving the process of UX design: simultaneous changes in the problem and solution spaces.

In this article, I’ve proposed a possible adaptation of the spiral model for a UX design process. By incorporating continuous changes to our understanding of the problem space into a systematic investigation of the solution space, we can synchronize these self-reinforcing forces and generate high-quality UX designs.

However, several important aspects of the UX design process require further discussion of empirical evidence and feedback—for instance, adapting this model to agile software development. 

Endnotes

Whyte, William Foote. Street Corner Society: The Social Structure of an Italian Slum. Chicago: University of Chicago Press, 2012.

Pahl, Gerhard, Wolfgang Beitz, Jörg Feldhusen, and Karl-Heinrich Grote. Engineering Design: A Systematic Approach. London: Springer-Verlag, 2007.

Simon, Herbert A. The Sciences of the Artificial. Boston: MIT Press, 1969.

Boehm, Barry W. “A Spiral Model of Software Development and Enhancement.” Computer, Volume 21, Number 5, 1988.