Agile UX Assumptions Busting

In my many years as a UX designer I’ve also become a keen facilitator of trying to get clients’ thoughts from their heads onto post it notes. However, everyone knows what the clients sees, thinks and expects can be very different to what a team of developers may perceive as the big issues with the product you all are developing. There are problems, questions and assumptions all lurking underneath the surface of every project and they often receive little air time in the rush to close tickets and dash through sprints. Hence why I created this assumptions busting activity with my team at Data61.

UX Assumptions Busting can take as little as 30 minutes once per sprint or once per month. It uncovers what other members of the team have questions about, what threats they see lurking, and what ideas need to be pushed to user testing or factored into launch plans.

You will need

A miro board or whiteboard of some kind if you’re doing it in person
Post it notes
Timer
All the user stories from your current sprint

1. Set up your board

A miro board with one column of post it notes with "Owner" as the title followed by Kris on a pink post it, Yumi on an orange post it, Cath on a green post it and Victor on a purple post it. — An example board with example team members

Set up the first column allocating each team member a different colour post it note. This is important because all the post it notes should be colour co-ordinated so each person’s contributions can be distinguished from each other (I have no great solution for colour blindness options so please tweet/message me if you do!). Put the date at the top so you can make subsequent boards per sprint and track the progress for each session.

2. Add the User Stories

A miro board with one column of post it notes with "Owner" as the title and a second column with "User Stories from this sprint" as the title. The first column has Kris on a pink post it with "As a user I can order multiple coffees" as a user story, Yumi on an orange post it with "As a user I can order a delivery of multiple coffees to a workplace" as a user story, Cath on a green post it with "As a user I can track my weekly caffeine consumption" " as a user story and Victor on a purple post it with "As a user I can order my friend a coffee and send it to them" as a user story. — The Assumptions board, now with user stories?

Take the user stories that have come up for your sprint and allocate them against the person’s name who is responsible for them. For this example we are using (again, sorry, I’m unimaginative) a coffee ordering service. Keep all the user stories in a dedicated colour not used by anyone.

3. Getting out the assumptions

A miro board with one column of post it notes with "Owner" as the title and a second column with "User Stories from this sprint" as the title with a third column with "I am assuming the user can.." and " A question I have for UX is...". The first column has Kris on a pink post it with "As a user I can order multiple coffees" as a user story and "Account for the extra time in the order" "Does the countdown timer to the order need to be changed for more coffee?", Yumi on an orange post it with "As a user I can order a delivery of multiple coffees to a workplace" as a user story with the assumptions "Pick up the order from the reception of their building" "Does different pickup options need to be available", Cath on a green post it with "As a user I can track my weekly caffeine consumption" " as a user story with the assumptions "Understand the graphs from the library we're using" "Are we clear on how many people will want to use this?" and Victor on a purple post it with "As a user I can order my friend a coffee and send it to them" as a user story with the assumptions "Get delivery confirmation" "Do we send the delivery confirmation to the friend". — The board with the clear assumptions and questions.

Set aside 5 minutes for everyone to answer the questions of “I’m assuming the user can” or “A question I have for UX is…”. After 5 minutes is up, have a quick discussion of the issues that come up – they might have never been discussed before in the project or UX might have overlooked some micro interactions in the project in a rush to launch (guilty). Feel free to add extra notes if something needs to be clarified.

4. Discuss and take to testing!

After getting the assumptions out, gently discuss all the issues and facilitate getting them to concrete plans. To do this, openly get participants answering the questions “What should we push to testing” (controversial, but sometimes necessary tactic of doing good and robust user experience) and “What needs to be discussed with the team?”. Sometimes we don’t see things clearly because our priorities, as UX designers, might be in something else and the obvious has missed our attention. It can sometimes be a tough to facilitate this part as we cannot always do everything. However, this does provide the golden opportunity to prioritise different aspects of our coffee delivery app. In this case clearly a trial run with a store needs to be done but the personal caffeine graph might be a little de prioritised although posing important open questions. Maybe this needs even more UX should be hired to capture the difficulties of these problems and now there is consensus on this!

5. Wrap Up

After the discussion, make a commitment to follow up with the next Sprint. When it is time to write up a new user testing plan, you will have a wealth of open questions to answer. Happy assumptions busting and good luck!