Strategy

No More Requirements

Jon Kolko

Jan 1, 2023

20 minute read

When I began my career, I was working on small and contained interaction design problems with small and contained solutions–including Ford's initial online vehicle design-build-price system. Our team's sphere of influence was on the user interface, and my individual solutioning was aimed narrowly at the vehicle comparison tool. We were a team of two, sitting in the same room, and while it was a difficult set of problems to work on, it had very clear boundaries and edges.

Today, an individual contributor working on a similar project may still be tasked with designing an interface for comparing, but now they are expected understand design language, multiple platforms of delivery, creating continuity between an interface decision on a mobile device and what a dealer sees in a real-time interaction with a customer, what the rest of the team is doing, and so-on.

While the things a designer does may not have changed much, the things they need to know has grown exponentially.

This is not nostalgic thinking. The influence of experience, product, and service design has become larger, and as a result of this maturity of the field, there are increased expectations for designers. We are trusted to work through complexity because we're good at it. But what is it about a creative design process that makes designers so good at tackling ambiguous, systemic, and poorly formed problems? As the scope of problems grew, why did our process continue to work successfully?

We're successfully able to take on complicated design problems because we've learned to identify, manage, and manipulate constraints. While our discipline has many things in common with a scientific approach to problem solving, constraints are one of the aspects of our process that are unique to design and are a powerful backbone of how we do our work.

While constraints support our work, another force is actively working against this magic power: requirements. The process of gathering, understanding, and working within a set of requirements is a legacy of when design wasn’t respected or understood. It represents not just a waterfall approach to shipping products or developing services, but also a waterfall approach to the production of value: that the people defining the requirements of a problem are different than, and more important than, those creating the solution.

When we solved small problems, we could get by with leveraging boundary conditions without knowing specifics, absorbing requirements without sacrificing the entirety of our creative process. But in this new world, where we are expected to attack more complex problems, the requirement process makes us unable to add the full value that is expected. We need to understand why our approach works, and begin to push back on processes that are antithetical to ours.

Constraints are Organic Boundaries

A constraint is an artificial boundary around a creative exploration. Within parameters imposed by the natural world, we can creatively explore anything we can conceive of. And within that exploration, our ability to show our ideas–to manifest them in reality–is limited primarily by our individual skills and abilities.

There are many reasons people strive to be creative—expressive, meaningful, emotional, fulfilling, political, and so-on. For most practicing designers, a creative process refers to how we solve design problems in our companies. In this context, an unbounded canvas is a hinderance, not a benefit, because there are infinite answers to a design problem. Without boundaries, we we have no point of comparative reference and can’t assess which ideas are stronger. For an artist expressing an idea, the judgement is theirs alone. For a designer contributing to the fundamentals of a business strategy, there must be concrete ways of determining success.

Author Donald Schön describes that during the creative problem-solving process, designers—used here broadly, inclusive of software developers and architects—create comparative references for judging success in real time, as they go about their work. These points become objective criteria, at least temporarily, for deciding if a design decision is a good one in that project.

Schön’s theories are informed by his research observing architecture students, where he observed the master/apprentice relationship in action. Architecture is primarily taught in a studio environment where students are constantly making things and professors critique and correct their work as it emerges, in real-time.

He describes a case where a master architect and a student go back-and-forth to solve a problem of a structural system on the first floor of a new building design. The master architect continues to push the student by repeatedly asking, "What's the problem?"

After the class has been completed, the architect reflects on the student’s approach and struggles:

“I'm convinced that I have to come to the crucial issue. At a certain level, at a certain stage, his consistent avoidance of hierarchical organization is the reason why that kind of backbone and that kind of a central strategy eludes him...he then is searching for a process in which he can create that kind of coherence which he can achieve without having any hierarchies.”

Consider the language used by the master. He sees the student struggling for an organizing principle, specifically a sense of hierarchy, which would serve as a successful backbone for the building design. In this example, hierarchy is a design constraint, and without it, the student struggles. This boundary condition is critical because, by limiting what the student can do, his solution set becomes smaller.

This is counterintuitive: one would think that a limitation is, well, just that–something that limits exploration, and they would be right. But the limitation focuses a creative exploration, and without that focus, the student tries things arbitrarily. In Schön’s example; the student hopes "that if each of his moves at each of these places is marvelous, then the whole thing will make sense...the result of this knitting together of local solutions to local problems is the 'spaghetti bowl.'"

Assigning a hierarchy is a declaration of prioritization whereas the student’s haphazard and somewhat arbitrary approach to problem solving means that more and more solutions will be necessary in order to stumble upon a good one. At some point–lacking that serendipitous stumbling–the luxury of exploration will run out and the student will pick the best, or perhaps the last, solution, and move forward with it. Without the language to help others see the value of the design, he is unable to describe why his solution is a good one.

Hierarchy is one possible constraint. The student could also establish a constraint of harmony, one where elements are in an even and balanced relationship with one-another, or dominance, where one element or idea overpowers all the rest. In all cases, the designer isn’t given the constraint, and they don’t simply declare it without knowing why. They find the constraint by creating it.

Constraints Emerge When Things Are Made

Author Henrik Gedenryd views the act of designing as a fundamental part of cognition. He explains how constraints are found and created through the process of making and sketching solutions, and those constraints then focus the next iteration of sketching. This is a process that Gedenryd has called "interactive cognition."

This implies that our ability to form new meaning does not happen solely in the head, but also in the external world:

"...cognition is not organized around a mind working in isolation, but to carry out cognitive tasks through making the most of mind, action, and world working in concert. For this reason, cognition is organized differently, and thus works differently, than if it were purely intramental [produced only intellectually]. The result is that when these three parts work together, performance is superior to that of an intramentally organized cognition."

New ideas and design solutions are not made by sitting and thinking. The process of cognition is driven largely without introspection, instead, it's a form of perceptual and behavioral give-and-take.

Constraints are inferred through sub-, or incomplete- explorations.

Researcher Raymonde Guindon explored solutions developed for ill-defined software problems by analyzing verbal protocols of solutioning from expert software developers. One of the problems he explored was the design of an elevator system. While some rules of the problem were defined top-down (each floor has an up and down button, except the first and last; the elevator has buttons for each floor inside), the problem was ill-defined because the rules themselves did not lead to a solution. The problem offered was incomplete. The developers were given two hours to design a solution.

Guindon identified that the developers leveraged several approaches:

1. Inferences of new requirements that changed the design goals,
2. The immediate development of partial solutions to the new requirements,
3. The immediate recognition of partial solutions in various parts of the problem decomposition,
4. Drifting, and
5. Solution insights triggered by scenarios [in the same domain]

What is compelling about this model is the speed at which these five approaches occur, and how they interweave with one-another. The developers inferred new requirements, and immediately used those to create new, incomplete solutions. Some of those solutions were “drifts,” side explorations that, on their own, went nowhere, but ultimately informed the final solution.

The summary of Guindon’s research identified that constraints, used interchangeably with non-top-down requirements, are inferred and become added top-down requirements through the process of solving the problem.

Constraints in Action

During a recent project, an interaction designer on our team was working with one of our partners who makes educational software for teachers. They were working on how to track students on a class roster so the teacher can understand how they are performing:

In this small snippet of exploration–of interactive cognition–the designer has set up, shifted, torn down and built up constraints.

First, the designer created her own new constraint: that the teacher needs to see all of the students, and needs to see how they are doing.

Next, the designer–reacting to what she literally just drew–stood up a new constraint, based on an assumption: that teachers don't have time, and want to know things quickly. This is a form of hierarchy based not on the designer’s whim, but on critical thought about how a busy teacher works and thinks. Once that constraint was established as a working idea, it then led directly to a decision to easily show high and low performers in the class. We can imagine that this constraint would last throughout and across screens in the product. A rule is implicitly established: whenever possible, constrain data sets to show only small samples of important content.

Another constraint was also assumption-based: that teachers care about how their students are doing holistically, potentially because that could help the teacher better intervene with troubled students. This led to a decision to give the teacher the ability to see grades from other classes.

Still another constraint was driven by best-practice interface design: having an overlay window on top of another overlay window is confusing and complicated. This immediately corrected–and overruled–the second constraint that had been established. Conforming to a single-overlay-window paradigm became more important than giving a teacher deeper insight into the student’s performance, and the designer explained the decision by saying that the teacher "cares most about how the student is doing in their own class."

In a matter of seconds, these constraints were set up, considered, adapted, and torn back down. The constraints led to design decisions, which built on and informed additional design elements. These creative moves happened so quickly that the designer couldn’t list all of them when she walked through the artifacts she had developed, but she could describe the heuristics, like showing only the most important information, so that teachers can be efficient and focused. Going through this process solidified the design choices so that she kept future design activities as consistent as possible, or went back and made retroactive changes as new constraints emerged.

A Summary View of Constraints:

Emergent, based on the act of making things. Exploring ideas through sketches or diagrams leads to new rule for a design, which become new constraints.

Built up, and torn down, in seconds. The new constraints that emerge from one exploration immediately impact other moves in the design process. However, if they prove to be detrimental to forward progress, they are immediately rejected.

Informed by patterning experience. Mature designers identify and establish constraints based on having seen and solved similar problems before.

Informed by speed and craft. Mature designers are able to make things quickly, and at a high degree of fidelity, react to them, and keep the process moving forward.

Requirements Are Assigned Boundaries

A requirement is something the business identifies as a necessary component, rule, or function, before a creative exploration begins–and if a solution doesn't include this piece, it is rejected. Requirements are a fundamental part of the Six Sigma process, a method for removing errors (defects) from a manufacturing process. This process has evolved into a related process in software, where requirements are typically a convergence of technical limitations and what a business leader or team has deemed important for a competitive or strategic market placement.

Requirements are often gathered from the various parts of the business through discussion with stakeholders. A business analyst or product manager compiles a list of the elements people in the company identify as non-negotiable parts of a new design and this acts as a checklist for assessing if a project solution is defect-free.

One of the best-practices for this type of list is to make sure it's easy to measure through quantifiable and objective means if requirements are fulfilled.

For example, in the Business Analyst's Handbook, using the "SMART framework" means requirements need to be:

• Specific
• Measurable (verifiable)
• Achievable and Appropriate
• Realistic and Relevant
• Timely and Time-bound

Additionally, the handbook says that requirements should also be:

• Unambiguous
• Correct
• Consistent

Defining requirements ahead of time means that the limitations of a solution are known, achievable, and ideally risk-free. For a purely engineering-based solution (like manufacturing), execution risk would mean functional failure, and is something that's considered unacceptable. For businesses providing commodity products and services, or trying to incrementally improve existing offerings, or delivering mission-critical systems where the expectation is 0% failure (such as a missile control system), risk-free is expected and necessary. But in design, if a new idea is risk-free, it is, by definition, not an innovation–it's been established to such a degree that adoption or engagement unknowns no longer exist. If companies are trying to drive a market, a high level of creative risk is fundamental.

The Problem with Conflating Constraints with Requirements

The language used in the SMART requirement definition begins to paint a picture of the distinction between a requirement and a constraint, words that are too often used interchangeably. Additionally, goals should delve beyond SMART to be:

• Unambiguous
• Negotiable
• Consistent
• Always Changing
• Subjective
• Correct

The word "correct" is an interesting one because it implies that there is a right answer to a problem, which isn’t true for many products and services. What is a "correct" vehicle aesthetic, banking mobile experience, or weekend at Disney World? If a banking app does not actually display my bank balance, it is incorrect, because it has a functional defect. But if I deposit a check in the app and the experience feels “just OK,” it's difficult to claim that the experience was "wrong"–only that it was frustrating, or complex, or strange, or boring.

Defining requirements ahead of time means that the requirements are fixed, but in the process of working through a solution, designers often discover that requirements written without knowing how something will work don’t end up making sense. As a real example, a bank's legal team may define a requirement that, "Every customer must see and sign an end-user agreement recognizing that their investment accounts are not FDIC insured." But some customers may not have an investment account and only use the bank for checking and savings. During design, a designer may decide that, based on the customer's accounts, legal agreements should be displayed only when relevant. This is a contradiction to the requirement, but from the perspective of the customer, this is clearly a good design decision. However, this decision is technically an incorrect solution and will need to be explained to stakeholders in order to get buy-in.

Most importantly, defining requirements ahead of time means that someone, or a group of people, already know the scope of the work and may really need someone with the skillset to build it. This is not necessarily a bad situation to be in. Many problems are so well-formed that they don't need creative exploration. Solutions that emerge from a non-creative process will typically be similar to existing solutions and provide customers with expected and straightforward value. In this case, the act of solving the problem is one of execution, not one of strategy.

Designers Don't Do Well With Requirements

When a designer is handed a set of requirements, they generally feel limited.

I don't have enough time to do my work, because my work is about exploration, and exploration appears non-productive.

In the context of requirements, exploring a new idea seems like a poor, and poorly structured, use of time. Why explore, if the direction has already been established?

Exploration defines constraints, but if a team already has a checklist of requirements, new constraints may not be necessary. The time for this exploration is eliminated, and as a result, designers see and feel that their work has been artificially compressed into an unrealistic timeline. What's more, designers often can't help themselves from exploring, because it's integral to the nature of the work. As a result, this time-consuming exploration will occur anyways, but won't be recognized as valuable. Design will be seen as a roadblock instead of an evolution.

I don't have autonomy to do my work, because I'm viewed as an execution arm.

Few people like to be told what to do. It's a sign of a power imbalance and it trivializes a role, pushing it further and further downstream in a strategic process. Without autonomy, designers are given requirements to execute rather than the ability to creatively explore and solve problems.

I don't understand why I'm doing my work, because the definition of the work has been created by someone else.

Requirements come from somewhere—often, from the perceived needs of a customer—but if the reason behind the requirements is lost, they will likely seem illogical without that context. The market doesn't necessary behave in an objective or obvious way, and internal groups seem to require peculiar things. Without deep explanation, the designer is being asked to execute without understanding the problem they are meant to solve.

I don't see continuity in my work, because there's little creative logic to the expectations of my solutions.

Requirements often have little to do with one-another—they were gathered in isolation from a variety of sources and stakeholders, and represent a mix of opinions and perspectives. Sometimes, requirements even contradict one-another. Given this list of apples and oranges, it's unlikely that even the best design will have an intrinsic sense of harmony or continuity. The designer, making good work with the best intentions, may still end up with a solution that feels haphazard or incomplete because they are trying to check off all requirements without being able to use critical thinking in their approach.

In the worst case, a designer who has been handed a requirements list and told to follow it to the letter, and who has consumed that list and designed to the best of their abilities, feels overworked and under-appreciated, confused about how their work contributes to the success of the business, and they end up with a solution that they aren't proud of. This is what's most troubling, and sad, about the feelings evoked by the requirement-definition process. Creative people quit over these feelings. And they don't just quit their jobs: they quit the profession.

We Need to Champion Constraints, But We Don't Know How

Constraints, not requirements, are the creative language of design, and should be encouraged instead. Designers and design strategists need to find a way to explain to our colleagues that the established, recognized, respected, and well-documented practice of defining requirements is not a very good way to design products and services.

But we have a lot of work to do in order to remove superfluous boundaries like requirements in favor of natural ones like constraints. The distinction between these two ideas manifests as a practical difference, but needs to be described to stakeholder who may not be involved in the design process. And that presents a challenge for designers who usually understand this difference intuitively.

While there are thousands of texts written and classes held on the value of requirements, there's little discussion about constraints. Most people in businesses are reasonable, and ultimately, they will pursue a process and set of methods that shows it is successful and valuable. The burden is on designers to describe our perspective rationally and then show it in action, but designers aren’t taught to present the value of constraints as a conceptual idea or describe the development of constraints as a process.

I encourage design leaders to explore and begin to answer some of these practical questions:

• How can we clearly describe the idea of constraints, the specific constraints in our project, and where these constraints came from when we present a solution to stakeholders?
• How can we best explain why we left out a requirement because it didn’t work well for the customer or in the design to the person who "required" it in the first place?
• How can we recreate the creative process for those who weren't part of it—so they come to the same constraint-based conclusions that we did?
• How can we show the relationship between the quality of an exploration and the quality of the constraints that emerge from that exploration?
• How can we teach designers who are emerging from short bootcamp programs, without the benefit of years master/apprentice-style learning, to better create constraints during their design process?
• How can we make time at work for the creation of constraints, which is typically a personal and reflective process, in a context that celebrates collaboration?

And, more theoretically, I encourage design leaders to begin to consider these disciplinary questions:

• What’s the role of critique in investigating, establishing, and tearing down constraints, and how does the delayed nature of a critique experience impact the quality of new iterations?
• Are design problems more ill-structured during the “fuzzy front end” and more well-structured in the craft-based execution or delivery part of a process?
• What’s the relationship of constraints to a cultural that constantly shifts its norms, behaviors, and values?
• Are we doing a disservice to design students by teaching them to focus on ill-structured problems (with tools like Design Thinking) when they have no pattern language or craft from which to define new constraints?

Personally, I feel unsatisfied with so many questions and so few answers. As we start to ask and answer these questions in our own work, I hope our community can begin to share our answers in presentations and texts in order to help advance our collective understanding of how we design—and how we talk about this process.