Lean UX Lessons Learned from One Dozen Projects

or How to Stop UX From Breaking Agile

A presentation by Nick Van Weerdenburg, CEO at rangle.io.

Follow Nick @n1cholasv and Rangle.io @rangleio

One Dozen Projects

One Dozen Projects- Variations in UX

• Design provided (3)

• Updating provided design (2)

• External design agency (2)

• Rangle-led upfront design (3)

• Rapid UX, iterative design through delivery (3)

A Few Definitions

Lean UX Primer

• An iterative design process

• Aims to use feedback and experiments to inform design

• Difficult to achieve

Some Definitions…

UX: The experience the user has.

UXD: the practice of designing the user experience

What we will consider…

UXDesign: the practice of designing the user experience

UXDevelopment: the practice of developing the user experience

And the intersection of the two creating the final User

Experience (UX)

The Central Problems

Going back 50 years…

The central issue with UX is underestimating the effort and complexity of building

usable software…

…not the lack of specialized UX work

UX and Agile

• UX is the primary reason agile is important, yet we often treat it as a waterfall activity

• Balancing and coordinating effort is the trick

of getting to an amazing UX

Teams Make This Complex…

• Developers prioritize development

• Analysts prioritize requirements

• Designers prioritize design

And all 3 need to be integrated.

to recap

Agile arose because user behaviour and needs (=UX) are impossible to predict

but…

The modern UXD process demands or implies a

complete solution, gets a sign off, and delivers

software.

bringing us back to BUFD (big up front design)

this is destructive to a great UX

but the solution isn’t easy

Lessons Learned Applying UX in

An Agile Environment

Any software documentation begets a waterfall process OVER TIME…

any spec, in time, becomes a defacto authority and replaces conversations long lost once the software is being

built.

design removed from conversation and validation

suffers rapid entropy

the result = we build products based on

misconceptions and misalignments

The Solution?

Shorten the Link Between Work and Validation• Do WAY less of upfront UX so as not to create something

that has apocryphal authority

• Be very committed to treating upfront UX as a hypothesis

• Treat code heavily used by your users as the final design authority

• Partition your UX for different purposes

• Define UX as a list of core values that your product abides by, not the specific solution

A Lean UX Lifecycle

Recap: UX is for Building Great Software…

• Plan for what the user wants

• Plan for what the user finds important

• Design an interface based on those practices

• Review those designs with users

• Get sign-off

• Build and Ship!

Reality: It’s Not That Easy

• User’s don’t know what they want

• You may not know who your users are (product/market fit)

• Actual usage vs. stated usage tend to be very different

• Paper prototypes don’t work very well

• So let’s do some UX work…but that takes back to design specs now done by designers instead of business analysts

• The solution? A Lean UX Lifecycle approach…

UX is 4 Different Things Across Time

Client Research

Market Research

User Research

Working Software

UX as Client Research

• You need to get into your client’s mind to understand what market they are thinking of addressing.

• UX is amazingly valuable for discovering your client’s motivations and inclinations.

• You can then figure out if market research is needed, or you can jump into user UX.

UX as Market Research

• We don’t even know our market, so by brainstorming about users and their ideas/wants/goals/behaviours we are in fact doing market research.

• This can be a lot more work than Lean UX.

• Treat it as a separate part of the lifecycle, and don’t let it drive actual design. Once oriented, start a new Lean UX process free to learning from delivery.

• The result of this stage is direction to investors (invest or not) and initial user UX (where to focus).

UX as User Research

• We know nothing about the user, so we need to learn more.

• We need some aids to discuss the user.

• We want some ideas about what the user wants.

• We want to point development in the right direction to start creating experiments that validate the ongoing direction of development. i.e. We want a better starting point, not a destination.

UX as User Hypothesis

• If we can treat UX as a hypothesis, that is a good start

• To do so, we need to age the original UX work and stop referring to it as a source of authority

• This requires design being everyone’s job (including developers) and ultimately owned by the user (validation)

UX as the Actual User Experience

• This is what we really want!

• Any separation between conversations/design and validation of the software leads to design entropy and the risk of false authority (due to lost context and nuance of the remaining artifacts)

• Testing is often about closing the differences in perception for the people using the design artifacts (removing opinion)

• We need to find a way to highlight and emphasize the actual user experience

Rangle.io’s Lean UX Process

0. Market definition (optional)

1. Rapid conceptual UX to get an initial understanding2. Interactive prototyping3. Lo-res mockups and a few hi-res for overall design 4. Style Guide

Steps 1-4 could be a day in truly agile process. Maybe a week. More than two weeks upfront and you should get scared. It also doesn't all have to be done upfront. Learn something, design the next section, build, learn some more.

5. Development delivering working software for testing 6. Refine with a pencil unless it's clear. Then go back to 1. 7. Ship or go to 5.

UX DESIGN

DEVELOPMENT

Personas RequirementsLo-Fi

Mocks + Some Hi

HTML5 Mocks I1 I2 I3 I4 I5I0

DevelopmentUX Design

Req DocsBacklog + Prototype + Arch. Doc + Developer Specs +

Code + QA

50%Clarity

Change

70% 90%

40% 30% 20% 20% 10% 10% 10%

Process

Requirements

QAQA QA QA QA

Hypothesis to Code: The Agile SDLC

UX Design

Design Thinking

Domain Knowledge

User Goals

User Interactions

User Personas

requirements

static mockups

interactive prototypes

UX Architecture and Style Guide

HTML5 Prototype

• visual and interaction design

Iterative Development

UX architecture

iterative development

• refinement of design

• foundation for developers to use

• developers are autonomous to build features, even without prototype Design Refinement

Lean UX Design Process

A UX Lifecycle to Align with Scrum

Minimum Viable Product

Emotional Design

Usable

Reliable

Functional

Emotional Design

Usable

Reliable

Functional

Not this

This

The beginning: front-end style guides• shift in industry from prototypes to style guides

• e.g. http://codyhouse.co/gem/css-style-guide-template/

• and http://bradfrost.com/blog/post/style-guides/

• “bootstrap—”..take same concepts and extract the core

• mdo code style guide- http://codeguide.co/

• Product Style Guide for Salesforce1- http://sfdc-styleguide.herokuapp.com/

The end: Documented User Experiences• UX is the result of testing and captures validated user

experience from delivered, heavily used code

• This is often lost in A/B test and analytics

• Create a UX document on the tail end of the validation process (a UX documentation)

• Have all future conversation against this

• Outline the core values of your design and user experience

Best Practices for Achieving Lean UX Success

• Build close to the conversations around the features

• Test and Validate

• Capture core guiding assumptions in style guides and validated lessons learned

• Don’t fall into a waterfall trap by relying on documents that have no traceability or living context

• Realize UX is both about the user, and the team’s understanding of the user. Neither exists without the other.

Thank YouTo discuss further, please email nick@rangle.io, twitter @n1cholasv or call at 416-737-1555.

Follow Rangle.io on twitter @rangleio