Navigating the MVP landscape: Insights from a designer’s perspective

Before we dive into the world of MVPs, let me start by sharing a bit about myself. In the realm of UX, people often identify with specialties such as ‘research,’ ‘design systems,’ or ‘interaction.’ However, I’ve always found myself drawn to one particular niche: I’m a designer who designs Minimum Viable Products (MVPs).

You might wonder how I found myself on this path. The answer lies in my career journey, which has been consistently intertwined with MVPs. Whether it was crafting an MVP for a pre-seed hospitality startup during my college years or creating an MVP for chamjo.design while awaiting graduation, MVPs have been my constant companions. Today, I’m deeply involved in building several MVP features.

Now, you might ask, does this make me an MVP expert? While I recognize that you may have your distinct perspective, I’m I’m thrilled to share five invaluable lessons I’ve learned along the way and invite you to join me on this learning adventure.

Getting acquainted with MVPs

To begin, let’s ensure we’re on the same page regarding MVPs. An MVP is an initial version of a product that serves a singular purpose: solving a customer’s primary problem. It doesn’t require full automation at this stage; it merely needs to fulfill its intended function.

MVPs are typically developed quickly and with minimal or even zero cost. They serve as tools to validate whether a proposed solution is genuinely needed or if it’s just hype.

What have I learned along the way?

#1 Streamline your design process

Just because it’s an MVP for a new feature or product doesn’t mean you have to employ every design method in your arsenal. Planning a method or step for just five minutes can extend your project timeline to more than a week. Each step doesn’t conclude after execution; you must also plan the transition of results to the next step, which demands significant time and effort. From my experience, focusing on benchmarking, design, and internal testing with your team and friends is often sufficient for gaining insights and building a solution. Afterward, consider post-launch plans, such as research to improve metrics or refining the user experience based on feedback from the initial launch.

#2 The key ingredient: Benchmarking

Conducting extensive research can be time-consuming and resource-intensive. After conducting research, you still need to process data, cluster it, and follow up with participants. I realized this when working on a case study. I questioned whether it was worth duplicating research efforts when many companies had already conducted similar studies. It was during a 1:1 meeting with Ravi Mahfunda, my Senior in Design, that his words resonated with me: ‘Why bother to do that? Just stand on the shoulders of giants.’ Inspired by his advice, I adopted a benchmarking approach. By evaluating competitors, forming hypotheses about their approaches, and making decisions based on their successes, I saved time and resources. This “mirroring” approach proved beneficial, as most feature requests for chamjo.design were variations of what competitors were already doing. While comprehensive research is valuable, it may not be the best use of time within the tight MVP timeframe. Remember, MVPs are about learning, not overthinking.

#3 MVP designs can be visually pleasing

Your MVP represents the first impression of your solution. Although speed is crucial, it doesn’t mean your MVP should lack visual appeal. To expedite the UI design phase, consider utilizing components from the device’s operating system or library. You might think default components are unattractive, but take a look at Telegram. It expertly balances iOS components with custom elements to match its branding without starting from scratch. This approach not only accelerates design delivery but also reduces the need to focus on component-level interactions and states, saving time and ensuring a more complete product feel.

#4 Invest in design details when possible

Amid the fast-paced MVP development process, details can often be overlooked or undervalued. However, these seemingly small impacts can accumulate, potentially affecting your product’s quality. I encountered a situation where an MVP didn’t perform as expected due to overlooked interactions and visual issues. This oversight led to additional efforts pre-launch, essentially picking up a new task in the middle of preparations. From this experience, I learned the importance of investing time and effort into comprehensive deliverables, including logic, interactions, specifications, and prototypes. Even if the devs don’t ask for it, that doesn’t mean they don’t need it.

#5 Three vital mindsets: User experience over advanced features, avoid overthinking, and prioritize simplicity

Designing and building an MVP can be exhilarating, but it can also lead to distractions. You might find yourself wondering whether to prioritize one feature over another, based on potential future additions. This kind of thinking can cause decision paralysis and unnecessary effort. Instead, I’ve learned to plan product or feature phases, focus on the current phase, and create a remarkable experience tailored to that phase. This approach not only speeds up launch times but also directs effort toward creating an exceptional customer experience, something customers value more than over-the-top feature roadmaps displayed on your website.

Takeaways

Overall, my journey has taught me several key lessons:

1. Streamline your design process by focusing on essential steps.
2. Benchmarking can often replace time-consuming research.
3. MVPs can be visually appealing without sacrificing speed.
4. Invest in design details when time permits.
5. Maintain three crucial mindsets: prioritize user experience, avoid overthinking, and embrace simplicity.

It may sound challenging, but I’ve found that these principles are practical and applicable in my current role, where we execute MVPs. I’ve realized that designing for MVPs is not fundamentally different from designing for fully-fledged products. Both require a similar mindset, with the main difference being a need for slightly faster execution and a bit less obsession with perfection to meet tight timelines while avoiding the trap of never launching.