lean ux lessons learned from one dozen projects
TRANSCRIPT
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- 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)
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)
Going back 50 years…
The central issue with UX is underestimating the effort and complexity of building
usable software…
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.
but…
The modern UXD process demands or implies a
complete solution, gets a sign off, and delivers
software.
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.
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
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…
• 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.
• 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).
• 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.
• 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)
• 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
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 [email protected], twitter @n1cholasv or call at 416-737-1555.
Follow Rangle.io on twitter @rangleio