In software development, we should focus on the goals of the users who will interact with our product. In most cases, in the very beginning our user doesn’t exist yet, so we need to prototype characters who look like our potential customers. And to imagine how the character behaves with our product, we form context scenarios, because they allow to identify the goals of potential users and to convert them into specific prototype interface solutions.
So, we need to define WHAT the product will do before we design HOW it is going to do this. This process consists of the following five steps:
1. Creating problem and vision statements
3. Identifying persona expectations
4. Constructing context scenarios
5. Identifying requirements
Creating problem and vision statements
The problem statement defines the purpose of the design initiative. Before beginning the process of ideation, it’s important for designers to have a clear mandate for moving forward. While the Goal-Directed method aims to comprehensively define the product through personas, scenarios, and requirements, it is often useful at this point to define what direction these scenarios and requirements should be headed in.
Before prototyping: Brainstorming
At this point in the project, we have been researching and modeling users and the domain for days or even months, and it is almost impossible to avoid having developed some preconceptions about what the solution looks like. The primary purpose here is to eliminate as much preconception as possible, allowing designers to be open-minded and flexible as they use their imagination to construct scenarios, and use their analytic minds to derive requirements from these scenarios. Don’t spend too much time on the brainstorming step. A few hours should be more than sufficient for you and your teammates to get all those crazy ideas out of your systems. If you find your ideas getting repetitious, or the popcorn stops popping, that’s a good time to stop.
Identifying persona expectations
People’s expectations about a product and the way it works are highly informed by their mental model. A person’s mental model is their own internal representation of reality— the way they think about or explain something
to themselves. The represented model of the interface — how the design behaves and presents itself — should match the user’s mental model as closely as possible, rather than reflecting the implementation model of how the product is actually constructed internally. In order to accomplish this, we must formally record these expectations.
– Attitudes, experiences, aspirations, and other factors that influence the persona’s expectations
– General expectations and desires the persona may have about the experience of using the product
– Behaviors the persona will expect or desire from the product
– How that persona thinks about basic elements or units of data (for example, in an e-mail application, the basic elements of data might be messages and people).
Constructing context scenarios
While all scenarios are stories about people and their activities, in the design processes we should use the context scenarios. They are used to explore, at a high level, how the product can best serve the needs of the personas. As we discussed above, this is where design begins. As you develop context scenarios, you should be focusing on how the product you are designing can best help your personas achieve their goals.
Context scenarios address questions such as the following:
In what setting(s) will the product be used?
– Will it be used for extended amounts of time?
– Is the persona frequently interrupted?
– Are there multiple users on a single workstation or device?
– With what other products will it be used?
– What primary activities does the persona need to perform to meet her goals?
– What is the expected end result of using the product?
– How much complexity is permissible, based on persona skill and frequency of use?
In most cases, more than one context scenario is necessary. This is true especially when there are multiple primary personas, but sometimes even a single primary persona may have two or more distinct contexts of use.
Context scenarios are also entirely textual. We are not yet discussing form, only the behaviors of the user and the system. This discussion is best accomplished as a textual narrative.
Identifying requirements for prototype
After you are satisfied with an initial draft of your context scenario, you can analyze it to extract the personas’ needs or requirements. Having performed these steps, you should now have a rough, creative overview of how the product is going to address user goals in the form of context scenarios, and a reductive list of needs and requirements extracted from your research, user models, and the scenarios.
Now you are ready to delve deeper into the details of your product’s behaviors, and begin to consider how the product
and its functions will be represented.
To read more about the design principles we use in our work, click here.