The BUS product design framework
A step by step playbook to tackle any project
I commend you for clicking on this even after seeing “12 minute read”. I’ve broken this manual into 3 parts to help you out. I suggest you read through chronologically, but I also know you probably don’t have a lot of time, so feel free to jump between them. Don’t worry, I’ll try not to be too offended.
Part 1 — Credibility for the Framework
Part 2 — Why the Framework is so Powerful
Part 3 — Applying the Framework
Too few people treat online opinions with the right amount of skepticism these days. On top of that, when I screen design applicants I always look for the ability to critically evaluate every new tool or process. So, read on and decide for yourself whether you should pay me any attention!
I’ve been designing and shipping products for a decade now, having been part of 4 different product teams & companies. To most of you I’m probably a random internet blogger, so I’ll try and give some credibility before diving in.
I was a product design lead for a Series A startup tripling their users into the millions, working with brands like Coke, Nintendo, and more. I write for 3 of the 5 largest Medium publications, have recruited & managed a design team, screened countless design applications and interviewed a myriad of UX/UI/Product designers. And if there’s one thing I’ve learned through all that, it’s that the creative process is inherently unstable. Someone once described it as controlled chaos — probably the best definition I’ve heard so far.
There are so many moving parts, from product management to design & development that at times it feels like everyone’s just running around like chickens with their heads cut off. Usually at least one fellow avian tries to pretend that he has a head, holding a pineapple with sunglasses where it used to be.
This framework has helped me systemize my decision making, navigate extreme uncertainty & risk, defend my decisions to stakeholders, and convince team members to rally behind ideas. If you’re convinced that this is worth a few more minutes of your time, read on!
The BUS framework stands for Business problem, User problem, and Solution — in that order. This framework of thinking has helped me tackle almost every product design job I’ve ever had to do — except in my earlier career I wasn’t skilled enough to systemize my decision making process like this. Now, I apply this framework to 100% of my product processes, and it has helped me navigate the headless chicken pen with a significantly increased degree of control.
There are two main reasons why this design framework is powerful:
- It’s a logical flow that mitigates the risk of being wrong as you go
- It gives you a pivot playbook for when to stop and investigate further, and when to keep going
1 — Mitigating Risk
Think of designing products as the whittling down of a long list of unknowns. At the beginning, you have zero idea if anything that you’re doing will actually achieve the outcomes you’re looking for. Through the process of researching, validating, etc. you slowly turn that long list of unknowns into knowns.
That’s where following this framework is incredibly useful. If you start with first understanding the Business problem, then move to the User problem, then move to the Solution in that order, getting each step right significantly reduces the risk of next step being wrong.
It’s additive — the solution being useful is contingent on solving the right user problem. Solving the right user problem is only useful if it solves the right business problem. I’ll explain.
If you’re redesigning a bank’s ATM, you need to first understand the business problem — the fact that the bank doesn’t have enough deposits, and their revenue is directly tied to it. If you started instead by looking at the user problem of “the user interface of the ATM is confusing” and just solved that, you may find that the client/pm’s desired goals still won’t be hit.
In other words, maybe simply making the ATM more usable (and thus solving the user problem) will only serve to get more people to withdraw money, not deposit! That’s still a losing outcome for the company if the business problem was that not enough people were depositing.
Instead, if the client/pm asked you to redesign the ATM and you found out that he/she was really just trying to get more people to deposit money, you could reject the idea of an ATM altogether! Maybe depositing cheques via mobile phone is the best solution.
The same applies to the solution part of the framework. If you’re not solving the right user problem, it doesn’t matter if you design the most usable ATM in the world. Perhaps people aren’t avoiding ATMs because they’re confused by the interface, but because the screen takes too long to load and people are in a rush! Getting the user problem right before attempting any solution at all is a much safer way to de-risk the end product.
Confused yet? Try this. Think of it as a pyramid. If you don’t set the foundation right, your pyramid is likely to be built on shaky ground. Aka, if you don’t get the business problem right, you run a much higher risk that your final product won’t be successful. But if your business problem is right, the only risks you’re taking is with the user problem and solution. The same applies to the user problem — if that’s right, the only risk you’re taking is that the solution is wrong.
Most designers I interview fall into the first category — establishing a very shaky foundation of assumptions about what they’re trying to solve for the business and user. They spend all of their time on the solution and whether it’s a good one, creating a completely lopsided pyramid, and frankly signals an inability to manage risk.
2 — A Playbook for Pivoting
The other reason why I’ve found this framework incredibly effective is because it allows you to pivot at the right place in the process to reduce the amount of wasted effort you incur.
How many times have you designed something, only to find out weeks after you ship it that nobody actually wanted what you built? It sounds stupid, but I’m guilty as charged, as I’m sure many of you are also. Boy was I slapping myself silly after I sank six months designing a product only to find nobody really had the problem to begin with.
If you follow the BUS framework and spend the necessary time investigating and reducing the number of unknowns in each step, you’re much more likely to have an end product that will actually deliver value.
For example, let’s use the ATM again. Let’s say you shipped a new ATM interface, and the bank’s revenue did not increase. Because of this framework, you now know exactly how to retrace your steps to figure out where you went wrong.
Start in the reverse BUS order — was the new interface a good solution for the user problem? Aka — did making the ATM buttons bigger solve the user problem of people being confused? If you’re confident that the solution did in fact make the interface less confusing (you can back it up with user research), then trace back further in the BUS framework to find the problem.
Going back a step further means looking not at the solution, but the user problem. Was it actually the right one to solve to achieve our business goals? Aka — were people depositing less because they were were really confused about the interface? Perhaps you’re less confident about this one. Great! Time to pivot. Swap out the user problem.
Now, as long as you’re sure that the business problem is correct (that few deposits are causing low revenue) then you can try solving it by solving a different user problem. You can keep trying different user problems until you hit the right one. Maybe at this point you go and talk to a few users and ask them why they’re not depositing. Perhaps the data shows it simply takes too long to drive to the ATM!
Now you have some new information — that the user problem is in fact that it takes too long to get to the ATM, not that using the ATM interface itself is actually confusing. Armed with this information, you’re much more likely to have a solution that actually accomplishes your goal.
The BUS Hypothesis
At every point in the design process, even if you’re tweaking the interface layout, you should be able to recite the BUS hypothesis. Aka — know why you think what you’re doing is going to solve the business problem. This short sentence will help you defend your decisions to stakeholders, get people on board with your ideas, and frankly help other smart people show you where your biggest risks are.
All you need to do is repeat what it is your building, and why it is your building it, from the solution back to the business problem (that’s BUS backwards). Using the ATM example again, the hypothesis over the entire project would be:
- By making the buttons bigger (solution),
- We will improve the usability of the ATM (user problem),
- Which will help increase the number of people who deposit money (business problem).
If you can recite the BUS hypothesis blind, you’ll find that it will even help you see where the biggest risks are in your process. Maybe you’ll think about it and realize that it’s a really big stretch that improving the usability of the ATM will increase the number of people who deposit money. Great! Time to pivot.
Start with the Business problem
When I run design exercises with applicants, I always look for this first. If the ask is “Redesign the ATM”, I expect the candidate to ask “Why does this matter to the business?” and trace the logic back to a company KPI like revenue.
If the client, pm, etc. says the reason they want to focus on the ATM is because they’ve heard that it’s confusing for people, your flags should immediately go up. That’s a user problem, not a business problem.
Generally, some of the key questions you want to answer as a designer at this stage are:
- What is the actual root business problem (which company KPI is being affected. Revenue? Cost?)
- How do we know that’s a problem (low conversion, lots of support calls, poor retention, etc.)
The goal is to fully understand where the request is coming from, and what the real goal of the business is. Often times by the time the problem lands on the designer’s plate, it’s actually presented as a solution that the PM already thinks is correct. Don’t take things at face value, dig into the root causes and challenge the thinking — after all, it’s for the client/PM’s benefit at the end of the day anyhow.
What this will let you do is focus all your efforts on the right goals. You can pivot which user problem you solve, based on whether you think they will end up solving the root business problem that you dug into. For example, once you know that the business problem is that not enough people are depositing money, you can try a number of different user problems to achieve that goal.
Before you move on, make sure you are aware of all the assumptions you’re making with the business problem. Of course the best case scenario is that you understand it 100%, but most of the time your schedule doesn’t allow for that — and if it does, you’re moving too slowly. It’s often more effective to understand it 70%, and know what you are deliberately taking a risk with on the 30%.
“Most decisions should probably be made with somewhere around 70% of the information you wish you had, if you wait for 90%, in most cases, you’re probably being slow.”
— Jeff Bezos
Remember, as I mentioned above, the Business problem is the foundation of the pyramid. If you don’t get it right, likely the rest of what you do will fail to reach your desired outcomes.
Once the business problem is settled, move to the user problem
This is the part that most designers are familiar with. The key questions you’d want to answer at this step are:
- Which user problem is causing the business problem? (You can find these answers by doing user interviews, ethnographic studies, diary studies, quantitative metrics, etc.)
- Why is it a problem? How do we know it’s a problem? (You can use a lot of the same tools as the one above.)
Once you’re certain you’ve got a good set of data to work with, you can present those findings & ideas in a form that people understand with Personas, User Journeys, Flows, etc.
Watch out for surface level problems — people often like to say things like “your site is bad” when they really mean things like “I clicked a button on my mobile device and the next screen was blank”. As with the business problem, drill down to really understand what the right user problem is. Otherwise, your solution won’t solve it.
I know I said to always start with the business problem, but as with most things, rules are sometimes meant to be broken. Sometimes a single inflammatory tweet from a customer will zero you in with a microscope on that single problem the person is facing. Many times that’s just a vocal minority and you should take it with a grain of salt, but there are times when you should solve that user problem right there and then, knowing that the business impact of not doing so is disastrous.
For example, if someone tweets “Your ATM exploded and there’s shrapnel in my right cheek” — you should probably investigate the user problem immediately. Having the business problem at the back of your mind is great, (if another ATM spontaneously combusts you will probably lose customers, losing you revenue) but starting by investigating the user problem is in this situation your best course of action.
Once you know the Business and User problem, focus on the solution
Remember, that if at this point the B or U of your framework is wrong, your solution is almost guaranteed to flop. If you don’t fully understand what problem you’re solving, you will most likely make something nobody wants!
When you’re ready and armed with enough information, ideate! Often times this process is fluid, unpredictable, and a bit chaotic. It can involve a few people in a room with stickies, a chat over lunch, a shower, and more. Ideas come from anywhere, and the important part isn’t even so much that you have the right one right away, but that you have many.
Once you’ve got ideas, you need to answer these questions:
- Which idea will solve the user problem, thereby solving the business problem? (user tests, interviews, beta tests, paper prototypes, etc. will all help you choose.)
- How confident am I that the solution will work?
Watch out for things like confirmation bias, and just plain old ego. You are not your product, and it’s very likely that the one you chose won’t work. Find more ways to increase your and your team’s confidence that the product will be a success.
And that’s the BUS Framework! Try it out, apply it, and comment & tweet me about whether it’s working for you. As with any framework, it warrants experimentation and improvement. I’ve personally found a ton of success when approaching product design with it, hope you will too!