Most Lean UX practitioners define documentation that follows, not leads, as the principle of “Getting out of the Deliverables Business“. The wording of this principle has caused a lot of confusion, and may create more damage than good when translated as “we don’t have to document anything”.
Agile development deliverables focus on the code and product subsets. UX Deliverables typically include myriad artifacts like thick BRDs (Business Requirements Documents), extensive wireframes, interaction flow diagrams, site maps, content inventories, taxonomies, contextual inquiry reports, trend analyses, and specification documents with full “redlines”. These have traditionally led the way, describing what developers are eventually to build.
I have found a simple refocus of the principle, where documentation follows the build, provides better understanding to teams adopting this principle. Documentation should follow and support each state of the Lean UX/Agile process, where measure-and-learn cycles guide pivots and happen rhythmically.
If you have a team of more than two people that have to get something done in tandem, they will need effective documentation; if you expect to build something that has more than a single simple button on it, you will need a minimum viable outline, or blueprint. In addition, if you bring other members into the core team later, or need to maintain what was built, you will need quality, albeit brief, documentation. For that matter, once I need to get more than 10 tasks done in a day, I need a list to help make sure I can track them.
Documentation is critical – but in an experimental, hypothesis driven approach it does not need to lead. Rhythmic measure-and-learn cycles can guide pivots, while minimal but sufficient documentation can keep the artifacts from holding inertia that makes change harder.
Lean UX brings a paradigm shift:
Leveraging Technology to Streamline the Documentation process:
Here is a practical tool I have discovered that can auto-generate a documented build direction when all the core team members participate. I was able to leverage new touch/pen large screen computers from Perceptive Pixel (currently owned by Microsoft) while working with a core team at Getty Images to define the interaction architecture. I found that a single OneNote page becomes incredibly powerful and time saving infinite whiteboard canvas.
This example of ideation (raw sketching documentation capture below) was done for a Getty brand mobile app experience. UX designers, researchers, and developers all came together in a room with a large touch screen in it and co-created the iterations for what the experience would work like. The digital sketching was being shared in real time to all the devices in the room. People were up at the board and working from the tablets on couches all from a single page within OneNote and in real-time. Beyond leading to huge time savings, by not wasting it on elegant and elaborate documenting exercises.
We enjoyed the benefit of the developers not getting lost in translation around the sketches. This was due to having given birth to the ideas in total collaboration alongside the UX designers. We were able to take our sketches right into prototyping.
Example of real world collaboration where documentation was auto generated from an interaction architecture sketching session:
The One Sheet Vision Casting Document:
Here is another real world example of a document supporting the team’s direction after the project kick-off. I use a single sheet to keep everyone on the same page (pun intended). I have found a single slide (minimum doc) method for complex MVPs can be extremely helpful since people actually read it, and can quickly refer to it during design reviews and demo builds. I have found this one sheet provides the stakeholders confidence in completely empowering the core team since everyone knows what we’re making and why, then makes together.
Example One Sheet – if you want to learn how to craft these for your team let me know.
The FUD Factor: (Fear Uncertainty and Doubt)
The paradigm shift to less documentation that supports rather than leads the product, can be unnerving to UX Designers and Researchers. These documents represent tangible milestones, and are used for their portfolios for future jobs; trophies to show how they contributed. Lean UX is a forcing function that gets the designers on the same engineering page as developers.
Now in order to fulfill your craft, you have to see the product or feature in action, used by customers. This supporting nature of the documentation becomes a true collaboration of team effort. One that you get to experience. Lean UX is about driving to quality, minimal, valued products with the least amount of waste.
Recruiters will have to dig deeper into interdependent and intertwined portfolios of actual experiences instead of the traditional artifacts of sketches, wireframes, drafts, comps and specs. It’s time to collect user feedback as your trophy of value to the team contribution. This principle empowers the UX designers and researchers to provide rapid build together insight and experiences without getting lost in the weeds of documentation.
I have found Lean UX principles to be revolutionary steps to transforming agile methodologies. It brings the end-to-end talent of the engineering pool together like no other tool. Lean UX provides the vision for harmony between the creatives, researchers and builders like never before.
Part 3 will focus on “Experience Outcomes“. I have become convinced that this is the most valuable principle of them all. (Read here)
More shared learning coming.
