Child pages
  • Goal-Directed Design
Skip to end of metadata
Go to start of metadata

Goal Directed Design is a user-centered methodology developed by Alan Cooper to address situations where different users of a proposed product express a desire for different things -- in short, most situations. Often, development teams can take every user idea at face value and develop a system that tries to satisfy everybody but manages to satisfy nobody. This can lead to the conclusion that listening to users has no value and that the only way to know what users will be happy with is to simply build it and correct it after user testing.

While we fully anticipate having to make small course corrections with future releases over time, we want to get as close to the right product with our first iteration. We will therefore be conducting an investigation before development or even design begins. This investigation will help us to create models of distinct, archetypical users called personas, which can help decide when a common need can be met by a common view or when distinct views are necessary.

Process

Goal Directed Design describes a six-step process for talking to users, analyzing what they say and do, and most importantly, making decisions about whether different users can be satisfied by the same interface or will require different interfaces. It includes the following steps.

Investigation Phase

1. Research: interviewing stakeholders and end users, reviewing the domain (benchmarking, literature review)

2. Modeling: Interview results are reviewed for common patterns to create models, including

  • Personas (archetypical user models): Personas are not based on a particular user, nor are they an "average" user. Instead, they embody specific behavior patterns and goals that we see during the end-user interviews. For instance, we may have two very different instructor personas, two student personas, and  persona for instructional designer, and another for a TA.
    • Primary personas: If we have more than one distinct persona in the same role, we don't smash both of their needs into the same interface, we determine one persona to design for; this persona is our primary persona. This decision is not based on who is the majority, nor is not to dismiss the needs of the secondary persona; it is a method to try to arrive at a design that will be usable by the most people. By satisfying the primary persona with a design, you satisfy the basics for the secondary persona (their specific needs can be addressed, just not often front and center). However if your design is driven by the secondary persona, you will end up with an interface that only works for that persona, while the primary persona is left confused.
    • How many primary personas?At times, you may realize that a persona is so different in what they need to do that they need their own interface. An instructional designer or TA could also represent primary personas who needs a unique view, or one or both of them may be secondary to the instructor primary persona.
  • Workflows: what do individuals do, in what sequence? How does one individual relate to another via workflows?

3. Requirements definition: these are the requirements for each persona: the data they need to see and the functional needs they have for working with this data. (as opposed to detailed requirements for developers).

We hope to get community input in step 1 and plan to synthesize this into a user and domain analysis document before the end of 2009.  For more information, see Investigation Phase. We intend to produce an investigation report at the end of this phase.

Framework Phase

4. Framework definition:

The framework is like sketching the layout for the house before detailed blueprints is created; we need to know which rooms need to be near to each other, which can be on other floors*.* It also pays to know what the future plans are for the people who are living in the house, even if we don't build out all the rooms right away. If we are designing a house for a young couple that has one child but intends to have two more kids and have their in-laws move in later, our plans may include a clear pathway and plumbing out to the side of the house where a future extension would be built to minimize disruption during a future remodel. 

Each primary persona will require their own interface. These will likely break down by role (instructor, student, and possibly another). For each primary persona's data and functional needs, we need to define

  • Data elements: what are the attributes of these data objects?
  • Functional elements: based on the functional needs, what areas do we need to hold and organize elements and what tools will need to act on data objects?

A framework shows how those functional elements relate to each other. They should be organized based on a persona's context scenarios--which elements need to be accessed sequentially or on the same screen.
We aim to complete step 4 by the beginning of February 2009 for developer and stakeholder review. This will include a description of the screens each primary persona would need to see, how a persona, in a given scenario, would walkthrough these screens, and a recommendation for which screens should be designed/developed first. Mid-February would be a good time to discuss coordination between teams at various campuses.

Design & Development Phase

After the framework has been made public, we will start creating detailed design for the most crucial screens, then proceed to the next priority. This would be similar to the prescribing the dimensions of the bedroom and bathroom, as well as their doors and windows. Development will probably follow close behind for each set of screens. It may be that Stanford produces designs that are developed

5. Design: Detailed form and behavior specifications for interface based on principles, patterns and practices.

6. Development: Coding begins based on specifications.

We will discuss this phase closer to the time it commences.

More about Goal-Directed Design

Alan Cooper began his life as a programmer, creating Visual Basic, but has become known for Goal-Directed Design, which is in used by his  interaction design firm and described in his books. If this approach is of interest to you, here's where you can read more about it.

  • About Face. While the first edition focused more on the interface design of a particular screen, the third edition has evolved to talk more about the research and analysis methods, such as personas, of Goal-Directed Design.
  • Cooper's address at Agile 2008 is a long read but clearly presented argument for how GDD can work with Agile development.
  • No labels