Chapter 4 from About Face should start off on comfortable ground for us because it covers scenarios, narrative, story-like descriptions of a user’s interaction with a product. We saw these well in I300, and we should be familiar with this material. The main new wrinkle is that personas are emphasized more in goal-directed design than they were in user-centered design. So personas get to be the actors in the scenarios here, and that was optional in I300.
Cooper calls them “context scenarios” instead of just “scenarios”, but they mean the same thing. We can use either interchangeably in I441. The full phrase context scenario is useful, for it reminds us of one of the critical roles a scenario can play. Scenarios can give a designer a clear idea of the environment (i.e. the context) in which the interaction is occurring. So designing based off of the scenario keeps that context at the forefront of the designers mind. When creating the context scenario in the first place, the designer had to think about and then articulate the expected context of use for the product.
Always be able to define the context(s) in which the personas will use the product
When reading this chapter, you may also notice that Cooper mentions two other kinds of scenarios, key path scenarios and validation scenarios. We’ll cover key path scenarios in more detail in the next chapter’s notes, and we’ll mention validation scenarios only briefly in class.
Problem and Vision Statements
To be able to determine the context of use and then create context scenarios, research and analysis of that research must have already occurred. Cooper also recommends a few other steps in between research and creation of context scenarios. His process is shown in Figure 4.1.
Problem and Vision Statements
We can see that Cooper’s first step is to create two design artifacts, a problem statement and a vision statement. Both statements are short (few sentences or a paragraph) written descriptions. The problem statement is primarily from the perspective of the organization behind the product, but it needs to also connect the business needs to the users’ needs. The vision statement is from a different perspective. It needs to be more user-focused than organization-focused, and it needs to articulate a goal or objective that the design can solve.
This page gives a good overview of this material from About Face and mentions how the Problem and Vision Statements are used to “define what direction these scenarios and requirements should be headed in”. The problem statement maybe doesn’t do as much of this heavy lifting as the vision statement does. This page gives some good insights into problem statements but is squarely user-focused. Since Cooper’s problem statements describe the problem from other stakeholder’s point of view, they may not be solely user-centric. This page might give the best advice for writing problem statements since it provides specific starting questions that can lead to problem statements like “How might we ….?” They give an example
- How might we make users pay more attention to the Ads we installed?
- How might we make Ads more engaging and immersive experience?
This is a good starting point for writing a problem statement. The problem these questions address is a need to design a way to get more attention paid to Ads. A problem statement just needs to summarize that in a short amount of space. The solution to the described problem would be whatever is designed. The vision statement would provide the starting plan or ideas for creating that design.
Let’s imagine a department store attempt to increase user engagement with its mobile apps during COVID times. The apps already exist, so this a redesign project instead of a design, but the same process applies. Here is a potential problem statement:
Brand X is attempting to increase user engagement with its app during the pandemic. Store sales are down although we offer many of the products people search for while providing curbside service and other conveniences.
Note that there’s not really anything about the users in this one. We’ve done OK describing the business need, but we haven’t connected that to the user’s yet. These statements are created AFTER research has occurred, so we should have research to back up our assertions about users.
Brand X is attempting to increase user engagement with its app during the pandemic. Store sales are down although we offer many of the products people search for while providing curbside service and other conveniences.
Customer surveys have revealed that it’s difficult to determine in-stock items before visiting the store and that it’s difficult to find unfamiliar items in the store. Many customers were not aware of the curbside option.
In either case, the problem is defined so that design solutions can be considered. A Vision Statement can direct that process.
Users searching for a product should always have access to stock information (in-store availability). If the item is available, users can opt for curbside pickup or to see items’ locations on a floor plan of the store. Customers will always know what’s available and where to find it.
The Vision Statement doesn’t say exactly what the user interface will be. Instead it describes a potential design path and more importantly a concept: “Customers will always know what’s available and where to find it.“
Context Scenarios
There’s not a whole lot to write about context scenarios since we know what they are. The important points to mention (that Cooper also mentions in the text) are that
They should not describe product or interaction detail but rather should focus on high-level actions from the user’s perspective.
Alan Cooper, About Face, Chapter 4 p 113
Directly below the above quote Cooper also provides a useful list of questions or issues that context scenarios should address.
Requirements
Design requirements are the list of constraints the design solution must satisfy. They are created based on an understanding or user’s goals and needs as well as the tasks they must complete to accomplish those goals. They should be written from the user’s perspective (i.e. describe something the user should be able to do) in contrast to software requirements (i.e. what the app can do) which are written from the app’s perspective. This is mentioned in case informatics students have seen software requirements before.
There are different categories of requirements which will make more sense after we have read the next couple of chapters.
- Data requirements – relating to the objects the user interacts with
- Functional requirements – relating to the actions of the app
- Contextual requirements – relating to the environment in the app or the environment the app is used in
The idea of context is a powerful one. We’ve mentioned earlier that Context Scenarios provide a description of the user using the product in its intended context (surroundings)/ We can also think of a product as providing different contexts that the user interacts with. An email app may provide a message list context, a view message context, and a write message context. Each of these contexts may give rise to their own set of requirements.