Lean UX Lessons Learned from One Dozen Projects with Nick Van Weerdenburg Presented live at FITC Toronto 2015 More info at http://www.fitc.ca/toronto Software is defining our era, and how we build software is an essential human practice with profound effects. It sucks to be doing it wrong. Nick discusses how Lean UX, an important new discipline, is difficult to achieve, best practices for achieving success, and his lessons learned with Lean UX and continuous delivery from a dozen projects. OBJECTIVE Invigorate the audience to adopt effective Lean UX practices. TARGET AUDIENCE Managers, developers, designers, project managers, clients. ASSUMED AUDIENCE KNOWLEDGE Some experience with software as a user or a creator. FIVE THINGS AUDIENCE MEMBERS WILL LEARN How documentation can become a trap. The importance of time elapsed between design and delivery. How to avoid UX becoming a defacto waterfall development process. The importances of meaning over prescription, context over instructions. Where UX design ultimately lives and evolves over time.

1. 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

2. One Dozen Projects

3. 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)

4. A Few Definitions

5. Lean UX Primer
• An iterative design process
• Aims to use feedback and experiments to
inform design
• Difficult to achieve

6. Some Definitions…
UX: The experience the user
has.
UXD: the practice of designing
the user experience

7. 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)

8. The Central Problems

9. Going back 50 years…
The central issue with UX is
underestimating the effort
and complexity of building
usable software…

10. …not the lack of specialized
UX work

11. 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

12. Teams Make This Complex…
• Developers prioritize development
• Analysts prioritize requirements
• Designers prioritize design
And all 3 need to be integrated.

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

14. but…
The modern UXD process
demands or implies a
complete solution, gets a
sign off, and delivers
software.

15. bringing us back to BUFD
(big up front design)

17. this is destructive to
a great UX

18. but the solution
isn’t easy

19. Lessons Learned
Applying UX in
An Agile
Environment

20. 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.

21. design removed from
conversation and validation
suffers rapid entropy

22. the result = we build
products based on
misconceptions and
misalignments

23. The Solution?

24. 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

25. A Lean UX Lifecycle

26. 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!

27. 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…

28. UX is 4 Different Things
Across Time
Client
Research
Market
Research
User
Research
Working
Software

29. UX as Client Research

30. • 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.

31. UX as Market Research

32. • 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).

33. UX as User Research

34. • 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.

35. UX as User Hypothesis

36. • 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)

37. UX as the Actual User
Experience

38. • 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

39. Rangle.io’s Lean UX Process
0. Market definition (optional)
1. Rapid conceptual UX to get an initial understanding
2. Interactive prototyping
3. 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

40. Personas Requirements
Lo-Fi
Mocks +
Some Hi
HTML5
Mocks
I1 I2 I3 I4 I5I0
DevelopmentUX Design
Req Docs
Backlog + 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

41. 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

42. A UX Lifecycle to Align
with Scrum

43. Minimum Viable Product
Emotional
Design
Usable
Reliable
Functional
Emotional
Design
Usable
Reliable
Functional
Not this
This

44. 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/

45. 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

46. 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.

47. Thank You
To discuss further, please email
nick@rangle.io, twitter @n1cholasv or call
at 416-737-1555.
Follow Rangle.io on twitter @rangleio