I spent the last two days participating in a workshop called “Smart Scrum Product Ownership,” with Jeff Patton (he wrote User Story Mapping) and Jeff Gothelf (he wrote Lean UX), held at the Center for Social Innovation on the far west side of Manhattan. It focused on integrating Lean UX practices into agile environments, and had a lot of great material. I have an entire page in my notebook devoted to things I want to follow up on and explore in greater detail. However, I also want to immediately think of ways to use the information in our day-to-day work, so it doesn’t get lost. Fortunately, we have a snow day today, so I have no meetings, and have already begun thinking about how to change our existing workflow based on some of the things I learned, to move us from a lean-ish to a truly Lean UX team.
One of the messages I received during the course of this workshop was that we’re all just making assumptions (or guesses). Lean UX aims to help reduce the risk involved in our assumptions by providing a framework in which we can test these assumptions in order to minimize risk. The framework includes creating hypotheses from our assumptions. In creating hypotheses, we can prioritize which assumptions to test based on the associated level of risk. Those of higher risk and higher perceived value can then be tested first, and the others can move to lower priority or a backlog.
By learning about this process alone, I got some clarity as to some of the ways we’re approaching our work in non-lean ways. As a small example, we’ve been working on a process wherein users can sign up and get a weekly email digest of posts from our News & Events blog. One of our current chores is to design the template, and another is to test the digest functionality. However, when sitting in the workshop, I realized we were going about it all wrong.
Rather than doing the upfront work and then seeing if our community actually wanted a weekly email digest of our News & Events blog, we should be testing our assumptions with a hypothesis. And because we have blog analytics, we need not even get too far along this path, because they show that, while our blog has adequate readership, it’s certainly not a high-traffic blog. So this work should move to a discovery backlog, and we should be focusing on testing our assumptions in higher risk and higher perceived value areas.
We’re also working on improving the way we provide spaces information to our community. As a large research library in the heart of New York City, we are constantly facing space constraints. We’ve gathered qualitative and quantitative user input on our spaces representation and use, but, rather than test hypotheses using this data, we’ve tried to immediately funnel it into concrete UI improvements. I’m going to take a step back and work with the team to write some hypotheses, and then determine which ideas are valid using some minimum viable product (MVP) strategies.
Minimum viable products are perceived differently depending on what industry you’re working in, but the way they are perceived in the area of Lean UX is as a way to test hypotheses. They include things like prototypes, and fake features (creating something that doesn’t work, but tests interest). I’m not quite sure how that aligns with user-empathy, and gaining trust, but that’s something else to muse on, on another snow day…
In the meantime, I need to go shovel.