Requirements are hypotheses: My experiences with Lean UX
•Descargar como PPTX, PDF•
4 recomendaciones•4,900 vistas
The document discusses Lean UX and how requirements are actually hypotheses that need to be tested. It provides examples of using Lean UX practices like creating hypotheses statements and testing assumptions quickly and cheaply for a university website search feature and customer support system. The key aspects of Lean UX discussed are reducing waste by not building unwanted features, prioritizing learning over delivery, and getting feedback from users to validate assumptions.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Requirements are hypotheses: My experiences with Lean UX
Similar a Requirements are hypotheses: My experiences with Lean UX (20)
Más de Neil Allison
Más de Neil Allison (18)
Último
Último (20)
Requirements are hypotheses: My experiences with Lean UX
- 1. Requirements are hypotheses My experiences with Lean UX Neil.Allison@ed.ac.uk UX Manager, University of Edinburgh @usabilityed #IWMW16 #P1
- 3. Just because nobody complains doesn’t mean all parachutes are perfect @usabilityed #IWMW16 #P1
- 6. What is Lean UX? "Inspired by Lean Startup and Agile development, it’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way. We work to build a shared understanding of the customer, their needs, our proposed solutions and definition of success. We prioritize learning over delivery to build evidence for our decisions." Jeff Gothelf @jboogie @usabilityed #IWMW16 #P1
- 7. Or to really boil it down… Requirements are assumptions Jeff Gothelf @jboogie @usabilityed #IWMW16 #P1
- 8. Willie Wonka didn’t do Lean UX https://youtu.be/_Kp5zhM23DE?t=2m45s @usabilityed #IWMW16 #P1
- 9. Feature focus Reduce waste. Don't build things that people don't want. @usabilityed #IWMW16 #P1
- 11. Lean UX hypothesis statement • We believe this [business outcome] will be achieved • if [these users] successfully • [attain this user outcome] with • [this feature] @usabilityed #IWMW16 #P1
- 12. The Lean UX cycle @usabilityed #IWMW16 #P1
- 13. Putting Lean UX into practice #1 CMS user support provision @usabilityed #IWMW16 #P1
- 14. Following the Lean UX for enterprise steps… 1. Begin with a specific desired outcome for the business 2. As a team, work towards this by collaboratively establishing: • What business outcomes are important to us? • Who is the user? • What outcome does the user want to achieve? • What features will they need in order to do so? @usabilityed #IWMW16 #P1
- 15. CMS user support goal "We see a month-on-month reduction in one-to-one time spent supporting customers with CMS-specific questions" @usabilityed #IWMW16 #P1
- 16. Business outcomes • Grouping the results of our individual brainstorming • We then dot voted to identify priorities @usabilityed #IWMW16 #P1
- 17. Meet our CMS users @usabilityed #IWMW16 #P1
- 18. Rough personas • Creating rough personas to get yourselves started is ok • The point is to externalise assumptions, not definitively identify your audiences • Engagement with users later will help to evolve & validate them @usabilityed #IWMW16 #P1
- 19. Outcomes for our personas • Brainstorming again, we identified potential needs our users have • We associate particular needs with particular types of user @usabilityed #IWMW16 #P1
- 20. Mapping features • We identified potential features • Using a simple table, we began formulate service hypotheses • The columns correspond to the blanks in the Lean UX statement @usabilityed #IWMW16 #P1
- 21. Example hypothesis • We believe an increase in user support self service will be achieved • if Ed successfully • gets a walkthrough key features and top tasks with • video guidance to supplement written support materials @usabilityed #IWMW16 #P1
- 22. Example hypothesis • We believe an increase in user support self service will be achieved • if Olive successfully • gets a quick answer to their CMS support question with • an enquiry form that suggests FAQs based on keywords @usabilityed #IWMW16 #P1
- 23. Now what? Get lean! •What is the smallest thing we can do or make to test our hypothesis? •What do we need to learn first? •What is the least amount of work we need to do to learn that? @usabilityed #IWMW16 #P1
- 24. User support: An ongoing experiment • We are experiencing a downward trend in our support calls • Lots of factors at play though • The videos • Analytics shows they’re well used • Anecdotal user feedback is good • We’re growing the catalogue • The smart enquiry form • 2% of visitors to the form subsequently submit a support call • A majority still access our support queue via email • We need to do some usability testing @usabilityed #IWMW16 #P1
- 25. Putting Lean UX into practice #2 Website search functionality @usabilityed #IWMW16 #P1
- 26. Website search features • We ran a feature survey in late 2014 with staff and students (http://bit.ly/1ujCjhD) • ‘Advanced search query builder' came 3rd (11% votes) • Top 3 = 35% • Top 5 = 56% • Technically a ‘quick win’ • UX potentially a nightmare @usabilityed #IWMW16 #P1
- 27. Are you sure you want that? Really? • It's well established in research that what people say and what they do aren't the same • We typically think that we want more power & more features, when really we appreciate simplicity and efficiency @usabilityed #IWMW16 #P1
- 28. Back to Benny…
- 30. What’s the quickest way to check? @usabilityed #IWMW16 #P1
- 31. What’s the quickest way to check? @usabilityed #IWMW16 #P1
- 32. And guess what… • We revealed this on 3 separate occasions for short periods • It was seen 35,097 times •Click rate - 0.003% @usabilityed #IWMW16 #P1
- 33. Benefits of testing this hypothesis • We reduced development time on something of limited benefit • We learned stuff about our customers • We focused our efforts in other areas • Responsive design for search results • Easy filtering by relevance and currency • Autocompleting filtering of contacts by keywords @usabilityed #IWMW16 #P1
- 35. Start hypothesising • Try to head off the feature-first approach with the Lean UX hypothesis statement • Get creative with how you test the hypothesis • Help your managers by • Framing their request • Providing data to inform decisions • Minimising the effort you commit upfront • It’s not a validation effort if you’re not willing to kill the idea (More about our experiences: http://bit.ly/UoE-Lean-UX) @usabilityed #IWMW16 #P1
- 36. Thank you Questions? Neil.Allison@ed.ac.uk UX Manager, University of Edinburgh @usabilityed #IWMW16 #P1
- 37. Photo credits • 2: https://pablo.buffer.com/app# • 3/28/36: https://upload.wikimedia.org/wikipedia/commons/c/c1/Benny_Hill.JPG • 4: http://focusedpurpose.blogspot.co.uk/2013_04_01_archive.html • 5: https://commons.wikimedia.org/wiki/File:Tree_in_field_during_extreme_cold_with_frozen_fog.png • 6/7/9: http://www.jeffgothelf.com/lean-ux-book/ • 8: https://youtu.be/_Kp5zhM23DE?t=2m45s • 9: https://twitter.com/mr_mike_clarke/status/484604575157342209?lang=en-gb • 10: http://www.slideshare.net/jgothelf/building-a-culture-of-learning/19-jboogiefeatures_on_their_own_are • 12: Josh Seiden @jseiden www.neo.com • 27: http://www.mcdonalds.com • 29: https://twitter.com/davidjbland/status/467096015318036480
Notas del editor
- Always start with an inspiring quote. Any ideas whose words of wisdom these belong to?
- Bet you didn’t know Benny Hill knew UX? I’ll come back to him later…
- 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
- 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?
- 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?
- (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?
- 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”.
- 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.
- 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.
- 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…
- 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.
- 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”
- First we brainstormed ideas for business outcomes that we thought would support the overarching goal, grouped and rationalised them, and then dot voted.
- 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.
- 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.
- 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.
- 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.
- Write up from the table full of post it notes; the three hypotheses we decided to pursue.
- 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.
- If McDonalds surveyed customers they’d almost certainly claim to have more interest in salads than the evidence shows.
- 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.
- 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.
- 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.