Good design knows “why” – designing with rationale for traceability

"The design is an expression of the purpose." - Charles Eames

 

Decisions should be based on rationale, and you should be able to account for these decisions made during the design process.

Think back to the last application you (or your team) finished. Can you point to every aspect (feature, design elements such as icons, colors) of the application and provide rationale for its existence?

 

Ideally you would want to be able to have traceability all of the way back to needs of the users that each feature is supporting, rather than speaking about the features separately, in and of themselves.

 

The goal-directed design philosophy, started and championed by Alan Cooper, focuses on driving all parts of the design process based on goals that represent what people need and want to accomplish.

 

I've already blogged in detail about using scenarios to drive the creation of requirements (and how scenarios differ from use cases and user stories), and won't get into that level of detail here; but, at the highest level, this is the master set of activities and artifacts that you would go through following the design process I tend to use (based on goal-directed design):

 

1. User research (contextual inquiry, etc to understand the actual context of use)

 

2. Personas (who are we designing for)

 

3. Scenarios (what are the specific situations we want to design for; focus on why and what, not how things are accomplished)

 

4. Requirements (derived from the scenarios)

 

5. "Sketches" of possible alternative design solutions (that support the key scenarios and requirements)

 

6. Wireframes and Prototypes (define the layout and behavior of the design concept; some of the same decision making done here could be accomplished with Sketches above, but at this stage, we want to focus on trying out the most novel interactions to see how well they work)

 

7. High fidelity mockups (only at this point do we explore and define the visual design language; even at this stage, we are still always thinking about solving the identified problems...i.e. the scenarios that represent the needs and wants of the users, customers, etc)

 

8. Code (now, that we understand the "right design" (using Bill Buxton's terms), can we move on to getting the "design right")

 

Following these steps, all the while focusing on designing for identified needs and wants (using prioritized scenarios and requirements), and using this as a basis for software implementation (i.e. as inputs to an agile software development process), we should be better assured that we have traceability from the final design back to these artifacts as rationale.

We never just "make" things...this is what separates Art from Design...Design uses some of the same creative processes as does creating Art, but Design creates these things to support a known purpose, not to show the world the maker's interpretation of the world!

 

So, again, if I were to point out any specific element of an application your team has produced, do you feel comfortable with the level of traceability back to identified user goals?