Does MVP mean Minimum Visible Precision?

It’s in Polish, but what it actually says is not that important.

I got an email from Google the other day. It was an automatic email but some parts of it caught my attention. I couldn’t leave it like that so I took a screenshot and moved it to Photoshop for a 3 minute fix. (mine is the one on the right in case you’re wondering) But Google is not to blame here, they are great at their core business and they are changing the world in many ways. This problem is a plague of every company (I’ve seen similar things from Apple, or even Microsoft who has upped their design game in the recent years). The thing is — those guys don’t have to try as hard anymore so they sometimes don’t. But what about smaller companies or products, with something yet to prove?

I have been thinking a bit more recently about the digital design execution and why it suffers from so many quality issues. It doesn’t really matter if it’s an MVP, or a finished product. There are exceptions of course — apps designed in such a beautiful and precise way that I’m in awe. One example that comes to mind is Wunderlist — I actually took some time on a 500x zoom with a pixel grid to examine that app. It’s one of the rare examples of “pixel-perfect” in action.

Creating styleguides (in this case for a web-app) can also help developers. Inputs type 1 and type 2 were created for A/B testing purposes.

But why should that be an exception instead of the norm?

When I took that time to examine Wunderlist, I also checked out 12 other popular apps (mostly from the Polish market) and sadly all 12 of them suffered from bad execution. Far from pixel perfect would be an understatement in some cases. Some of them had millions of downloads. That causes the users to get used to that sloppy execution which is a bad sign if we truly want to do quality work.

The definition of MVP is often portrayed with the drawing of a skateboard and then the car instead of just wheels first. Sure — that is understandable. The product has to work and has to be useful. But does it automatically imply that HOW it’s built doesn’t matter? Remember the 1997 iMac? If you do then try to also remember what did PC computers look like back then. They both could accomplish most of the same tasks — write a word document, listen to music.

Right now hardware manufacturers took their lesson from Apple (to some degree) and hardware is starting to look better in general. Software on the other hand is plagued with poor execution.

Ok. But why?

This of course is because of the way software is created. You have some project managers and some developers. Maybe a visionary CEO. If you’re lucky you have a skilled designer. A design is created and then it’s pushed to the developers. They implement it as best as they can — but they’re not designers (very few have a “designer mind” and that is awesome) so the end result isn’t necessarily what the designer imagined. The designer gets frustrated and sends in a list of “fixes” to make the coded product look and feel more like the design. Some can be implemented and they sometimes are. The rest is often considered “too difficult or time consuming” and gets axed. There is a way however.

When we designed our most recent product — Babynote — we considered every little detail and how to execute it. We consulted the developers on design ideas as we went, so we knew which elements or interactions were much harder to code and thus much harder to fix if the execution was not perfect. Knowing that we managed to build the app EXACTLY as we wanted it to look, feel and work. And I believe it is still possible.

This is due to the fact that we’re a design centric company so we take what we do very seriously. Do you? Or have you found some recent examples of design execution sloppiness?

I plan to write more on that subject, because I believe that making it “known” is the way for the real users to also start consciously noticing design flaws. They do notice that something is “not quite right” but they can’t yet put their finger on what it is. Let’s change that. Let’s educate the user so they will expect more from us — designers and developers. And let’s build some awesome shit, okay?