Designing a Startup MVP in One Week

Read for 10 minutes

We decided to write this article to demonstrate, using a real example and our team's experience, how to quickly (in just a few days) and effectively develop interfaces for an MVP using open libraries and an experienced UX/UI designer.

As an example, we chose one of our custom projects, which we started without any formal specifications and with minimal initial information. The project deadline was described as «We needed this yesterday!». What was notable in our case was how our specialists helped prioritize tasks, thereby meeting the client's needs and quickly achieving the result - ready MVP design layouts.

The approaches and practices described in the article can be adopted by any startup team to accelerate the release of new product versions and optimize design work. The generalized conclusions can be found in the final section 'Recommendations for Startup Teams from a Designer'.

The context

The founder of an early-stage startup from California approached us with the task of developing an MVP platform aimed at reducing cloud infrastructure expenses. The functionality involved allowing users to quickly monitor their server performance and receive recommendations for improvement. Later on, users could also order and pay for more cost-effective solutions.

Initially, the MVP was created for students at US universities who needed affordable servers. The first version was expected to have users install a script themselves to monitor server status, and then in the service itself, they would receive analysis results and alternative options.

The MVP's goal was to understand whether there is a market need for such a service and whether it addresses a real problem, not an imaginary one. Consequently, the initial implementation was to be done with a minimal budget and time. There was no direct automatic monetization planned in the first version. The first clients and payments were to be processed manually by the customer: this would happen after a client had used the service and was ready to pay for the connection of alternatives.

At the time our team was brought on board, the client provided limited materials: a few marker drawings reflecting their vision of the interface, and brief comments about the project idea.

In this case, the absence of interface design became the main obstacle to starting development. The product involved working with a significant amount of tabular data, and the interface had to be user-friendly and intuitive. However, at the beginning, we had limited details about the project, and it was unclear to the developers what exactly needed to be implemented in the first version.

The process of work

The client wanted to move from point A - just an idea in mind and chaotic hand-drawn layouts, to point B - a clickable MVP that could be tested with real users.

My task was to translate the client's idea into a concrete sequence of actions and screens for the developers. But before shaping the optimal user journey into a tangible interface, it was crucial to understand the product's value and how, according to the client's vision, users were supposed to receive it.

Breaking down complex tasks into simpler ones helped to understand the details and transform the initial data in the form of marker sketches and comments into a clear user flow - the path that a user needs to follow to achieve their goal.

We received this user flow on the 4th day of working on the project. The first 2 days were spent immersing the designer in the context of the subject area. To do this, it was necessary to delve into the specifics of working with cloud infrastructure, consulting with our backend developers, and asking them about CPU, GPU, RAM, why these data are important for technical specialists, etc. The remaining 2 days were spent on clarifying questions for the client and forming a comprehensive user journey.

After immersing myself in the subject matter and interacting with backend developers, I moved on to clarifications for the client. For every unclear aspect in the sketches, I wrote down a question and figured out what was meant. For example, the sketches included a «Recommendations» section, and in order to incorporate this block into the final layouts, it was necessary to understand what form the recommendations would take, how and by whom they are formulated, and how this would help the product's users achieve their goal, etc.

The next step involved creating the first screens of the application, which could be discussed and adjusted. The remaining 3 days were mainly spent on synchronization through intermediate layouts via online meetings and demonstrations. This allowed us to fully understand the structure of the project, clarify details that continued to emerge during discussions, and increasingly reveal the founder's vision.

Accelerating the release of the first product version for user demonstration was facilitated by deviating from the standard workflow, where a designer hands over fully stylized, pixel-perfect layouts. In our case, the result of the designer's work were black-and-white prototypes that functionally covered all scenarios for the demo and were approved by the client in terms of embodying all their ideas in the product as needed. As a stylistic solution, we proposed using the ready-made Ant Design component library since our developers already had experience with it, and it functionally covered all the necessary elements laid out by the designer. This way, we found a compromise between the desired outcome and managed to drastically reduce both costs and time spent in the process.

Project outcomes

Before: There were 5 marker drawings from the client, which were too unclear for developers to use for product release.

After: Product layouts and a clear user flow were created, enabling developers to turn them into a functioning product using a ready-made component library

Project results in numbers:

7 working days or approximately 40 hours of designer work from receiving the task to the final layouts.
3 Zoom meetings with the client and 2 in-person meetings with developers for immersion in the subject area.

As a result of the designer's work, we gained the clarity we were missing. We figured out how the MVP should be presented to users.
Additionally, we ended up with a great dashboard. We managed to fit a lot of information onto a single page. Specifically for developers, it was a whole process of learning about styling tables. We learned many UX hacks, like aligning numbers to the right and text to the left. Developers often don't think about these things, and working together on such a project helped us understand many nuances.

The layouts underwent significant transformation during the design refinement process. The way the client initially visualized the project turned out not to be the most effective approach. Thus, during the demonstrations, the designer often received feedback like, «Ah, indeed, we can transition and combine things here and there — I hadn't thought of that. I needed to see it clearly.» Many components and their arrangements, as sketched out, were changed or simplified through the joint efforts of the team and the client. This saved the project from unnecessary rework in future iterations.

Additionally, we solved the problem of lacking convenient materials for demonstrating to potential users during customer development.

I really needed to see the finished layouts to understand how to more conveniently display all this data on the page. And generally, now I see the necessity to showcase the interface in some form, just to get some feedback from users. Without the layouts, in my customer development, I was stuck explaining to clients how the backend works, using words and marker sketches — I was fed up, this approach had run its course.

Recommendations for startup teams from a designer

Answers to the question«Who uses the service and why?» should be communicated by the founder, but the question «How?» is better answered by a designer. This will save time and resources for teams without an experienced UX/UI specialist.
Using open libraries isn't always justified, but it can radically reduce costs and simplify work on an MVP, the purpose of which is to quickly test its usefulness for customers.
Structured work and involvement in details are better than thoughtlessly 'drawing pixel-perfect layouts'. By starting with the question 'Who and why?', working through the user flow, clarifying numerous details, and only then moving on to interface design, we created a truly minimal version for achieving the user's goal, saving the client time and resources on reworking unnecessary components and screens in the future.

Subscribe to our weekly newsletter to receive similar publications directly in your inbox. We don't put ads in our newsletter, only materials from our Magazine :)