Requirements are hypotheses: My experiences with Lean UX

Editor's Notes

• #3: Always start with an inspiring quote. Any ideas whose words of wisdom these belong to?
• #4: Bet you didn’t know Benny Hill knew UX? I’ll come back to him later…
• #5: Last year I attended a day-long workshop on Lean UX, led by author of the book, Jeff Gothelf. The day was all about how large organisations can adapt to the challenges of today’s business environment where small start up companies are significantly disrupting established business models. It’s had a profound effect on how I think about projects… You’re probably not involved in new product development, which is where this approach has come from, but I’d suggest the ideas behind Lean UX should matter to you if you are responsible for some of these: Software development, or maintenance of functionality The management or execution of a service or process A website, or areas of a website; the content you curate and how you structure it
• #6: There’s this mythical state of perfection. Of a product we’re working on being finished. Funders often believe we can achieve perfection, and perhaps we don’t do enough to dispel this expectation. In reality development should be continuous. So this tree is that mythical state of product perfection that we’re trying to reach. Now think about projects that you run. Do you decide upon a path towards that tree and set away, keeping going til you have to stop (or you believe you’ve reached it)? What if there’s a cliff edge in that fog? Or some less dramatic but nonetheless fundamental obstacle in your path. In this situation, what would you do really? Just march off despite only being able to see three steps ahead? Or take those three steps, stop, take stock of what you can now see and then continue for a few more steps. So why can’t we do this with development?
• #8: Or to put it another way (my words), it's about making sure that what you're doing is likely to be a good idea before you put too much effort into it. How many web pages, or features, or service elements are you responsible for that are not well used, or not fit for purpose, or just basically redundant? How much does it cost you to maintain? How much does it interfere with your end users' experience? How did they come to be there, or be like that, in the first place? How much time, cost and effort went into getting it there? Is it because nobody stopped to ask why? Or because the boss said just do it? Or because what seemed like a good idea at first turned out to be not such a good idea, but by that point you were too far down a particular road?
• #9: (Run video from 2m 45s to 4m 51s) How often have we encountered that? A product vision based around a marketing concept. Or better yet, the brainchild of a vice principal. And the thing is, how often do we proceed and deliver pretty much what was envisaged without any indication of how the intended audience will respond? Despite our misgivings, or those of colleagues a bit closer to the coal face?
• #10: So Lean UX is all about doing just enough to establish whether a development is a good idea; using evidence of user interaction and demand to justify continuing down a particular path.  A well used phrase in the field:  "Fail fast, fail cheap". You’ll probably find that using the word fail doesn’t go down so well though. I prefer “learn”.
• #11: We’ve been practicing agile for over 3 years now, with the primary driver for adoption being the development of a new University CMS. (Check out my colleague’s workshop on the topic tomorrow, by the way). But for all we’re agile, and ok at it I’d say, the focus in some quarters is on feature delivery. Doesn’t matter what, so long as we’re delivering. I’ve personally found this frustrating at times, but then I am bias towards investing in enhancement over new bells and whistles. And why? Because at the end of the day a feature is only worth the effort if it adds value for the business and the user. If it’s something that is used, and usable.
• #12: This is the Lean UX hypothesis statement. If you take only one thing away with you today, take this. And next time someone asks you for something dubious, shape their request into a hypothesis statement and ask them if its what they meant.
• #13: OK, it’s a cycle. But where should we start? Whether you’re talking about developing something new, or enhancing something you already have, start by learning about what your users and business need. Not necessarily by asking, but by watching, analysing, diagnosing. Work collaboratively with your team to generate ideas to meet those needs. Build the bare minimum to enable you to validate your idea. And repeat. I’m going to talk through a couple of examples of how we’ve done this in very different scenarios…
• #15: These are the steps I went through during Jeff Gothelf’s workshop. When I got back to the office I picked up on a CMS user support review I already had in progress. I’d had a chat with the team, reviewed some feedback data and was in the process of drafting something when I attended the Lean UX workshop. I decided to use what I’d learned there to experiment with our service provision – what we provide and how we allocate resources – and more importantly for me, empower my direct reports, Duncan and Lizzie, to move things forward themselves. I do little hands-on training and virtually no direct user support any more, so I wanted the people who drive the service and meet our customers all the time, to identify opportunities with me and collaboratively prioritise what we gave focus to.
• #16: So I set this outcome as the starting point for our process. “… freeing us to spend more time on strategic and research-related support matters”
• #17: First we brainstormed ideas for business outcomes that we thought would support the overarching goal, grouped and rationalised them, and then dot voted.
• #18: Our use of personas within the team is pretty mature, so we didn’t need to create any. We already had validated personas that we were all familiar with.
• #19: If you don’t have personas to draw on – like we didn’t on the day I attended the workshop – start with sketches. The point of this step is to force the team to externalise and share their assumptions. Rather than keep who we think the user is in our heads (which makes for difficult conversations when we all have different unshared thoughts on this) we get it all out, and, however imperfect, come to a shared view of who the users were that we were serving. Of course, the idea here is that you would validate your assumptions and develop the personas over time based on what you discover through research and engagement with the business.
• #20: For this exercise, we focused on our personas’ needs and pain points, putting one idea down per post-it note. After doing this individually, we shared as a team and grouped them.
• #21: The final brainstorming exercise was about features. The thing that is typically talked about first. Sometimes it’s the only thing that is talked about. So coming to it last, after we have collaborated on business outcomes, users and user goals, made feature brainstorming more focused and easier to share our ideas. Again, we put our ideas down on post it notes (the focus being on features that we thought would serve our personas and create their desired outcomes), then shared with the team, then grouped and rationalised. Using a table drawn on a flipchart, we started to fill in the columns to complete this sentence. We had prioritised our business outcomes, so the number of rows in the table was limited by this. But what we had was different personas, with different pain points and priorities, potentially being served by multiple features that ultimately (we hypothesised) would support our priority business outcomes. So you can imagine it was quite messy as we moved around and grouped and traded post-it notes. But ultimately our challenge was to write some hypothesis statements that would form the basis of a direction for the enhancements to our service.
• #22: Write up from the table full of post it notes; the three hypotheses we decided to pursue.
• #27: The development team decided to prioritise this as it was a ‘quick win’; we could just turn on standard Google functionality. But then they encountered a problem. Which advanced features to use, and how to present them in the interface in a manner that was easy for website visitors to use? I was asked to help them design and test the interface. But I suggested instead that we check that this was something people actually wanted. Why would I do this when our survey already was telling us we should prioritise this? A few reasons: It’s well established in research that what people say and what they do aren’t the same. We are hopeless at predicting the future; we’re overly optimistic about what we think we would do. ‘Introspection illusion’ (Ref: UX Myth 23: People can tell you what they want) We typically think that we want more power, more features, when really we appreciate simplicity and efficiency While implementing these features was technically easy, from an interface design perspective there was a lot of hard work ahead of us. I wanted to be sure that if we went to a lot of effort to deliver these features, people would actually use them.
• #28: If McDonalds surveyed customers they’d almost certainly claim to have more interest in salads than the evidence shows.
• #29: Which brings me back to Benny Hill – just because nobody complains, doesn’t mean you’re necessarily doing ok. Or indeed if nobody asks for something, it doesn’t necessarily mean they don’t want or need it.
• #30: A great model. In a higher ed context where perhaps the product is one that staff and students have no choice but to use, you might change the top circle to everybody hates the product.
• #31: Back to the story… So we introduced an advanced search link – very simply alongside the search box when initial results were presented, in much the same way as Google do. But if anyone chose to click it, they wouldn’t get any new features. They’d just get a message saying we were planning to implement advanced search and inviting them to tell us what they want to see.