Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2

Share

Download to read offline

Lean UX Lessons Learned from One Dozen Projects

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Lean UX Lessons Learned from One Dozen Projects

  1. 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. 2. One Dozen Projects
  3. 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. 4. A Few Definitions
  5. 5. Lean UX Primer • An iterative design process • Aims to use feedback and experiments to inform design • Difficult to achieve
  6. 6. Some Definitions… UX: The experience the user has.
 UXD: the practice of designing the user experience
  7. 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. 8. The Central Problems
  9. 9. Going back 50 years… The central issue with UX is underestimating the effort and complexity of building usable software…
  10. 10. …not the lack of specialized UX work
  11. 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. 12. Teams Make This Complex… • Developers prioritize development • Analysts prioritize requirements • Designers prioritize design And all 3 need to be integrated.
  13. 13. to recap Agile arose because user behaviour and needs (=UX) are impossible to predict
  14. 14. but… The modern UXD process demands or implies a complete solution, gets a sign off, and delivers software.
  15. 15. bringing us back to BUFD (big up front design)
  16. 16. this is destructive to a great UX
  17. 17. but the solution isn’t easy
  18. 18. Lessons Learned Applying UX in An Agile Environment
  19. 19. 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.
  20. 20. design removed from conversation and validation suffers rapid entropy
  21. 21. the result = we build products based on misconceptions and misalignments
  22. 22. The Solution?
  23. 23. 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
  24. 24. A Lean UX Lifecycle
  25. 25. 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!
  26. 26. 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…
  27. 27. UX is 4 Different Things Across Time Client Research Market Research User Research Working Software
  28. 28. UX as Client Research
  29. 29. • 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.
  30. 30. UX as Market Research
  31. 31. • 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).
  32. 32. UX as User Research
  33. 33. • 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.
  34. 34. UX as User Hypothesis
  35. 35. • 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)
  36. 36. UX as the Actual User Experience
  37. 37. • 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. A UX Lifecycle to Align with Scrum
  42. 42. Minimum Viable Product Emotional Design Usable Reliable Functional Emotional Design Usable Reliable Functional Not this This
  43. 43. 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/
  44. 44. 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
  45. 45. 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.
  46. 46. Thank You To discuss further, please email nick@rangle.io, twitter @n1cholasv or call at 416-737-1555. Follow Rangle.io on twitter @rangleio
  • SalimKapasi1

    May. 9, 2015
  • kenguashi

    May. 1, 2015

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.

Views

Total views

1,429

On Slideshare

0

From embeds

0

Number of embeds

10

Actions

Downloads

20

Shares

0

Comments

0

Likes

2

×