Applying the LeanUX process, part 3

If you're interested in LeanUX, but you haven't yet read through part 1 and part 2, I strongly advise you to do so first.

Part 1 provides a foundation of what LeanUX is and why it may be a good fit for your organization.

Part 2 breaks the entire process down into steps that you can take within your own organization to facilitate LeanUX meetings.

This article is a list of useful resources and FAQs that can help you get started, but the other articles provide a good foundation to ensure you get started correctly.

Frequently Asked Questions

Who will lead the project?

The Facilitator leads the project and makes sure the team is adhering to the process. This is often the designer, but this document is designed to serve as a step-by-step reference, so even if you're not a designer, you can use these steps to facilitate the process.

As the team becomes more comfortable with the process the Facilitator’s role may diminish in importance. This is a good thing.

Who should be involved?

The core team (or “working group”) should consist of all of the major roles that are responsible for creating software applications. This means the team should include:

Front-end Developers
Back-end Developers
Designers
Business Analysts
Product Owners
Quality Assurance

The working group may also need to check in periodically with other decision-makers within the company, such as the executive team or other stakeholders.

Who will make the decisions?

For the most part, the working group makes the product decisions by discussing issues and coming to a consensus. In situations where a key decision needs to be made or a tie needs to be broken, that responsibility falls on the Decider. In situations where key feedback or decisions are made by a higher-level decision maker, those decisions should be directed through the decider to communicate to the rest of the team. This keeps the “chain of command” clear for the rest of the team.

What is everyone’s responsibility?

Everyone on the team plays a part in the design of the application, but below are some key functions that certain roles tend to play.

Designers are responsible for documenting the team’s design decisions in the form of high-fidelity mock-ups, prototypes and design documentation (as needed). They will take the low-fidelity artifacts generated by the team and develop them into high-fidelity screens.

Developers are responsible for building any working prototypes and, later, for developing the application based on the plans made by the team. During the design phase they are responsible for identifying any potential development concerns and guiding the team around them.

The Business Analyst is responsible for ensuring that the team designs support the requirements of the project. If there are features that are required to be in the product the BA must ensure those are included. The BA is also typically in charge of documenting key team decisions about the application’s behavior.

The Product Owner is typically the person that engages with clients and potential clients to set up tests as they are required.

How can team members make the most of our time?

LeanUX asks the team to maximize shared understanding, but there is still a time and place for contributors to work individually when it makes sense. Decisions should be made with the team, but once those decisions are made, the individual contributors can work towards solutions alone. This means that after the initial sketching process has produced designs it is acceptable for the designers to work alone to produce high-quality versions of those designs, and for the developers to work alone to begin implementing the first versions of those interfaces or back-end services.

This suggestion is a deviation from the traditional LeanUX process, but I found that it helps team members utilize their time more effectively.

Technical design can occur in parallel with these efforts. The direction should be decided as a team, but the work can be divided up and completed alongside the other team efforts.

What if someone has a great idea after the process has begun?

Because the process is cyclical and iterative there are regular opportunities for new ideas to be rolled into the product.

New ideas should be converted into hypothesis statements and added to the hypothesis statement backlog. When the team has completed a testing cycle and is evaluating the feedback from the tests there is an opportunity for the design to be tweaked and for new hypothesis statements to be pulled from the backlog to be worked in the new cycle.

The team can choose how to prioritize those new hypothesis statements (some teams may want to vote), but the decider has the ultimate decision-making authority on what gets pulled into the next cycle.

What are Problem Statements?

A problem statement is a short blub that describes the business justification for the project. It should include:

The current goals of the product or system
The problem the business wants to address (i.e. where goals aren’t being met)
An explicit request for improvement that doesn’t dictate a specific solution

Problem statements for new products are different from existing products.

Template for Existing Products

[Our service/product] is intended to achieve [these goals].

We have observed that the product/service isn’t meeting [these goals] which is causing [this adverse effect] to our business.

How might we improve [service/product] so that [customers] are more successful based on [these measurable criteria]?

Template for New Products

The current state of [domain] has focused primarily on [customer segments, pain points, etc.].

What existing products/services fail to address is [gap].

Our product/service will address this gap by [vision/strategy].

Our initial focus will be [segment].

Example

Connectivity is now a commodity. As an organization that once was a one-stop-shop for connectivity and content we’re now viewed as a “dumb pipe.” How might we might increase the value of our service beyond this perception and increase lifetime customer value and retention.

Assumptions Worksheet

Each member of your team should take the time before the first meeting to fill out this worksheet. This will be used to gather assumptions about the project and will help to identify blind spots and opportunities before any planning is done.

User Assumptions

Who is the user?
Where does our product fit into their work or life?
What problems does our product solve?
When and how is our product used?
What features are important?
How should our product look and behave?

Business Assumptions

I believe my customers have a need to:
These needs can be solved with:
My initial customers are (or will be):
The #1 value a customer wants to get out of my service is:
They can also get these additional benefits:
I will acquire the majority of my customers through:
I will make money by:
My primary competition in the market will be:
We will beat them due to:
My biggest product risk is:
We will solve this through:
We will know we are successful when we see the following changes in customer behavior:
What other assumptions do we have that, if proven false, will cause our business/project to fail: