Building a minimum viable product? It needs to be beautiful above all else

Aesthetics and app development
Share this content

There is undoubtedly a common aesthetic we share as human beings. We can marvel at the beauty of a sunset and we can unanimously agree - with the possible exception of his mother - that Wayne Rooney is no oil painting.

It is undeniable that we are aesthetic creatures, and we make judgements of value and worth based on how things look. It's unfortunate perhaps, but not surprising, and a browse of the Daily Mail app or Instagram will quickly show that we are obsessed with how things look.

So, how important are the aesthetics of an app or website when bringing a new product to market? How important is form versus function and what does this mean in the world of the lean startup and the Minimum Viable Product (MVP)? Is there a ‘minimum viable aesthetic’ we should be aiming for or does minimum viability apply only to functionality? 

What first attracted you to multi-millionaire Paul Daniels?

You may remember this hilarious quip by Mrs Merton when interviewing the late TV magician’s wife Debbie McGee. But the same is true in the app world. Money and power go a long way even if you don't look very appealing - take Gmail as an example. But startups don't have this luxury - we know we're in a beauty parade and you ignore this at your peril. 

If the app isn’t fast, people will quickly lose interest and start thinking about how this will impact their productivity.

So, where does this leave us on a limited budget, building an MVP when trying to balance form versus function? First of all, we need to agree what the purpose of our MVP is. Importantly we need to be clear ‘why’ we are creating an MVP before we can determine ‘what’ it should be. I’m going to be rather broad in my definition and say that the ‘why’ is two-fold:

1) To prove that our product will appeal to customers

2) To prove that our product will appeal to investors

Now there may be those for whom an MVP is only a means to prove to themselves that a particular concept works, but I am going to assume for the purposes of this article that what we want from our MVP is to get the buy-in, emotionally or financially, from other people.

It’s not what you do it‘s the way that you do it

So where do aesthetics, the look and feel of a product, fall into our list of priorities when creating an MVP on a limited budget and timescale?

Let’s consider the requirements for a shippable product first and work backwards stripping away the layers of necessity to reveal our MVP.

A shippable product must balance functional versus non-functional features within a given budget and time to market. Functionality is ultimately why a customer will use our product because this is what solves their problem. But in a market where people are saturated with apps, and where we have competition, it is the non-functional features that will differentiate our offering. The trick, of course, is determining how much of your budget you spend on non-functional versus functional features.

I have distilled the non-functional features of a software product and rated them in order of importance in the following list:

1) Make it beautiful! How the product looks, and how the user interacts with the product, traditionally called UI and UX (User Interface and User Experience) are vital. If people don’t love your product and your brand, you are making life very difficult for yourself. If they love you, then they will forgive a multitude of mistakes, and you will make plenty of mistakes when developing a new product!

2) Make it fast! If the app isn’t fast, people will quickly lose interest and start thinking about how this will impact their productivity. This should be obvious and needs no further explanation or justification.

3) Make it reliable. If a user puts some data in, then they should expect to be able to get it out again. The user needs to be able to depend on the app, so it must be robust. If it is not, they will soon stop using it.

4) Make it secure. Often the last question to be asked before your application is adopted, and frequently one asked by enterprises when looking at solutions from startups, they want to know how secure their data is, not an unreasonable request is it?

So, why this order? Well if it’s not immediately obvious; think about the list in the reverse order. You may have the world’s most secure app, but if it cannot be relied upon, who needs security? Now suppose you have a secure and reliable app, but if it takes forever to load screens, then you’ll be lucky if people aren’t falling asleep in your demo.

But if it looks horrendous, then you’ll never get the opportunity to tell people how fast, reliable and secure it is because they will have made their minds up in the first few seconds of seeing it that they don’t like it. The first few seconds of your demo, or of a user’s experience with your app, will define their relationship with you forever.

Now run the scenario through in the correct order: you present a beautiful app, and people will start off in a positive frame of mind liking your product and wanting you to succeed. From this point onwards they will actively look for ways to overcome any issues that may exist about speed, reliability and security or, dare I say it, even functionality.

It’s not to say you can deliver a slow, unreliable and insecure product as long as it looks nice, that would be crazy. But it does mean that you will have an opportunity to discuss and address any issues because people have already bought into your brand and product.

Peeling away the layers

Now let’s strip away those layers until we get to our MVP. Do we need it to be secure? Well maybe, but if we are just demonstrating a concept with dummy data, maybe not. How about reliable? Well, yes, it would help if it’s reliable, but people realise it’s an MVP so it’s not going to be one hundred percent.

How about speed? Well it would certainly help if screens load fast that’s for sure. But if you had to pick just one of these elements for your MVP, I believe it should be to make it beautiful! If you do a good job here, then you can work on everything else with the support of your users and investors.

To distill it down, I would say you can largely (but not completely) ignore security, reliability and speed for an MVP, but do not ignore look and feel. How important is look and feel compared to our functional requirements? I’m going to fly in the face of Eric Ries and the lean startup brigade on this one, because I think it really does matter how your MVP looks; the same rules apply because it’s the same human nature and you should sacrifice functional features to a point where your MVP looks great. Then you’ll have the hearts and minds of your users and investors, and they’ll support you while you introduce new functionality and solve the issue with speed, reliability and security because they’re in love with your product. Now that’s what I call magic!

About Paul Lewis-Borman


Paul Lewis-Borman is Founder and CEO of Meetzoo, a UK based tech startup that aims to improve business meeting productivity. Meetzoo are currently crowdfunding on the UKs leading equity crowdfunding platform. Invest here:


Please login or register to join the discussion.

01st Jul 2017 01:41

Good advice - totally agree that design is key to MVP success and, in most cases, simpler is better. Less options and clutter means fewer things that can break. But I always build the back end (even the first iteration) using a proven, robust framework so that security is not an afterthought.

Meetzoo looks like a great project.

Thanks (1)
to bradleyhook
03rd Jul 2017 19:45

Thanks for your comments Bradley. You're spot-on that using proven techniques and best practices means you can address non-functional things like security implicitly to some extent. One problem with the lean startup idea is the technical debt that accumulates in the rush to get to market, particularly when building on top of an MVP. I've heard it suggested that an MVP should be thrown away and the shippable product built from scratch. Maybe that's good advice, but I doubt many people have the budget/time/inclination to follow it :-)

Thanks (0)