“Our goal is not to create a deliverable or a feature: it’s to positively affect customer behavior or change in the world–to create an outcome” - Lean UX Designing Great Products with Agile Teams, by Jeff Gotheld & Josh Seiden
Do you remember my first summary of Lean UX and its principles, from the great book Lean UX Designing Great Products with Agile Teams, by Jeff Gotheld & Josh Seiden? In case you don’t, here is the link to the introduction of Lean UX.
First, let’s summarize the three points of Lean UX:
- Design Process: Being as efficient as possible
- Team Culture: Ensuring close collaboration and productive interaction between stakeholders
- Team Organization: Not relying on just the designer to figure out what’s best
So now that your memory of Chapter 1 has been refreshed, let’s dig into the topic covered in Chapter 2 of the book; this post is also the second in an eight-part series. Before you begin designing a product and starting a "collaborative design," it is important to address the following three steps:
- Stating Assumptions
- Converting Assumptions into Hypotheses
- Defining User Outcomes
These three concepts should undeniably help to design the product that most closely matches a target audience’s expectations.
I. STATING ASSUMPTIONS
Whatever a project is about (app, website, software, etc.), it always comes with requirements and deliverables. Based on this, expectations from the team in charge involves coming up with a bunch of features which should perfectly fit the target audience’s needs, and therefore create the perfect product.
But, this fantastic outcome rarely happens. The truth: it is an arduous process to foresee if the designed features will impact the user the way that’s expected and create whatever goal the product is meant to achieve. For instance, will a functionality engage a user to click? Will a feature generate a transaction? Is a user journey simple intuitive enough for the target audience?
A team can make assumptions based on the provided requirements and the personas that have been drawn during the project’s Discovery Phase.
To avoid any risk of treating assumptions as facts and exposing the project to future problems, it is important to state the assumptions. “By doing this as a team, you give every team member–designer and nondesigner alike–the opportunity to ask questions about your target audience, what problems you are solving for those people, and how best to solve the problem.” (Lean UX Designing Great Products with Agile Teams)
There are four categories of assumptions:
- Business outcomes - In other words, the definition of “done.” What exactly is the “measurable change we want to see in the world or in customer behavior”?
- Users - Who are the people being targeted by the product? The different user profiles which will help to define the personas?
- User Outcomes - What are the personas looking for from the product?
- Features - There are 2 kinds of features: 1- Additional functionalities, improvements, or changes to an existing product, also called “Customer Journey Mapping"; 2- Any functionalities that lead to a transaction for a new product, or what leads a business to achieve the product goal.
By stating assumptions, a team makes sure that all the problems are identified, addressed, and measured (“analytics reports, usability reports, information about past attempts to fix the issue, justification from the business as to how solving this problem will affect the company’s performance, competitive analysis”). This is teamwork where all the disciplines are represented (designers, product managers, marketers, developers/engineers, etc.).
To represent all disciplines, whether it’s an existing or new product, the “Problem Statement Template” is a good tool to start:
II. CONVERTING ASSUMPTIONS INTO HYPOTHESES
Now that assumptions have been stated, here’s the specific template to write down each hypothesis statement for testing (the goal is to focus on features):
“We believe [this statement is true]. We will know we’re [right/wrong] when we see the following feedback from the market:
- [qualitative feedback] and/or
- [quantitative feedback] and/or
- [key performance indicator change].”
Pretty straightforward, isn’t it?
At this stage, we are in pretty good shape in defining the business outcomes.
Remember, Lean UX is all about the building-measuring-learning cycle. The more we test during the process, the better the learning and product outcome. We must always consider all the types of user case scenarios when it comes to functionalities and ask questions like: How can we make a feature more engaging? How can we make a product more appealing in the first place? How can we generate more clicks? How can we convert reluctant users into convinced buyers?
The “Startup Metrics for Pirates” framework (or, AARRR!) created by Dave McClure, founder of 500 Startups and former PayPal employee, indicates the level of engagement from customers. Each user behavior that corresponds to a level can be measured to determine where the efforts need to be focused on attaining the product goal. Here’s what the framework stands for:
- Acquisition - can the product or new feature engage the user/customer to go further?
- Activation - is the user happy enough to use the service?
- Retention - will the user come back
- Referral - will the user be a good product ambassador and recommend it to others?
- Revenue - will the product finally lead to the transaction?
III. DEFINING USER OUTCOMES
Once hypothesis statements are set up, it’s time to focus more on the target audience that the product is supposed to reach.
Normally, the personas were identified at the very beginning of the process, sometimes by a third-party vendor required by the client. If this is the case, a team might ask: are the personas still accurate or relevant based on the hypothesis statements? It might be a good idea to review and refine the list. With Lean UX, personas should always be refined “whenever we learn something new about users.” (Lean UX Designing Great Products with Agile Teams)
In case the personas haven’t been created yet, consider it mandatory at this stage of the process. So if a user persona hasn’t been created, here’s a persona template to help:
Each time a person is identified, ask the following questions:
- Does this user/customer really exist, based on the assumptions and hypothesis statements? (Depending on the answer, refine accordingly.)
- Are the listed user’s needs and obstacles real ones? (No need to build solutions for problems which don’t exist.)
- If the problems are real, do the solutions solve them? (We need to make sure this is the case by getting feedback ASAP.)
Remember, creating personas is a team effort and the key factor to a product’s success. At this stage, nothing is etched in stone and will probably never be; a product is in constant motion. And, if a team thinks steps are being taken backward, efforts must be doubled to go forward.
Based on what you read, are you bursting with the desire to know which chapter comes next? Hold your breath, it’s: Collaborative Design!
Until then, have fun with your job—and empathy toward your users!
(Source for all images in this post: Lean UX Designing Great Products with Agile Teams, by Jeff Gotheld & Josh Seiden)