The Briefing consists of a workshop done in-person or virtually, usually lasting one to four hours or multiple days for more complex products.
When the product design process starts, the product owner will either have a vague idea or a detailed vision of the desired product. The role of the UX Designer at this stage is to understand all the existing client requirements and relevant information to understand the product context. Ask the product owner to present any documentation or references needed to understand all business requirements.
Adopt a critical attitude towards the requirements provided by the product owner and try to understand their motivations. For more detailed requirements, consider deconstructing them and challenging their ability to satisfy user needs. This makes it possible for the product team to find more user-friendly ways of achieving the same goals, lowering implementation and maintenance costs.
Personas are written documents describing fictional but realistic characters that model existing and potential users. The Goal Oriented Persona methodology constructs each Persona with demographic information, context, goals, frustrations, and behaviors.
What distinguishes the Goal Oriented Persona from other approaches is the relegation of demographic data and the user context to a secondary level, focusing primarily on goals and needs.
User Research guarantees that the product requirements are based on data rather than assumptions, thus assuring the product is successful in the most fundamental dimension of usability. Ideally, User Research should be included throughout the design process, but definitely at the start to allow for more significant risk reduction. Further iterations in the product will only be at the level of the interface details and not the level of the product concept and its functional requirements.
Avoid Personas based on stereotypes and assumptions when using this technique. There are three main risks that Personas allow us to avoid: the elastic user, self-referential design, and edge cases. When used properly, Personas provide a crucial base on which to establish a product’s requirements and ensure its usefulness. Personas drastically reduce project risks and help the team avoid wasting resources developing a concept for which the user would see little utility.
Have a clear idea of how to address the user with the product and solve their issues. The stages of building a realistic Persona include collecting information, compiling information, building the profiles, and prioritizing the profiles.
The Design Benchmark consists of a document summarizing the functionality offered by existing products operating in the same market, their position and communication style, and their information and iteration display patterns. Ideally, these should be represented with images, annotations, and graphics. A Cartesian Graph is a great tool to determine a space in the market where a new product could be successful.
A product does not exist in a vacuum. It inhabits an ecosystem shared with competing products that have established their position and target the same audience.
Design Benchmark analyzes the landscape and the characteristics of similar products to understand if there is space in the market for a new entry, innovation potential, and how to present the product in development.
Objectives of the Design Benchmark are to understand the minimum quality standard expected by users and which of their needs, identified in the previous step, are not yet satisfied through available products. This will come in handy during the Decision Matrix, helping to establish the minimum functionality the product must offer and what features should be highlighted.
Consider how existing products position themselves regarding business goals and communication style. Seek to understand how they address users and which communication styles might impact them. Design Benchmark identifies the interacting structures and GUI of existing products, thus providing options for solving eventual iteration, navigation, and hierarchy conflicts.
Four types of products should be given special attention...
1. Direct competitors.
2. Products that target the same user end goals.
3. Products that address different end goals but target the same users.
4. Products that deal with data similar to what is expected of the product.
Once this list is complete, consider...
1. Available features
2. Positioning in terms of value and communication style
3. Information and interaction display patterns.
Instead of making an exhaustive list of features, observe which ones are common amongst the products and which are unique. Understand the highlighted features and the product’s communication style, observing both the interfaces and the platforms on which they are being promoted.
User Journeys consist of Persona-based scenarios merged with insights from two other frameworks/models: The Pirates Metrics framework and the Hook Model.
Envision how Personas will get to know the product and start using it, in what contexts they will use it, what tasks they will perform, and how to make them repeatedly return to the product.The objective is to create a cohesive and simple experience, so users do not feel lost at any point, incentivizing them to prolong product usage.
Persona-based scenarios are “concise narrative descriptions of one or more Personas using a product or service to achieve a specific goal ... using a story to describe an ideal experience from the Persona’s perspective.”
User Journeys are akin to epics, which focus on the function and presentation of the interface rather than on user behaviors. User Stories, or Use Cases, focus on the different tasks a user can do with the feature.
Pirate Metrics are a quantitative framework used to evaluate a product’s performance.
Pirate Metrics Stages:
Acquisition: To acquire a user. For a SaaS product, this usually means a signup.
Activation: The user uses the product, indicating a good first visit.
Retention: The user continues using the product, indicating they like it.
Referrals: The user likes the product so much that they refer it to other new users.
Revenue: The user pays for the product.
The Hook Model is a framework that covers the elements needed to lead the user to use the product for the first time and repeat the experience regularly.
Trigger: The trigger starts the process and prompts the Persona to try the product. The internal trigger is the Persona’s emotions or feelings rooted in basic human needs that will keep them hooked long term.
Action: The behavior of the user.
Reward: “What distinguishes the Hook Model from a plain vanilla feedback loop is the hook’s ability to create a craving. Feedback loops are all around us, but when predictable, they do not create desire…However, add some variability to the mix, and voilá. Variable rewards are one of the most powerful tools.”
Investment: The user provides input to the product, such as time, data, effort, social capital, or money. It implies a task that improves the service the next go-around.
Include each of these metrics in the User Journey along with the user’s mood and emotions each time they are expected to change. Describe all tasks and transitions to create an outline of a journey the ideal user will undertake from the moment they get to know the product until they achieve their desired goals.
The Decision Matrix consists of a list of all features extracted from the User Journey, organized in epics and user stories, and rated according to the user and business goals.
The Decision Matrix narrows down previously generated ideas that explored various possibilities and highlights a single approach. Features need to be prioritized so that the team can build a working product that can be released and tested as soon as possible while also addressing the users’ needs. This is known as a Minimum Viable Product (MVP), an expression coined by Frank Robinson in 2001 that was popularized by many others in the following years.
MVP will be designed to work with and without certain features, ensuring that no screen or navigation path breaks if the team does not implement low-priority features.
1. List: List all epics and write down the user stories. Play with the levels of complexity for each user story.
2. Rate (according to user goals): Prioritize the user stories according to user goals using a scoring system. Then, give different weights to each Persona according to their priority.
3. Rate (according to business goals): Use the Pirate Metrics framework to rate how important each user story is to accomplish, considering the stage of the product’s development.
4. Check (product usefulness vs. business model): Take the average of both scores to see each user story’s priority level.
The wireframes are the screens’ skeleton. They are the layout without styling and only a high-level black-and-white sketch.
The Wireframes are a quick way to experiment and show different options to stakeholders, helping validate all the mentioned aspects of the product. They deliver higher quality products by reducing structural changes in the final designs.
Wireframes emphasize elements including navigation, architecture, content, and information hierarchy.
They make it easier to find structural solutions to design challenges that would otherwise demand too much visual styling.
The Wireframes should cover all the main screens:
1. Navigation and sub-navigation.
2. Textual and multimedia content in the final sections.
3. The complete list of forms and fieldsThe final layout (final positioning of various content sections)
The Mood Board consists of a canvas that gathers various inspirational materials, communicating the values and emotions the product should convey.
The Mood Board tests different visual approaches and allows the designer to communicate abstract concepts to stakeholders.
The construction of a Mood Board is the analysis of experience goals (User Research) and positioning (Design Benchmark) to determine which emotions and state of mind the product should impart to the user.
Present two or more Mood Boards representing the same values and emotions but with visually different approaches to clarify concepts and obtain an aesthetic direction. It’s essential to draw upon a diverse pool of resources, going beyond the industry and even the medium in question when practicable.
The Style Guide is a document or file that compiles various stylized GUI elements and functions as a style library. This typically includes the color palette, typography, elevation, states, components, and relevant iconography.
One of the most important aspects of a good user experience is the interface’s consistency throughout its various sections, pages, and interaction points.
The graphic style of each element provides fundamental indicators to the user.
For instance, they point to the current location in the application flow, direct attention to the most relevant information, and emphasize clickable items. Consistent style patterns throughout the product allow the user to perceive information more quickly and with a smaller margin for error. This results in an easier, faster, more fluid, and more reassuring user experience. Knowledge of Color Theory, Gestalt Principles, and composition rules is helpful for this step.
The GUI consists of various editable vector files and one or more PDF files with an export of the editable files that contain the main pages as they would appear in the final product.
The product’s pages are created with their “final” appearance, in other words, the appearance that the user will see.
The GUI a combination of the Wireframes and Style Guide. These final screens are presented to stakeholders for approval before proceeding to the development phase.
It helps front-end developers interpret the interface, guiding them through implementation.
The Prototype is a “click-through,” meaning that it is not dynamic, nor can it process any data. However, it allows the team to simulate navigation from page to page. The execution of this type of Prototype does not require any code because it can be done using applications such as InVision.
A clickable Prototype makes the navigation and User Journey easier to understand by offering an experience similar to the actual product.
The objective is not to prototype all the possible interactions on each screen, but to present a realistic use case linearly.
It not only makes the Technical Assessment phase easier but also guarantees the existence of a master file directly synced with the design source files, reducing the chances of discrepancies between design and implementation.
Product Managers can quickly leave comments in appropriate places instead of communicating through a single shared file with dozens of screens presented linearly on a canvas or via emails that are not directly synced with the source file. This speeds up the process for change requests and makes communication between design, management, and development much clearer.