The most crucial measure of success for a design project is the degree to which it serves its intended goals.
Projects come about because an organization invests time and resources in changing something in the world; it could be migrating a key system to a new platform or launching a website to sell a new product. More often than not, designers are brought in to “spruce it up.” Alas, they often join the project too late, when major decisions have been made.
It’s a mistake — but understandable. Talking about look-and-feel is easy; talking about fitness-to-purpose is hard.
It’s hard for several reasons:
- Teams are too close to the problem. They’ve internalized the conditions that led to the creation of the project and don’t ask “dumb” clarifying questions.
- Teams are siloed. They see only their piece of the problem; it’s unclear who’s responsible for objectives that bridge several departments.
- Research is “expensive.” Stakeholders don’t see why they should invest time and money towards understanding the context.
- Goals are ambiguous, misaligned, or misunderstood. Teams may be driven by easy-to-measure metrics rather than more relevant indicators.
- Screens are sexy; diagrams are boring. Stakeholders are drawn to invest in “actionable” artifacts, i.e., those that can be handed to developers for implementation.
More broadly, many stakeholders conflate design with interface design. As a result, they may wonder why designers should care about this stuff at all. We care because design has a broader and deeper remit: achieving “good fit.” As Christopher Alexander put it,
We are searching for some kind of harmony between two intangibles: a form which we have not yet designed and a context which we cannot properly describe.
We achieve fit by making both form and context more tangible. We synthesize research to clarify the context. We create artifacts that allow us to test intended interventions. These tests, in turn, reveal new aspects of the context. The better we understand the context, the more apt the forms. The more apt the forms, the better we know the context. We iterate to bring the two closer together. A virtuous cycle ensues.
But the process must start with a clear direction. Or rather, without clear direction, teams will iterate aimlessly, wasting time and resources. At a minimum, teams must understand the project’s goals, the environment in which it’ll exist, the people who will use it, material, legal, and time constraints, etc. — even if at first these are only hypotheses to be tested.
Projects rarely start with such clarity. More often, early stages are a muddle. The first step is clarifying the direction as much as possible. When engaging with teams in these situations, I often ask questions such as:
- Who are the target users? How much do we know about them?
- What tasks do they seek to accomplish?
- How would accomplishing those tasks support their goals?
- How would accomplishing those tasks support our goals?
Often, there are no clear answers for one or more of these questions upfront, which prompts another one:
- How will we learn what we don’t know?
We want to start moving. But we must first get clear on where we’re aiming. Because without clear direction, designers are relegated to making superficial and/or local interventions. The final result may blow everyone away with snazzy visuals and clever interactions, it may even win awards — but fail in meeting its goals.
Meeting goals is more important. Start by clarifying the big picture.