No more requirements - hero image

No more requirements

Design doesn’t start by knowing things – it starts by discovering them. By pretending we know what a solution should be ahead of time, we’re short-circuiting the value of the work – and our own value, too.

When I began my career, I was working on small and contained interaction design problems with small and contained solutions. In one of my first professional roles, I worked on 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. Our team was made up of two of us, sitting in the same room. It was a difficult set of problems to work on, but it had very clear boundaries and edges.

Today, an individual contributor working on a project for a company like Ford still may be tasked with designing an interface for comparing vehicles to one-another. But now, they are expected to balance and be aware of design language system, multiple platforms of delivery, how an interface decision on a mobile device needs to have continuity to what a dealer sees in a real-time interaction with a customer, what a large and often distributed 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. Our influence has become larger, and as a result, there are increased expectations placed upon us. This is a maturity of the field. We demanded more responsibility, and over time, the value of design has become well recognized. We are trusted to work through complexity because we’re good at it.

But why are we good at it? What is it about a creative design process that makes designers so good at tackling ambiguous, systemic, and poorly formed problems? While 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 shares 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.

But just as 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 those who define the requirements of a problem are different than, and more important than, those who create the solution to the problem.

When we solved small problems, we could get by with leveraging boundary conditions without knowing what they were or how they worked, and could absorb requirements without sacrificing the entirety of our creative process. But in this new world, where we are expected to attack more complex problems and produce more value, we need to understand why our process works, and begin to push back on processes that are antithetical to ours. This isn’t simply because it makes us feel less important or less powerful – it’s because the requirement process makes us unable to add the full value that we are now expected to add.

In this text, I will describe what constraints are and how they work, and juxtapose them to requirements. My intent is to make a case for a unique and fundamental part of our discipline, identify a gap in how we talk about this unique part in our jobs and with our colleagues, and present an opportunity for our further delineation of the unique and valuable contributions we make to the development of new products and services.


Constraints are organic boundaries

A constraint is something artificial that acts as a boundary of a creative exploration. Creativity is, by its very definition, bounded only by laws of nature. 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 further limited primarily by our individual skills and abilities.

There are many reasons people strive to be creative. A creative process can be expressive, meaningful, emotional, fulfilling, political, and so-on. For most practicing designers, a creative process is how we solve design problems in our companies. And during the process of solving a design problem, an unbounded canvas is a hinderance, not a benefit. This is because there are infinite answers to a design problem, and none of them are right or wrong. Without boundaries, we have no way of assessing which ideas are better or worse: we have no point of comparative reference. For an artist expressing an idea, the judgement is theirs alone. For a designer making that contributes to the fundamentals of a business strategy, there must be more to determining success than the simple declaration of “I like it.”

Constraints are temporarily objective

Author Donald Schön (link, unfortunately behind a paywall) has described 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 of comparison that are erected subjectively then become objective criteria, at least temporarily, for deciding if a design decision is a good one or a bad one.

Schön’s theories are informed by his research with senior and junior architects. He observed student architects as they were in school. Architecture is primarily taught in a studio environment where students make things and professors critique and correct their work as it emerges, in real-time. Schön observed that master/apprentice relationship in action.

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, and asks the student several times, “What’s the problem?” During the example, the student struggles.

After the class has been completed, the architect reflects on the approach the student takes:

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 can see the student struggling for an organizing principle for a new creative design. Specifically, he observes that the student is avoiding a sense of hierarchy, and that hierarchy would act as a successful principle for acting as a backbone for the building design.

In this example, hierarchy is a design constraint. The master realizes that this constraint is missing. Without it, the student struggles.

Hierarchy is a bounding condition for the design. A 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 would be almost entirely set up to fail. The student would spin, and the likelihood of him arriving at a good solution would be nearly random. He would try things arbitrarily, and those things may or may not solve the problem, but the odds would be heavily stacked against him. And that’s exactly what happens in Schön’s example; the student “knits this together, hoping 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.'”

As a result of the spin, the student will run out of time. A 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, and at some point – without that serendipitous stumbling – the luxury of exploration will run out. And so the student will pick the best, or perhaps the last, solution, and move forward with it. And, without a set of constraints, the student will be unable to describe why his solution is actually a good one. He will lack language to help others see the value of the design, and he will likely resort to simply saying that he “likes it.”

Assigning a hierarchy is a declaration of prioritization. This is just 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, he could create a constraint of dominance, where one element or idea overpowers all the rest. But in all cases, the designer isn’t given the constraint, and they don’t simply declare it. They actually find it by creating it. A sketch creates a constraint, which informs an additional sketch, which informs or refines constraints, and so-on.

Constraints emerge when things are made

Author Henrik Gedenryd (pdf) views the act of designing as a fundamental part of cognition. This implies that our ability to form new meaning does not happen solely in the head, but also in the external world itself:

“…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. The result is that when these three parts work together, performance is superior to that of an intramentally organized cognition.”

Intramental means ideas produced only intellectually. Recognizing “action and world” means recognizing our ability, craft, and execution to make things as first-class citizens alongside our ability to think rationally.

This is something anyone with real creative confidence understands. New ideas and design solutions are not made by sitting and thinking really hard. They are made by making. The process of flow is a process of cognition driven largely without introspection at all; it’s a form of perceptual and motor give-and-take. Introspection often derails the creative process entirely.

Gedenryd is explaining how constraints are found and created through cognition, but not just through a traditional definition of cognition. Constraints are found and created through the process of making and sketching solutions, and those constraints then focus the next iteration of sketching. Constraints are organic boundaries to enhance creativity. This is a process that Gedenryd has called “interactive cognition.”

Constraints are inferred through sub-, or incomplete- explorations

Researcher Raymonde Guindon (pdf) explored solutions developed for ill-defined software problems by analyzing verbal protocols of solutioning from expert software developers. One ill-defined problem that was 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 complete their work, and spoke out loud as they completed their designs.

Guindon identified that the developers leveraged several approaches in developing their solution:

  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. In a sense, the things that were identified as problem rules are added to, and then changed, 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 to use in their classrooms. They were working on how a teacher explores students in their class roster to understand how the student is performing:

“So the teacher has a class of 15 or 20 students, and they probably want to see how all the students are doing.”[Using a software program called Sketch, quickly draws a screen with a list of students (in about 90 seconds), with each of their grades displayed]

[Looks at the screen critically…]

“Actually, it’s pretty busy looking. I think they wouldn’t have time to focus on all of the students – most teachers don’t have enough time to do anything. Showing them the top and bottom performing students would be useful, so she can just focus on helping the poor performers, or accelerating the top performers.”

[Sketches a new screen showing the list of students, with high performers and low performers highlighted at the top of the screen, and only showing grades for those students]

“They could see which students are doing well in their class. But if the student isn’t doing well, I would imagine they aren’t doing well in other classes, too. What if they could pivot on a student to see their other classes?”

[Adds a Show All Classes button next to each student]

“So they could click this, and an overlay would show up with the student’s information, showing how they are doing in each class.”

[Draws an overlay window with the student’s classes, showing performance in each one]

“And then, they could click on another class, and go to that class…”

[Starts to draw an overlay on top of the overlay… pauses halfway through]

“Oh, but they are already in an overlay window. So if they click the new class, are they in another overlay, or do they lose context of the student and up back in the underlay view?”

[…. thinking]

“It seems like an individual teacher cares most about how the student is doing in their own class, and knowing about how they are doing in other classes is useful, but extra. So I’ll have ‘Show All Classes’ just open a small hover window – a peak into the other classes – instead of switching to the new class entirely.”

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 highlight 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, show only the most pressing information, and 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 show the context of other classes.

Still another constraint was driven by best-practice interface design: having an overlay window on top of another overlay window is strange and poor design. This then immediately corrected – and overruled – the second constraint that had already been established. Conforming to a single-overlay-window paradigm became more important than giving a teacher a holistic insight into the student, and the designer rationalized 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. And, the constraints are in place for future design activities, until of course, they aren’t anymore.

The constraints emerged from the designer and informed the design; the design informed the constraints; the designer made a change; and so-on.

After the design session, when asked about the constraints, the designer couldn’t recreate her process or articulate all constraints concisely. She couldn’t provide a list of them. The various creative moves and scaffolds were generated so quickly that even the designer themselves didn’t really understand what was happening.

But she could offer a description of the heuristics – like showing only the most important information, because teachers are busy – as she walked through the artifacts she had developed. And the constraints that she used and didn’t alter become “baked into the design,” and into her brain. Interactive cognition has led to plain old cognition and memory. Her future design activities, presuming they occur while these ideas are still recent and active, will work to keep these constraints as consistent as possible, or she will need to go back and make retroactive changes based on the new constraints that emerge later.

A summary view of constraints

Based on the above ideas, and my own experience of 20 years of designing and close to 20 years of teaching design, I view constraints and the constraint definition process as having these qualities:

Emergent, based on the act of making things. When designers make artifacts, such as sketches or diagrams, they are exploring ideas. Some of this exploration “feels” right enough to become elevated to a new rule. The rule then becomes a new constraint.

Built up, and torn-down, in seconds. During the exploratory process, the new constraints that emerge from one exploration immediately impact another move in the design process. Sometimes, those constraints are viewed as detrimental to forward progress, and in those cases, the constraints are immediately rejected.

Informed by patterning experience. Mature designers are identifying and establishing 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, so they can react to them – and accept, or reject new constraints – in the moment of exploration.

Requirements are assigned boundaries

Those of us who work in a professional context constantly come across the idea of a requirement. A requirement is typically defined before a creative exploration begins. A requirement is something that the business has deemed to be a necessary piece of a solution – the solution is “required” to have that component, rule, or function, and if it doesn’t have it, the solution is rejected as being incorrect. 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 requirement definition 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. Someone – often a business analyst or product manager – will hold meetings with people throughout a company and list all of the different things people have decided are non-negotiable parts of a new design. They then write these requirements in a list, and that list then acts as a checklist for assessing if a project solution is defect-free.

There are best-practices and established ways for writing these requirements. One of these best-practices is to make sure it’s easy to measure if the requirement need has been fulfilled. This measurement should be quantifiable and objective: it should be crystal-clear if a solution checks the box of a given requirement.

For example, in the Business Analyst’s Handbook (pdf), readers are instructed to use the “SMART framework” for writing these requirements. Requirements should be:

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

Additionally, the handbook describes that requirements should delve beyond SMART to also be

  • Unambiguous
  • Correct
  • Consistent

Requirements are assigned boundaries. They are defined ahead of time, and defined by people who may or may not be responsible for actually designing the solution. They are defined as a checklist to measure against the solution, and to judge if the solution does, in fact, solve the problem: the problem is defined by the sum of the requirements, and the sum of the requirements is the solution.

The problem with conflating constraints with requirements

Defining requirements ahead of time means that the limitations of a solution are known ahead of time. The language of requirements – that they should be achievable, and measurable – implies that a solution should be risk-free. For a purely engineering-based solution (like manufacturing), execution risk would mean functional failure, and is something that’s considered unacceptable. But in design, risk is inextricably tied to novelty, which is inextricably tied to innovation. If a new idea is risk-free, it is, by definition, not an innovation: it’s been established to such a degree that the adoption or engagement unknowns have been driven out of the system. Risk-free is a good place to be for many businesses and business problems, because they are providing commodity products and services, or are trying to incrementally improve existing offerings, or they are delivering mission-critical systems where the expectation is 0% failure (such as a missile control system). But in contexts where companies are trying to drive a market, a high level of creative risk is fundamental.

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 often incorrectly used interchangeably.

Requirements Constraints
Specific General (Heuristic)
Measurable (verifiable) Mutable (transient)
Achievable and Appropriate Freeing
Realistic and Relevant Exploratory
Timely and Time-bound Temporary

Additionally, goals should delve beyond SMART to also be

Unambiguous Negotiable
Consistent Always changing
Correct Subjective

Defining requirements ahead of time means that the limitations of a solution are correct and fixed. The word “correct” is an interesting one because it implies that there is a right answer to a problem. That’s puzzling in the context of most products and services. What is a “correct” vehicle aesthetic, or a “correct” banking mobile experience, or a “correct” experience 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. Once the requirement process has been completed, those requirements become the law. But in the process of working through a design solution, a designer often discovers that requirements written in absence of form-giving don’t actually make any sense. As a real example, a bank’s Legal team may have defined a requirement that “Every customer must see and agree to an end-user agreement, recognizing that their investment accounts are not FDIC insured.” But a customer may not have an investment account, and may only use the bank for checking and savings. During design, the designer will likely 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. But if requirements are, in fact, required, that decision is rejected as an incorrect solution.

Most importantly, defining requirements ahead of time means that someone already knows the scope of the solution. If someone, or a group of people, is able to articulate comprehensive requirements for a solution before any creative solutioning has begun, it means that they already know what that solution is and they just need a set of hired hands to go build it. This is not necessarily a bad situation to be in. Many problems are so well-formed that they don’t need real creative exploration at all. Solutions that emerge from a non-creative process will typically present as tablestakes – they will mimic existing solutions, and provide customers with expected and straightforward value. Defining requirements ahead of time means that 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 react negatively:

I don’t have enough time to do my work, because my work is about exploration, and exploration appears non-productive. In a context of requirements, exploring a new idea seems aimless or a poor, and poorly structured, use of time. Why explore, if the direction has already been established? Exploration defines constraints, but it appears that new constraints aren’t necessary when presented with a checklist of requirements. The time necessary 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, most designers 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 a valuable. Design will be seen as a roadblock, and designer’s work seen as a negative part of the overall process.

I don’t have autonomy to do my work, because I’m viewed as an execution arm. When designers are handed requirements, they are also handed a mandate: do as you are told. Few people like to be told what to do. It feels, and is, condescending. 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, we are just a puppet.

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 perceived needs of a customer, or from a view of a business environment. But the reason behind the requirements is often lost, and so the designer, now framed as an execution arm, doesn’t know why they are being asked to do the work they are doing. Often, requirements seem illogical without 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 do things that often seem crazy or without basis.

I don’t see a 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, as they were gathered in isolation from a variety of sources and stakeholders, and represent a variety 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, doing their best work and with best intentions, is likely to end up with a solution that feels haphazard or incomplete.

In the worst case, a design 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 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.

The point: we need to champion constraints, but we don’t know how

We need to find a way to explain to our colleagues that the established, recognized, respected, and well-documented practice of establishing requirements is a bad way of designing products and services. Constraints, not requirements, are the creative language of design, and should be encouraged instead. 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 in a theoretical way in order for it to be acknowledged as a legitimate difference. And that presents a large challenge for designers who understand this difference, but only understand it intuitively, or aren’t crisp in their ability to describe the difference. I fall into both categories: I’ve written 5000 words here simply to grapple with understanding this idea myself, and it’s far-fetched to imagine handing this text to a busy leader and expecting them to read it.

I think this is the largest problem with constraints. While there are infinite texts written and classes held on the value of requirements, there’s so little discussion about constraints. We have little to stand on when trying to present the value of constraints as a conceptual idea, as well as the development of constraints as a process.

It’s unrealistic and juvenile to expect to bang our fists and demand change. 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. I encourage design leaders to explore and begin to answer some of these practical questions:

  • How can we clearly describe the idea of constraints, and our specific constraints, and where these constraints came from, when we present a solution to stakeholders?
  • How can we explain that we ignored a requirement 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 of deep master/apprentice style of learning, to better create constraints during their creative 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 collaborative work?

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 those new constraints?
  • 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 leverage in defining new constraints?

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, and help advance our collective understanding of how we do our jobs.

Jon Kolko

Modernist can help you build a design culture around constraints.

Get In Touch

Related Posts