In some sense I300 covered the user-centered design process (UCD). Early in the course we saw a diagram illustrating the process (reproduced below), and then we focused on parts of that process bit by bit learning how users thought, how to create certain kinds of designs, and how design artifacts could aid that process in both big-picture ways (personas and scenarios) and in detailed ways (use cases, hierarchical task analyses). Once we had a design we learned how to evaluate it with usability testing or expert evaluation (cognitive walkthroughs and heuristic evaluation).
Chapter 1 of the I441 textbook About Face by Alan Cooper introduces the Goal-Directed Design (GDD) process. We’ll use this design process as a scaffold for most of what we do this semester, reinforcing things we saw in I300, filling in gaps for things we didn’t get to see, and seeing completely new things, too.
In the past, I’ve provided skeleton outlines of each chapter of About Face to help students focus on the key ideas. Here is that outline for chapter 1:
- Problems with digital products (know what is meant by each or give examples of). pp. 4-5
- They are rude
- They require users to think like computers
- Goal vs tasks and activities – what’s the difference? p. 14
- Implementation models are one kind of bad design. What is meant by the term? Examples? pp. 16-17
- The difference between implementation models and users’ mental models
- Goal-Directed Design Process
- Stages: Research, Modeling, Requirements, Framework, Refinement, Support See beginning p. 23 – 30 where overview of each stage and its key design activities or outcomes/deliverables are described
This semester I will attempt to go into more detail in these lecture notes, so here goes…
Goal-directed design boils down to designing products or user interfaces that exist to help the users achieve their goals on their terms. Products that confuse users or do not speak the same language as the user are not helpful products. It’s helpful when designing to think of the things you design as having a personality. Ideally that personality would be courteous and helpful in the same way an assistant who helps you complete a project could be. An assistant who is not helpful and deliberately insists you bend to their terms is essentially being a thoughtless, rude person. Devices are no different; badly designed ones are often rude the way they communicate with users and force the user to adapt to their terms instead of the other way around.
One of Alan Coopers famous designs (and implementation) is Visual Basic which gave users a Graphical User Interface (GUI) with which they could create a user interface while the program generated the code behind it.
Visual Basic worked then much the same way it does now. The user manipulates the user interface by dragging widgets (user interface elements) to the canvas (blank area for creating upon representing the app’s window). The direct manipulation continues as the widgets can be resized and moved with the mouse. An alternate mode using the instructing interaction type allows the user to edit properties of the widgets and move and size them that way with pixel-perfect precision.
The alternative method back then of creating a front end to an app involved programmatically defining the widgets and setting their location on the screen either by assigning values to properties or via method calls. In some cases, the order in which the widgets were instantiated would determine how they would have tiled or packed together in the app’s windows. Some expert programmers would not mind or perhaps even prefer to generate front ends this way. Many programmers and anyone who is not a programmer would not be skilled enough to create a user interface via this path. The goal of these users is to create a user interface. It is not to think in Visual Basic, Java, Python, or C++ terms about how to define GUI widgets. By allowing the user to directly manipulate the thing they are creating, the design is able to support the user by matching their mental model more closely and providing an intuitive interface with immediate feedback about the state of the end result.
Goals, tasks, activities
A goal-directed design process for user-interface creation would identify that goal and then carry out research to understand the users goals and the activities they would need to complete to accomplish those goals. Note that the user does smaller things, activities, to accomplish a bigger thing, the goal. We can related this idea to the Seven Stages of Action from I300 where we saw the user will formulate a plan to achieve a goal. That plan will break the goal up into smaller parts, and then the smaller parts get broken up even more into individual actions that the user executes. (The quote from About Face is that “Norman describes a hierarchy in which activities are composed of tasks, which in turn are composed of actions, which are themselves composed of operations.”
Cooper provides the helpful rule that goals change very slowly, if at all, over time. One of my goals this in I441 semester may be to grade an assignment. I had the same goal a year ago when I441 was offered, but this year there is COVID and no physical papers to hand in. A year ago I would have carried out different activities (sorting papers, sharpening my red pen, etc.) to accomplish my goal than I will this year (clicking mindlessly through Canvas screens as I start to drool). The activities changed but the goal hasn’t.
Cooper also wisely underlines that identifying understanding goals are important because they hold the clue to why a user does something while activities or tasks may only hold the answer to how they do things in one specific context. Cooper still uses activities and tasks. Once again, they are carried out to help a user accomplish a goal, but goal-directed design is focused first and foremost on understanding the goal and then working from that premise.
Goal-Directed Design Process
Figure 1.7 of the text shows the steps of the GDD process:
- Research users and the domain
- Modeling users and the context
- Requirements Definition – define user needs, business needs, and technical needs
- Design/Framework – the “structure” of the design
- Design Refinement
- Design Support – ongoing work as development happens
Figure 1.8 provides more detail and a great overview of the process:
The chart above is helpful for most of the semester (don’t forget about it) because it gives us a roadmap for the GDD process. We can see what kinds of research we will carry out as well as what the results of modeling are. We can recognize or learn about some of the design artifacts (personas, context scenarios, and key path scenarios) we’ll be creating. We can also just refer back to this for the sequence and the breakdown of each step to use as a checklist as we learn this process and create and document our designs with it.
It’s helpful to compare GDD with UCD. Let’s make a table to do so!
| UCD | GDD |
|---|---|
| Research | Research |
| Analysis | Modeling |
| Requirements Definition | |
| Design | Design/Framework |
| Prototype | Design Refinement |
| Deploy | Design Support |
In my infinite wisdom I spaced out the UCD entries, in particular first recognizing that both processes begin (research) and end (support the ongoing product) the same way. At that point, we can recognize that the tell-tale iterative cycle in UCD Analysis -> Design -> Prototype is representative iterative refinement and not a complete re-do of the cycle each time. With that observation it makes sense to match up Prototype with Design Refinement. After that, I’ll just wave my hands and say that Design in UCD matches up with Design in GDD (makes sense!) and that if we recognize that writing down requirements is a kind of analysis (because it follows from the results of research, then we are done! The two processes are essentially the same although the names differ some and the UCD Analysis step is broken into the two GDD steps Modeling and Requirements Definition.
As we go forward this semester, we’ll describe interaction design in terms of this new process, but we can recognize it’s one we’ve seen before, so what we’re doing is iteratively improving or refining previous knowledge we gained from I300. That’s what we should be doing!