The UX Project Canvas: A Comprehensive Guide

In the dynamic world of UX design and research, clarity and alignment are paramount. The UX Project Canvas is a tool designed to provide a holistic view of a project, ensuring that teams are aligned, informed, and focused on the most critical aspects. In this article, we'll delve into the different sections of the canvas, its usage, and the benefits it offers.

The Left Side: Setting the Stage

The left side of the canvas is all about understanding the context and the 'why' behind the project.

  1. Business Problem or Requirements. This is the foundation. What challenge or need has prompted this project? It could be a gap in the market, a user pain point, or a business goal.

  2. Success Criteria. Define what success looks like. Is it increased user engagement? Perhaps it's a smoother checkout process or more sign-ups.

  3. Success Metrics. Quantify your success criteria. If success is about increasing user engagement, by what percentage? If it's about sign-ups, how many new sign-ups per month are we targeting?

  4. Consequences of Inaction. Understand the implications. What are the potential risks or losses if the project doesn't move forward? This can be in terms of revenue, market share, or user trust.

  5. Dependencies and Stakeholders. Identify any other teams, stakeholders, or external factors that could influence the project. This ensures that everyone is on the same page and potential roadblocks are identified early on.

The Middle Part: Observations, Assumptions, and Unknowns

This section is about grounding the project in reality, based on what the team knows and doesn't know.

  1. “We have observed” followed by "How do we know it?". This is about stating facts. For instance, "We have observed a drop in mobile app usage" next to "Based on last month's analytics report."

  2. "We assume that" followed by to "How we verify it". Assumptions can guide the project, but they need validation. For example, "We assume users find the app navigation confusing" next to "We will conduct usability tests to verify this."

  3. "We don’t know" next to "How we discover it". Acknowledge gaps in knowledge and outline how to fill them. "We don’t know why users abandon their shopping cart" next to "We will send out surveys and conduct interviews to discover the reasons."

The Right Side: Defining and Moving Forward

This section is about synthesising the information and deciding on the next steps.

  1. Problem Statement. A concise statement that encapsulates the main challenge or need the project aims to address.

  2. Hypothesis. Based on observations and assumptions, formulate a hypothesis. For instance, "If we simplify the app navigation, then we will see an increase in user engagement."

  3. Next Steps. Outline the immediate actions to be taken. This could be conducting research, redesigning a feature, or setting up A/B tests.

Hypothesis using the If-Then-Because Framework

The If-Then-Because** framework is a structured way to formulate hypotheses, especially in the context of design, user experience, and product development. It helps teams articulate their assumptions clearly and set the stage for experimentation. Here's a breakdown of the framework:

  1. "If" (The Change). This part of the hypothesis describes the action or change you plan to implement. It's the variable you're introducing or modifying in your experiment. Example: "If we introduce a 'one-click checkout' option..."

  2. "Then" (The Expected Outcome). This section predicts the outcome or effect you expect to see as a result of the change introduced in the "If" part. It's the measurable result you anticipate. Example: “Then there will be an increase in completed purchases..."

  3. "Because" (The Rationale). This is where you provide the reasoning or logic behind your hypothesis. It's based on your understanding of user behaviour, previous research, or industry best practices. Example: "Because users prefer a faster and more convenient checkout process."

Full Hypothesis

"If we introduce a 'one-click checkout' option, then there will be an increase in completed purchases because users prefer a faster and more convenient checkout process."

Benefits of the If-Then-Because Framework

Clarity. The structured format ensures that the hypothesis is clear and easy to understand.

Focus. It helps teams concentrate on a specific change and its anticipated outcome.

Rationale. By providing a reason for the expected outcome, teams can better align with user needs and business goals.

Testability. The framework sets the stage for experimentation, making it easier to design tests and measure results.

In essence, the If-Then-Because framework provides a clear and concise way to articulate hypotheses, ensuring that teams are aligned and that experiments are designed with a clear focus and rationale.

Hypothesis Testing

When conducting hypothesis testing, researchers often make predictions about how changes in the independent variable will affect the dependent variable. These predictions are formulated as hypotheses:

  • Null Hypothesis (H0​). This is a statement indicating that there is no effect or no difference. It's a default position that there's no relationship between the independent and dependent variables.

  • Alternative Hypothesis (H1​). This is what a researcher wants to prove. It's a statement indicating that there is an effect or a difference.

Example of A/B Test

To create an A/B test first the independent and dependent variables need to be identify. The independent variable is the variable that we are changing in the test, and the dependent variable is the variable that we are measuring the impact of the change on.

In the image, the independent variable is the in-page nudge. We are testing whether removing the in-page nudge will have a positive impact on conversions. The dependent variables are the click-through rates (CTRs) for the upgrade device CTA and the add services to your plan CTA, as well as the CTR for login via mega-menu. We are also measuring the overall conversion rate.

Two versions of the website will be created: a control group and a variation group. The control group will see the website as it is currently, and the variation group will see the website without the in-page nudge.

We then need to randomly assign users to either the control group or the variation group. This will ensure that the two groups are similar in all other respects, so that we can be confident that any difference in conversion rates between the two groups is due to the independent variable (the in-page nudge).

Once the users have been assigned to groups, the test run for a period of time. This will generate enough data to measure the impact of the independent variable on the dependent variables.

At the end of the test, the conversion rates between the control group and the variation group is compared. If the variation group has a higher conversion rate than the control group, then it is possible to conclude that removing the in-page nudge had a positive impact on conversions.

Problem framing

There are several framework to formulate an effective problem statement. For the UX Project canvas the Point Of View (POV) and the How Might We (HMW) Questions can be used:

POV (Point Of View)

The POV helps teams clearly define and understand the user's problem.


Purpose. The POV is used to articulate and frame user problems in a human-centred way. It defines the challenge by focusing on the user, their needs, and the insights behind those needs.

Structure. A typical POV statement is formatted as: [User] needs [need] because [insight].

Usage. The POV is derived from insights gathered during the empathy phase of Design Thinking. It's a synthesis of user research, observations, and other data to pinpoint the core challenges faced by users.

Outcome. The result of crafting a POV is a clear, actionable, and user-focused problem statement that serves as a foundation for the ideation phase.

HMW (How Might We)

The HMW helps teams transition from understanding the problem to brainstorming potential solutions.


Purpose. The HMW is used to reframe the defined problems (from the POV) into opportunity statements. It turns challenges into open-ended questions that inspire creative solutions.

Structure. A typical HMW question is formatted as: How might we [opportunity/challenge]?

Usage. Once a problem is defined using the POV, teams generate HMW questions to transition from problem identification to ideation. It's a bridge between understanding the problem and brainstorming solutions.

Outcome. The result of crafting HMW questions is a set of open-ended prompts that guide brainstorming sessions, encouraging teams to think broadly and creatively about potential solutions.

Benefits of the UX Project Canvas

Clarity and Alignment. Ensures that everyone, from designers to stakeholders, understands the project's context and goals.

Focused Decision Making. By laying out observations, assumptions, and unknowns, teams can make informed decisions.

Efficiency. Reduces the risk of miscommunication or overlooking critical aspects, ensuring that projects move smoothly.

Flexibility. The canvas is adaptable and can be used for various projects, from app design to website overhauls.

Conclusion

The UX Project Canvas is a powerful tool that provides a 360-degree view of a project, ensuring that teams are aligned, decisions are data-driven, and the project's direction is clear from the outset. Whether you're a seasoned UX professional or just starting out, incorporating the canvas into your workflow can lead to more successful and streamlined projects.

Previous
Previous

POV, JTBD, and HMW in UX Design: A Comprehensive Guide

Next
Next

The Importance of Understanding the Customer Journey in Conversion Rate Optimisation (CRO)