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
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
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
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!