The 7 product dimensions (by Ellen Gottesdiener) help to think to discover product options and create pieces of value.

Download the PDF version of the 7 product dimensions
Continue reading →The 7 product dimensions (by Ellen Gottesdiener) help to think to discover product options and create pieces of value.
Download the PDF version of the 7 product dimensions
Continue reading →Lean UX = applying Lean and Lean Startup principles to User eXperience.
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):
Overhead deliverables:
Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true 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).
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.
The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:
Learn more about Lean, Lean UX and product development with experiments in follow-up posts!
Materials in this post are based upon readings on the topic of Lean UX.
Lean UX book by Jeff Gothelf.
“Cross-functional” collaboration in (agile) product development means that the whole (complete) product “development” team is participating. Scrum talks about a “development” team without distinction of role. As such, “developer” means any competence or skill required to create the product or service, not limited to “programming” (writing code).
Lean UX heavily promotes the whole product development team participating during the complete product development cycle from the very beginning. The entire team approach aims to create a shared understanding with everyone (all team roles) from the start and to minimize any waste originating from working in sub-teams or silos (hand-overs, intermediate deliverables, re-discussing the same topic with people who didn’t participate, etc.).
True agile teams (feature teams) are product-oriented and can implement product features end to end, creating value pieces with every item done. Collaboration with all team members is an excellent source of creativity, new ideas and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, participate in work outside their main domain, and help create that necessary shared understanding to deliver value within an iteration.
Teams working in a phased approach (the so-called staggered sprints) face several worries – this should not be accepted as standard, and such teams should strive for a better working method. A phased approach is some work done in a sprint before the “development” sprint (or even worse, acceptance or testing after the” development” sprint).
The challenges with this phased approach are:
The (single) (proper) Scrum team approach has numerous benefits:
And so, we urge you to re-consider any extensive upfront work (before “construction”) and try to create shared understandings with the whole team. That shared understanding will lead to a willingness to collaborate within the same sprint truly. You foresee a regular cadence of user tests in the Lean UX approach. The aim is to create a “test everything” culture: we test what’s available, and given the users’ feedback, we improve (we iterate).
Sources: