Last year, I was lucky enough to attend the Design It; Build It conference, where I saw Tobias Ahlin give a talk on an idea he called “Design Bets”. (He will also be coming back to the University of Edinburgh to give the same talk in a couple of weeks – check out the info at the end of the post to book.)
Put simply, Design Bets is a framework which allows you to plan changes, and then evaluate the impact of those changes using evidence, not personal belief or bias. It is designed for software products, but could easily be used for any type of change management – e.g. for a business or other organisation. It’s also a great tool which allows you to quickly plan and see possible changes across many areas at once.
I was immediately interested in this concept, because we are currently running a project to improve student experience in MyEd. There are a lot of ways that we could do this, and lots of ideas were being tossed around. It was difficult for the team to keep track of what ideas had been discussed, and to easily understand what those ideas were.
We had planned an away day for the project team, and I wanted to use some of the time to work on our change planning as a group. Before the day, I put together a hypothesis deck for the project in PowerPoint, using the Design Bets framework.
The term “bet” in the title refers to the gambling risk of making change, but it is also an acronym which stands for “Belief Exploration Tree”:
- At the top of the tree is your overall goal. In our case, it was to improve student satisfaction. You should also give a metric to indicate how success will be measured.
- Below the goal, you have branches which represent different areas for potential change. Some of our branches were: “Use recognisable language that students easily understand”, “Improve user help”, and “Show contextualised (not generic) content”.
- Underneath each branch, list the ideas you have for making change in that area. Each idea should be stated as a hypothesis. You should give measures for how success will be met, and also state why you believe this idea will work. For example, one idea under “Recognisable language” was to make names and labels on the site more descriptive, rather than using internal service names.
The tree should be continually updated with new information as you start to implement changes. If the ideas within a particular branch are not showing any impact, that branch can be set aside to allow you to concentrate on other areas.
For our away day, I printed out the tree and laid it out on the floor so that everyone could see it. I gave a short presentation on Design Bets to explain the idea. We then moved over to the tree and walked through what was included. This gave everyone time to understand the concept and see what was there already. In many places, the ideas were quite sketchy and missing details.
We then took time for everyone to look at the tree, discuss, and add in their own ideas and notes. I brought along some blank templates, so that people could use these to add in new ideas easily, along with Post-it notes and pens. In some places, questions and additions were scribbled directly on the pages.
Finally, we came back together as a group and went over the whole tree again. Everyone was given time to explain their additions, and we discussed them as a group. In total, the whole exercise took about 2 hours. For us, this time was necessary because of the scale of what we were discussing. I imagine this could be shorter for a smaller project.
After the away day, we typed up a new version of the tree with all of our new additions and comments. This was then circulated around to the team for further discussion at project meetings.
This allowed everyone in the team to easily see what changes were being proposed, and to understand how they fit into our overall goals. Where work was already defined, we could link the idea directly to the related deliverables. This allowed us to see which ideas were already being progressed within the project. Ideas which had no related deliverables could then be discussed for inclusion, or put aside for future projects.
We also identified areas where we might need further work or clarification to progress an idea further. In many cases, we were lacking particular metrics to understand the impact of a change. These could then be quickly picked out to see which work might be riskier or harder to evaluate than others.
This ended up being a really valuable exercise for us. Everyone came away from the activity with a much better understanding of what we were going to do, and how we planned to do it. I hope to continue using our tree going forward, to help us make better, evidence-based decisions on how to improve MyEd.
Want to learn more? Tobias is coming to the University of Edinburgh to give his talk on Design Bets (30 March 2018, 10:30 – 11:45).
Staff and students book here: http://edin.ac/2FgVU3W