Balancing Simple and Useful

Lots of buttons means it’s awesome… right?

I had a recent Uber ride in a Ford Explorer and was incredibly overwhelmed by the quantity of buttons on the dashboard.  It occurred to me that there must have been dozens, if not hundreds, of people in the design and review cycles for this product before it went to market.  I wondered if at any point in time someone stopped the meeting to ask: “Is this the best design for our average user”

By contrast, the picture below is of the steering wheel of a Formula one car. The design is by no means simple.  But, every one of the buttons is designed for a specific use case that the driver needs to perform during the race.  Nothing in the car is there because a designer said to themselves “I guess they might need a button to do XYZ… lets throw it in so the marketing guys stop bugging us about innovative features.”

Upon further analysis of my preferences, I realized I have a bit of crush on things that are very useful but are also simple.  The trick is to figure out how to balance these two sides of the simple/useful equation… It’s harder than you think.

Should I start with the most features and remove them, or start with minimal features and make additions?

I love the concept of the the 11-Star experience that Brian Chesky (founder AirBnB) talks about with Reid Hoffman on The Masters of Scale Podcast.

To paraphrase their discussion:  Think about the best experience in your industry, this is a 5 star experiences.  Keep adding extreme improvements until you figure out how to make the experience an 11 star experience.  Within the ideation process of getting to the 11 star experience, you will identify 1-2 potential realistic nuggets of insights that you can apply to your product to differentiate it from the rest of market.

At the opposite end of the spectrum, there is Eric Ries’s Lean Startup model of building a minimal viable product (MVP) to meet the needs of the problem you are trying to address.  Build, release, and measure the MVP product to test whether it solves the problem for the customer (and if they will pay for it). Repeat this process until you achieve product market fit.

Between these two models, I tend to lean towards the Brain Chesky’s model. This is most likely due to the reality that in the “enterprise world” you only get one shot to get it right before the executive suite and board start breathing down your neck to produce results.

The typical steps I will take to define a solution are:

1. Build an understanding of the problems and objectives of the customer / client. (e.g. Improve will-call order pick time in 2019 to improve low customer satisfaction scores).
2. Build an understanding of the existing user process and experience. (e.g.  They use a call center and fax paper picking slips to pull product)
3. Build an understanding of how other people have solved this problem in the market, or if there are tools that we can leverage to solve this problem.
4. Brainstorm how to develop the ultimate solution (or process/product) to solve the problem.
5. Remove as many features from the “Ultimate” solution as you can while still meeting the needs of the customer.
6. Identify if any of the parts or features you removed would make the product more than 20% more useful than the minimal solution required.
7. If the cost/benefit of re-adding any of the removed features is worth it, add them back into your product

At the end of this process, I am left with a direction for how to approach a solution to give me not just a minimal viable product, but also a product that is useful enough to be differentiated from some of the existing products in the marketplace.

 

Is there are framework for making things simple?

Once I have gone through the above process, I will typically put the solution aside for a period of time, then I will come back and do an objective review to determine if it can be made more simple.  

The following are the framing questions I use to help guide me in the objective simplification analysis:

1. What is the purposes of every part –  When you look at all of the components in your solution, do you understand how each one of them contributes to the usefulness of the solution?.  Are there any duplicate or redundant parts that can be removed?
2. Could I swap parts with a cheaper alternative –  Are there cheaper alternative parts that can get the job done? Why would or wouldn’t you want to swap them?
3. Is it easy to assemble –  What skills do you need to assemble and integrate your solution?  It is something that I can document and easily teach someone with less skill to build?
4. Where is it fragile –   What in the solution going to break?  How is it going to break? If those parts break, what is the impact?  Can those weak points be replaced with something more robust?
5. Is it easy to fix –  If this solution breaks in the future, how easy will it be for someone else to fix? Is there anything we should implement to make it easier to fix?

The above questions are designed to help you mentally model and design before you start iterating.  As with any framework, this approaches does not always get me the correct answer at first, but it does help speed up the journey toward simple and useful.