Lean UX = applying Lean and Lean Startup principles to User eXperience.
Remove waste from the UxD process
Too much too often product (software) design and development is document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback, in order to improve our products (software) iteratively and incrementally.
Forget about the overload of UxD deliverables that are created to communicate “specifications” to “developers”. Re-consider and only create those deliverables that truly serve a purpose. We value “making” over “analysis“; we value “building” over “specification“. Lean helps us to focus on flow and to reduce non-value creation (waste).
What do I mean?
Useful deliverables (depending upon your context):
- Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
- Low-cost prototypes used in user testing
- Low-cost sketches, mock-ups, designs, etc
Overhead deliverables:
- Detailed User Interface specifications (for example including annotations of every screen)
- Wireframes of every screen, every screen size
- Visual designs of every screen
- High-fidelity mockups (not reused in development)
Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true cross-functional collaboration.
Cross-functional collaboration
True cross-functional collaboration (including designers, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development / release cycles. Agile re-focuses product (software) development on value creation and working products (software).
In every step of the cycle, and from the very beginning, the whole team is involved. The whole team approach aims to create a shared understanding with everyone, all the time. Knowledge, user feedback can be quickly spread and shared, and the team minimises the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).
Apply the scientific method
BUILD > MEASURE > LEARN
or
MAKE > CHECK > THINK
The scientific method exists for centuries and we are simply applying it to nowadays product (software) development.
“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg
In Lean Startup this is known as the build > measure > learn cycle. This is an on-going process, it obviously doesn’t stop with 1 iteration. We also call this make > check > think.
Lean UX cycle basic
The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:
- by first focusing on outcomes (objectives) and next on features (solutions)
- by getting in touch with your end-users, observe and measure how they use your products
- by focusing on creating valuable experiments to expose risks and uncertainty
- by improving whatever you’re making based upon that feedback
- by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
- by creating products iteratively and not only incrementally
- by minimising the total time going through this process
- by creating an environment of continuous learning
Learn more about Lean, Lean UX and product development with experiments in follow-up posts!
- Techniques to bring UxD and development closer together, why collaboration matters.
- The scientific method and product development with experiments
- How to organise user testing
- How to incorporate validated learnings
Resources
Lean UX book
Materials in this post are based upon readings on the topic of Lean UX.
Lean UX book by Jeff Gothelf.
Comments are closed.