Assumption-driven development: hypothesis writing

THINK: assumptions and hypothesis

Instead of expressing “requirements, ” we consider assumptions and declare hypothesis statements. A hypothesis statement is a way of expressing assumptions in a testable form.

Reality often shows that the creators of a product or service are not sure what a user needs or wants or how it should work concerning the user experience. But quite often, organizations or companies proceed with their idea for functionality or user experience without input what the user needs (or what the user thinks about it) and without checking (testing) with the end-user throughout the development process.

Quite frankly, organizations that have been in business for many years (decades) think (with some level of arrogance) to know what the customer wants and how the experience should be – but this arrogance will bounce back with failure: an unhappy end-user will trash the product and its experience if it deemed to be unfit.

Hypothesis statement

A hypothesis statement will require experiments to determine which assumptions are right or wrong.

The first step is to list any assumptions: an assumption is a declaration of what we assume to be true. But it’s not considered a requirement until we have facts and figures to support it. Assumptions comprehend both business and user assumptions. A possible way to start listing assumptions is to start from a problem statement. Problem statements are full of assumptions. When assumptions are listed, it’s crucial to select the most uncertain ones.

The main principle of Lean Startup is to expose the highest risk first to learn. The whole team should do the exercise of listing assumptions and hypotheses with the whole team: everyone involved so that you can create a shared understanding from the start.

A hypothesis statement has the following format:

Hypothesis
Hypothesis

Note: This is a possible format, and there’s no obligation to follow this blindly, as long you understand the purpose, and you have the different elements.

Outcomes (objectives) and metrics

It is essential to focus on outcomes first: what are we trying to achieve and what objectives? What kind of user needs? Instead of directly thinking about features (solutions), we focus on outcomes. When creating the product, the progress will be measured against the outcomes. To measure, you need to define a set of metrics. An excellent approach to this is Objective-Key-Results.

Features (functionalities, stories, …)

Features exist to serve the needs that have been identified. You create a particular feature (solution, functionality, story). It’s essential to have the outcome first defined and think about possible features.

User assumptions

It is essential to know something about the customer, the end-user you’re creating the product for. Personas are a well-known technique to make the end-user visible.

The clue is to approach the creation and validation of personas the lean way: personas are not the output of great research upfront but are created and evolve as the product evolves. Personas created with lots of work upfront and not updated afterwards are essentially throw-away personas: they become useless as soon as they are outdated, and concern a source of waste.

We prefer to create “ad-hoc” or “proto”-personas: these represent the best guess of who is using the product and why. A proto-persona contains the information (demographics, behaviours and needs) of a specific type or segment of end-user relevant to the product being designed.

Resources

Lean UX book

Materials in this post are based upon readings on the Lean UX approach.

Lean UX (Jeff Gothelf)
Lean UX (Jeff Gothelf)

Lean UX book by Jeff Gothelf.

Read more about the Lean UX cycle.

Read more about the Lean UX book.

Objective Key-Results

In any context, objectives (or outcomes) are essential as they give guidance or direction; instead of focusing on solutions.

(Solutions in the broad meaning: a product or service, an improvement, a feature, a functionality, …)

We want to track progress concerning objectives, not only solutions. Quite often, solutions are proposed or defined without an objective in mind. To reach a specific objective, multiple solutions are possible.

When teams are given an objective, they can think for themselves about possible solutions and which solutions fit the best in the current environment (system, product, service, …). In general, teams who own part of the problem statement and the solution space are more motivated, focused, and creative, as they feel ownership.

Objective Key Results
Objective Key Results

OKRs = Objectives + Key Results

It is a method of defining and tracking objectives and their outcomes.
[Source: wikipedia.org]

  • Objectives are what the organization or individual want to accomplish, and are typically subjective, qualitative. Objectives can be ambitious, can be challenging.
  • Key results are concrete, specific, and measurable. They describe how you will accomplish the related objective, and measure whether you accomplished the objective or not.

The clue is that Objectives Key Results can be defined on several levels in the organization: for example, executive management, departments, products or services, teams.

How Google sets goals

 

Lean UX cycle

Lean UX cycle

Lean UX = applying Lean and Lean Startup principles to User eXperience.

Remove waste from the UxD process

Too much too often product (software) design and development is document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback, in order to improve our products (software) iteratively and incrementally.

Forget about the overload of UxD deliverables that are created to communicate “specifications” to “developers”. Re-consider and only create those deliverables that truly serve a purpose. We value “making” over “analysis“; we value “building” over “specification“. Lean helps us to focus on flow and to reduce non-value creation (waste).

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mock-ups, designs, etc

Overhead deliverables:

  • Detailed User Interface specifications (for example including annotations of every screen)
  • Wireframes of every screen, every screen size
  • Visual designs of every screen
  • High-fidelity mockups (not reused in development)

Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true cross-functional collaboration.

Cross-functional collaboration

True cross-functional collaboration (including designers, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development / release cycles. Agile re-focuses product (software) development on value creation and working products (software).

In every step of the cycle, and from the very beginning, the whole team is involved. The whole team approach aims to create a shared understanding with everyone, all the time. Knowledge, user feedback can be quickly spread and shared, and the team minimises the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).

Apply the scientific method

BUILD > MEASURE > LEARN

or

MAKE > CHECK > THINK

The scientific method exists for centuries and we are simply applying it to nowadays product (software) development.

"The Scientific Method as an Ongoing Process" by ArchonMagnus - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

In Lean Startup this is known as the build > measure > learn cycle. This is an on-going process, it obviously doesn’t stop with 1 iteration. We also call this make > check > think.

Lean UX cycle basic

Lean UX cycle basic

The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:

  • by first focusing on outcomes (objectives) and next on features (solutions)
  • by getting in touch with your end-users, observe and measure how they use your products
  • by focusing on creating valuable experiments to expose risks and uncertainty
  • by improving whatever you’re making based upon that feedback
  • by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimising the total time going through this process
  • by creating an environment of continuous learning

Learn more about Lean, Lean UX and product development with experiments in follow-up posts!

  • Techniques to bring UxD and development closer together, why collaboration matters.
  • The scientific method and product development with experiments
  • How to organise user testing
  • How to incorporate validated learnings

Resources

Lean UX book

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

A few articles

Lean UX cycle

Lean UX: What is Lean UX?

Lean UX is about apply lean principles to User eXperience.

Why?

There are 2 main observations:

Bad UX. Failed products.

Unfortunately, there are still too many (software) products and services built and released on the market, that do not fit the customers’ needs. This is a long lasting pain in software development. Nowadays thanks to modern web & mobile technologies, possibilities are endless. But than again there are still too many useless, badly designed, wrongly understood, misfit products with failed UX.

Search the web for “failed products” and you get a few examples.

Creation of software by writing documents.

The purpose of creating software is to serve the users’ need, to solve their problem, to automate their work, to meet their goal, to be convenient in use. Software is an end, not a goal. The experience has to be right, it must properly function, the experience should be neat and crisp.

Unfortunately, when creating user experiences, many product (software) development teams are organised in a way so that:

UX people “produce” the “UX” and create a document, a deliverable (“the UI/UX spec“). “The spec” is delivered to the developers who will make the wonderful UX real.

Documents do not solve users’ problems; software does.

With the agile manifesto in mind:

Working software over comprehensive documentation

We know and we owe it to ourselves to focus on delivering a working product, to collaborate and to work to the highest standards, and to minimise any unnecessary intermediates (such as “the spec“). So why do still so many teams (agile or non-agile) keep on focussing on “big UX design upfront”?

Applying Lean principles to product creation and UX will help us to focus on creating a right product fit, by creating value, and by minimizing any waste in the process. Likewise agile, likewise lean, Lean UX is a mindset, a process change and a way of thinking how to create the right product in the right way.

Lean?

The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

What is Lean? (lean.org)

UX?

UX or User eXperience is about the user experience, but also the whole customer experience. It’s more than design aesthetics. It’s the result of the combination of design, interactions, architecture, technology, business goals, etc.

UX iceberg

UX iceberg

Source: UX iceberg;
http://arquiteturadeinformacao.com/wp-content/uploads/2012/03/ux_iceberg.png

Lean UX

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX (Jeff Gothelf)

Lean UX (Jeff Gothelf)