It Takes a Team

To Build a Product

The UXDX Model

A picture say a thousand words. The design of the UXDX model has been chosen to highlight the importance of working as one autonomous team. There should be no barriers between design and development as the understanding of the customers needs to be shared by everyone. In addition it provides a visual reminder to teams of the importance of Outcome-Driven development which can protect against the natural tendency to people to revert to Feature-Driven development.

How do you increase the odds of success?



Instill a desire for better

Demonstrate how people's jobs will improve in order to get them to embrace change.

Organisational Ability

Organisational Ability

Align on a shared vision

Align on clear customer, business and process goals. Then enable teams to deliver. 

Personal Ability

Personal Ability

Enable quality execution

Upskill in the new ways of working and remove any hesitations to change.

UXDX Model: Research -> Hypothesis -> Prototype

33% of product features negatively impact the product

Are you validating your new features before development?

UXDX Model: Build -> Test -> Release

Low performing teams spend 22% more time on unnecessary rework

Are you merging and testing regularly enough? 

UXDX Model: Deploy -> Operate -> Monitor

DevOps teams have a 440x faster lead time for changes

How quickly can you get code to Production?

Building the wrong features incurs the following four costs:

  1. The cost of ongoing maintenance
  2. The opportunity cost of not building the right feature
  3. The potential cost of the negative effect that the feature has on the product
  4. The cost of development

UX - DX Handovers

    Outcome Driven Development

    The UXDX model promotes Outcome-Driven development instead of traditional Feature-Driven development. By expanding the DevOps loop to include the Research, Hypothesis and Design stages it forces teams to validate their assumptions about new features before building them.

    Outcome-Driven development relies on the product team defining the outcomes that they expect to achieve with each feature. These outcomes are documented as hypotheses as follows:

    1. We believe that (feature) 
    2. Will result in (outcome - aligned to product purpose) 
    3. And we will prove it based on (measurable metric) 
    4. Within (time period) 

    The hypothesis structure allows teams to remove their bias towards features and verify whether their assumptions about a feature hold true. The design step, while not mandatory for every feature, encourages teams to validate their assumptions without writing any code. If, after the Research or Design steps, the hypothesis doesn't hold true it forces the team to update their understanding of their customers. These course-corrections accelerate the product teams learning and enables them to build better products, faster.

    Join The Annual Gathering

    Over 3 days, 1400 UX, design, dev and product people globally will descend on Dublin with a common goal - to learn how teams can work better together to build products, faster.