The trade offs of Minimum Viability vs. Maximum Value
In the final post for seminar 1, I try to navigate the process of designing for a product specifically in the digital world, weaving in my own experiences as a user experience designer at the Harvard Business School and Deloitte Digital.
As a UX designer working for a tech company under rigid deadlines, I have often been stuck between the dichotomy of the MVP versus a fully designed and user tested product. What is the sweet spot, how much should a design be fleshed out before it is released out into the world?
Let us start by understanding what an MVP actually is. The idea behind an MVP or Minimum Viable Product originates in ‘The Lean Startup’ by Eric Ries, “An MVP is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. To explain this in simpler terms, an MVP is a stripped down version of the final product, it often contains most of the important functionality, but does not account for the time to iron out the user experience, aesthetics or test the solution with end customers.
The core idea behind an MVP is creating a solution for validating ideas. By focusing on the core functionality of a product, it gives us the ability to check if the assumptions we made while designing were true. It allows us to put a product in front of end users very early on in the process, thereby providing a necessary reality check, ‘is this what the users really want?’ Incorporating feedback from early adopters often helps better align functionality to user needs, and helps get into a feedback loop where decisions are driven by customer feedback — not intuition.
But is this how it is practiced in the industry?
I was onboarded on to the Caterpillar team as a UX designer, the only designer to be added to a team of 30 developers. Caterpillar, a global manufacturer of large machinery and farm equipment reached out to Deloitte with an aim to create a portal that helps dealers search for a specific product amongst their 10000 products available worldwide. Currently, all of this data is maintained in excel sheets, spanning across their 500+ dealers in 180 countries.
A huge task technically, and presumably, a very exciting design challenge. But once I started with the project, the reality was very different. I was provided with a set of pre made technical stories (all tasks are broken down into ‘stories’ in the agile framework), and had very little leeway for what could be done with the design. Instead of thinking about what is it that the dealers really need, what was created was a skin, something that made the application look good. Rather than design driving the project, the project was driving the design.
While there are a lot of benefits of creating an MVP from the technical stand point, this process often ends up limiting creativity. The push to create a solution that is ‘good enough to deploy’ restricts blue sky thinking. Rather than coming up with ideas that push the boundaries of what is possible, it forces designers to think of solutions through the lens of engineering tools.
We need to redefine what we mean by an MVP.
Currently, we are using the MVP only as a testing tool, to check for technical feasibility. It is being used as a gauge to understand if something can be developed. There is zero influence of design or thinking until it becomes too late in the process to go back and change what we have already created. While the aim of an MVP is not to create a fully polished and designed product, it is our duty to at least give the users a part of the real experience if we want to get accurate feedback on whether a solution makes sense.
We need to start designing MVPs by using the strengths of the design process — to start to think about the wholistic experience from the very beginning. The MVP is not a proof of concept, it is a real product that we are putting in front of real customers, and we are responsible for the creations that we put out in the world. By adopting a user centric approach, we can get a perspective of the enter system and then design towards it, part by part.
After we finished creating the search portal for Caterpillar, we were tasked with redesigning the entire dealer facing experience for Caterpillar. 3 more designers were added to our team. This was the start of a new portion for design, and an opportunity to improve on our mistakes. We first started talking to dealers about the problems they were facing, and understanding where was it most valuable to create a new solution. This time around, our aim was to understand the entire problem from the beginning. Even if we built the product in parts, our knowledge could not have any gaps.
As we started working on the different sections of the dealer portal, we received feedback on what was it that was working and what wasn’t, and could learn from the feedback we received. With each subsequent release, we started gaining confidence in the product we were building, and could see this reflected in the confidence of our users. The technical stories that were originally assigned to us changed, and now became design stories that were provided to the development team! This was a big win for our small design team of 4 people :)
Creating an MVP and directly creating a final product both have their own strengths and weaknesses. A poor MVP is a bad representation of the solution, even to collect information but waiting to develop a solution fully is a long, repetitive process which delays product releases, and basically the actual start of the product. In order to best utilise the benefits of both approaches, we need to redesign how we leverage the MVP to give us the most benefit in order to understand what users need, such that we are creating the best solution possible. Adapting a modified design approach, such as talking to consumers and gathering information, requirements and expectations right from the beginning even as we build it out in phases is the middle path I feel we need to implement.
