A Taxonomy of Constraints
Maybe it’s just the projects I’m working on, but I feel like I’m using the word “constraints” a lot.
(That sounded a lot more bitter than I intended.)
It’s a word we’ve been throwing around, but experience shows there’s considerable nuance to it. Shining a light on these constraints may help us better understand the boundaries in which we must operate, and help us spell out the requirements for a project.
Nathan is working on an essay about design standards, and he’s taking a more thorough look at how designers and organizations should relate to them. Standards may be a way of dealing with constraints, or a constraint in and of themselves, but there are other pieces to the framework that bear spelling out.
What is a constraint?
Constraints are inputs into the design process that make designers are focused on solving the right problem. The design process depends on exploration and iteration, two things that can take designers further away from appropriately solving the right problem. Constraints allow us to evaluate the output of our design process to make sure we achieved our objectives.
What I’m most interested in, though, is a taxonomy of constraints. What are the specific things that establish boundaries and provide a means for validating design?
Designers who subscribe to user-centered design philosophy prioritize user research perhaps above all others. In short, user research yields a set of expectations–what users would like the product to do. As we produce design ideas, we can compare the idea to user needs. Doesn’t address a need? The idea dies.
Most of my work these days involves designing web sites to meet a specific business objective. Sometimes it’s hard for me to relate the business objective to any other constraints, but that’s the nature of the organizations I’m working for. The project is a small piece of a larger machine. Depending on the piece and the machine, failure of the part may or may not mean failure of the whole. Regardless, these constraints can sometimes seem arbitrary as they serve some abstract objective and not a concrete requirement driven by users.
As much as we don’t like to admit it, there are external (and again, seemingly arbitrary forces) that scaffold the design process. Most explicitly, these are deadlines that confine the range of activities we can perform in order to conceptualize and flesh out a design. Less explicitly, these may be the whims of project stakeholders and other team dynamics.
Though technologists are fond of saying “We can make it do anything,” the truth is that most design work happens in the context of existing systems. These existing systems come with capabilities and configurations that make some design ideas more feasible than others. The sometimes unsaid extension to the technologists’ mantra is “We can make it do anything with sufficient time and budget.”
Just as the technology provides a context for a design idea, so too does the organization that will support it. There are people behind every technology, having to provide support in everything from customer help to content updates. Without the infrastructure from an operational perspective, some design ideas will not be successful. To thrive, a design must acknowledge the organization that will support and maintain the final product.
Otherwise knowns as “best practices,” these conventions emerge after withstanding the test of time. Used widely on other web sites, such standards become constraints in so far as they establish a baseline from which other design decisions extend.
This is where Nathan’s essay will come in. Establishing standards specific to the organization is a complex process with numerous benefits. Suffice it to say that from the designer’s perspective, standards provide a range of starting points for solving problems. Positioning and integration into the design process is crucial: done poorly, these constraints come across as creativity-killers.
A good team will summarize their direction in a single theme or collection of bullet points. This direction is specific: “make it easy to use” gets eliminated as a principle pretty quickly, for example, because it isn’t specific to the project and is common to all our projects. Instead, design principles are specific and meaningful to the team working on the project. They are means for making design decisions.
They are, in a sense, a super-set of all other constraints. I didn’t really think about this until now, but teams compose design principles when they want to boil down everything they’ve learned from all the other constraints.
Constraints are good
I don’t know if this–design decisions within a framework of constraints–is the right way to look at design. I can’t imagine Steve Jobs making a list of constraints before sketching out the Next Big Thing. On the other hand, design doesn’t end with a concept. Myriad other choices go into realizing a vision like the iPod. No doubt constraints play a role in mediating these other decisions.
Here’s the thing: I like constraints. They define a design problem. They help me understand what success is. They let me collaborate efficiently with other team members who share an awareness of the project’s boundaries.
Some ideas on exploring constraints further:
- Prioritization: What process do we use to prioritize constraints? Is there a Maslow’s hierarchy for constraints that implies which things are most basic and which are less necessary?
- Distinguishing from requirements: What’s the difference between requirements and constraints? In short, requirements state the problem and constraints are a tool to help me solve the problem. Can the distinction be more nuanced than that?
- Managing conflicts: How do project teams deal with conflicting constraints? Presumably these conflicts are ironed-out at the beginning of the process, but in practical terms, I suspect this does not happen formally until the conflicts arise.