The Elements of User Experience
The term user experience is still constantly talked about in the technology and commerce world, but it is one of those things most people do not understand in depth. In this article I bring Jesse James Garrett's view of user experience in his book The Elements of User Experience.
For Garrett (2003), designing the user experience can seem like a hard, difficult task. However, by dividing the work of building from the bottom up, the way a building is constructed, separating elements from the most abstract, like planning and floor plans, to the most concrete, like construction and finishing, it is possible to understand the whole task better. The author also stresses that the plans are divided based on analyses of how people behave when having a user experience, and of what and how it is possible to interact with the system. This set of decisions, through interactions, "inform and influence every aspect of the user experience" (GARRETT, 2003). So by studying these layers of experience, it is possible to begin to understand how decisions are made and separated.
Garrett (2003) argues that to begin a plan above, the plan before it does not need to be fully completed, but constant evaluations must be carried out, because new things can emerge at each level about the project: what competitors are doing, how the industry is demanding better production practices, what is known about users, and so on. These decisions can have a cascading effect in both directions. The purpose of this method is to avoid future problems and risks, so that no stage is designed without understanding the stage before it and its context.See the full diagram of the elements of user experience.
According to the model, each plan depends on the plan below it. So the surface depends on the skeleton, which depends on the structure, which depends on the scope, which depends on the strategy. When the choices made in the lower plans do not line up with the ones above and below, projects can go off track, causing losses in schedule and cost, and especially when the development team tries to join components that do not fit together naturally. The worst can happen at launch, when users may reject the product.
Strategy
The goal of this stage is to define:
Product objectives and user needs
Strategy
Product objectives
Business objectives
Brand identity
Success metrics
User needs
Segmentation
Research
Development rules and processes
In this stage, field research and meetings with stakeholders (decision makers with veto power) are carried out in order to generate the project's first requirements.
This is where discovery, qualitative and quantitative research with users and customers, partners, and business and risk analyses, among others, take place.
Scope
The goal of this stage is to define:
Scope
Functionality
Requirements
Functional specifications
Content requirements
Requirement prioritization
At this point, a deeper understanding of the problem and the value proposition has been reached, so it is necessary to narrow down the ideas and define the constraints of what must be delivered. It is essential to understand the scope so you know when the task is finished.
Garrett gives two reasons for defining the scope:
1. To know what will be built: although it may seem obvious, teams often do not understand the goals of what will be built. When this is well aligned, responsibility is shared among the members.
2. To know what will not be built: many ideas come up while the features are being built, but it is important to understand the requirements, and what is meant to be solved at that moment, in order to set the scope. The product manager can decide what goes into the feature and what does not, so the rest can be delivered in the next release. This keeps the amount of work from exceeding delivery capacity within the deadline and the technical capacity. Garrett says this can work like a snowball, where each idea connects to other needs that will also have to be built, and the scope eventually spirals out of control.
Structure
The goal of this stage is to define:
Interaction design
Conceptual models
Expected and exception flows
Error prevention
Information architecture
Content structure
Language and metadata
With the scope well defined and prioritized, it is time to make what will be built more tangible. This is the stage where sketches, wireframes, flows, interaction design, and information architecture are drawn, along with the logic and how the system will behave with each interaction people have.
Interaction design (structure)
Interaction design is responsible for thinking about people's behavior with the system, about technical feasibility with the development team to create new behaviors, and about how technology can offer better solutions. The interaction designer evaluates conceptual models (the way people think) to design familiar interactions that make the product easier and simpler to use. Error handling is another point to work on at this phase: knowing what the system should do when an error occurs, how to prevent errors from happening, and how to help people get out of them.
Information architecture (structure)
According to Garrett, information architecture focuses on how people cognitively process information, and on whether the product makes sense to people.
Skeleton
In the skeleton stage, the goal is to define how the product will work.
At this point the project becomes more concrete and more detailed, and the interface components start to be developed. The skeleton stage focuses on interface design. Navigation design aims to present the spaces where information lives. Information design focuses on communicating effectively with users.
Surface
Interface design concentrates on organizing elements so that interactions between users and the product are possible.
In the surface plan, the goal is to develop sensory or emotional design, and to present the product's skeleton in a logical way.
Sensory design can draw on psychology to create predetermined sensations or emotions in the people who use the product. This can be achieved by reaching the five senses (sight, touch, hearing, smell, and taste). To make sure the product causes the sensations it was designed to cause, it is essential to run research and tests and make adjustments until the margin of error in the sensations evoked is acceptable.
There are other important points at this stage of interface design focused on sight, such as content hierarchy, elements, and contrast.
Conclusion
There are many ways to use this methodology, and the author makes clear that applying it is not a matter of time or resources, but of mindset: you need to think holistically and keep the user at the center.
This methodology has several stages that suggest several roles, but the author notes that one person can take on several roles in building the product, depending on the context.
To learn more about Garrett's work, visit Jesse James Garrett's site jjg.net.
Comments