Lean UX Workshop I
Lean UX Workshop I
Lean UXAgility through cross-functional collaborationWorkshopChris BarklemLean UX Labs & Just UX
The workshop is about Lean UX. Lean UX focusing on bridging design, product and engineering and building agile teams. Teams focused on their agility not the process of agile, and do so by building a collaboration that is cross functional and iterative, which builds a shared understanding across those teams.2
Looking at failureThe story of Plancast.The founder, Mark Hendrickson, was a writer and web developer at Techcrunch, he left and started Plancast naming himself "Product designer and developer".
Looking at failureHere is his discription of what happened..Plancast was to provide a really easy way for people to take whatever interesting plans they had in their calendars and share them openly with friends, with the rationale that greater social transparency for this particular type of personal information would facilitate serendipitous get-togethers and enable a greater awareness of relevant events. Personally, I figured that knowing more about the events my friends and peers were attending would lead to a more fulfilling social and professional life because I could join them or at least learn about how they spent their time around town.Along the way my team built a minimum viable product, launched from obscurity on TechCrunch, raised a seed round of funding from local venture capitalists and angel investors, and worked like mad to translate our initial success into long-term growth, engagement and monetization.
Looking at failureBut..Alas, our efforts began to stall after several months post-launch, and we were never able to scale beyond a small early adopter community and into critical, mainstream usage. While the initial launch and traction proved extremely exciting, it misled us into believing there was a larger market ready to adopt our product. Over the subsequent year and a half, we struggled to refine the products purpose and bolster its central value proposition with better functionality and design, but we were ultimately unable to make it work (with user registration growth and engagement being our two main high-level metrics).
Looking at failure"While the initial launch and traction proved extremely exciting, it misled us into believing there was a larger market ready to adopt our product.
They did not look at :who where these people?what were their intentions?
Looking at failure100,000 have registered and over 230,000 people visit each month.
This is called a vanity metrix.They are called that because they make you feel good about yourself. But they don't tell you how your product is performing. If its working well, or if its working poorly. Out of these 100,000 people, how many have actually shared a plan? How many people have followed a user, how many return a second time, a third time, a second or a third month. These numbers don't tell you that, they make you feel good, but they don't tell you if your seeing any traction for your product.This leads to a false sense of success and a false sense of market fit.
Is there a better way?
The old fashioned wayNormally called the waterfall method
Design > Requirements > Development > Support / Learn >
Software is continuousYour product evolves from doubtto certainty.It never stops evolving.We are no longer delivering a finished product, instead we deliver a continuous stream of incremental improvements.
Software is continuous11.6 secondsAmazon pushes new code to production every 11.6 seconds. Tests the outcome produced by the change, if needs be rolls back the changes.Amazon pushes code, designed to test an outcome, before committing to a solution.
They push small bits forward, incremental changes. Tiny bits of risk.11
No more Model Years
No big changes with a finished product mentalityNo cramming in featuresNo thinking about what features we can sell to the user
Design a continues learning loop
The cutting edgeAgile software developmentLean StartupLean
Agile software development17 software developers, got together in 2000 with their frustrations.They were continuously missing deadlines, not meeting customer expectations and continuously negotiating contracts as the project evolved.
Manifesto for Agile Software Development Individuals and interactionsover processes and tools Working softwareover comprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan
The men valued the things on the left more then the things on the right. This is not saying they did not value things on the right, just not as much as things on the left.They stated that they did not know upfront all the details, that over time as the project evolved, so the plan needed to change as new information materializes.
Whats missing from Agile?
User experience, Design and Product Management were never factored in during Agiles inception.
What is Lean?We are always moving from doubt to certaintyWe are always moving in small steps towards certainty out of doubt
This was developed by Taiichi Ohno and his team in the 1950s. Its called the Toyota Production System. They could not compete with the Americas on scale. So they decided to compete by removing all waste from the system.
What is Lean?
Developed by Eric Ries
Every startup is a grand experiment. It intends to answer a question. Should we be actually building this?
ELIMINATE UNCERTAINTYWORK SMARTER NOT HARDERDEVELOP AN MVPVALIDATED LEARNING
Reduce wasteDont build things people dont want
Combine all the goodSo if you combine all the good from Agile, Lean and Lean Startup you will get the inspiration which lead to Lean UX
Inspired by Lean Startup and Agile Development theories, its the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed. Jeff Gothelf
We start, thinking we all see things the same
Visualizing out ideas reveals inconsistencies
Between designers, developers, product owners, experts, marketers and customers.
Regular discussion leads to iterationWith each iteration leading to a broader understanding
Ultimately leading to a shared understandingAnd team alignment (including your customers)
Working together grows understandingThe more you work collaboratively as a team, the more your shared understanding of the problems and solutions evolve. Ultimately you are all able to work effectively on parallel paths with the same clear understanding of where your going, why your going and how together you are going to achieve it.
How will this fit in with Agile?Use a cadenced Scrum process
End of theory, start of practice.