Three easy steps to help non-designers make an MVP look great

Some low-hanging fruit for developers and other non-designers like myself to make the first version of their product look great

December 3, 2014
Jonathan Libov

I have no formal design training but I've made some decent looking apps in my day. The MVP version of my latest app, Fifty, is riddled with design flaws and features we didn't have time to ship, but still merited an unsolicited compliment from a top-notch designer, so I must be doing something right.

In that spirit, I thought I'd share a few tips that any non-designers out there—from marketers to product managers to, most importantly, developers—can follow to produce a nice-looking app.

1. For God's sake, pick a font

For your app to have a truly unique identity, you'll need a unique logo and design language. Many companies who don't yet have the time or money to hire a designer to craft their brand just stick the first letter of the product's name inside a circle (see the P.S. note on this post on the Product Hunt blog). So be it. But there's some low-hanging fruit out there: a unique, great-looking font.

The standard font on iOS is Helvetica Neue; on Android it's Roboto. The former is a great font, the latter is, well, whatever. Proxima Nova and Avenir are also very common these days because they're very legible and add a fresh, clean look. But the commonness of these fonts is a problem, because if you choose one of them (or, in the case of Helvetica Neue on iOS and Roboto on Android, you make no choice at all), your app will look like everyone else's. I know that fonts seems like a minor detail, but trust me, you're more deeply affected by font choices than you'll ever know.

So pick a font. If you cannot spare a dime on fonts (more on that below), browse Google Fonts. Sacha Greif's "Google Webfonts that don't suck" is a great resource. Read Sacha's notes on what to look for in a font that will meet your needs and match your app's character. Don't be intimated by trying to match your app's character — you owe it to your product to try out at least 20 fonts that you think might work and then pick the best one.

Here are a few of the fonts that I tried with Fifty (click to see a larger view):

Fifty font trials

I chose Centrale Sans for a few reasons For one, it's very legible but also has a playful character that I liked. One of the reasons we built Fifty is because we wanted an alternative to the dense, hyper-masculine style of other sports score apps.

Second, I had never seen Centrale Sans used elsewhere on the iPhone. In doing my research, I found out that the only prominent app using Centrale Sans (to my knowledge) was Weathertron, and it was commonly described as gorgeous. I felt confident that my fondness for Centrale Sans wasn't just a personal quirk.

I had to drop some serious dough for Centrale Sans. Many great fonts are expensive, but they're often worth it. The great fonts you see in Instapaper cost thousands of dollars. I'm not suggesting you spend that much, but you do owe it to yourself to browse Hoefler & Co's font collection, or Mark Simonson's and try out a few premium fonts to see if you might experience how a great font can transform your humdrum app into a unique one filled with character.

(If only I could follow my own advice and find some nicer fonts for this blog.)

2. Use a baseline grid

Imagine you were climbing a ladder in which the rungs were not at a consistent distance from one another. You wouldn't have trouble climbing the ladder, but it would be odd and uncomfortable. That's what it's like when you don't stick to a baseline grid in your app.

A baseline grid is a set of horizontal guidelines, equidistant from one another in the vertical direction, that you overlay on your design to establish a vertical rhythm. In designing your app, it's tempting to just move items around and change spacing until it looks right. But you owe it to yourself not to stop there. Download a baseline grid like Teehan + Lax and use their template to place items on the grid.

I know what you're thinking: "That seems like a lot of work that should be best left to a designer". To the contrary! If you use a grid, you'll be surprised how much easier it makes your life as a non-designer doing design. Moving things around in space without a great is like writing an essay for a test, whereas using a vertical grid is like a multiple choice question. You merely need to pick a baseline grid size and snap your elements to it!

Here's a sample of the baseline grid I used in Fifty:

The baseline grid used in Fifty

And here's a sample I put together of what happens when you use a vertical grid and when you don't. Note that I only made one change — the line height in the tweet text — that made the text still readable, but suddenly inconsistent with the grid that's already been established above.


Trust me, even if you've done a good job moving things around until they looked pretty well spaced, you'll be really pleased when you take a few minutes to get everything spaced just right.

(If only I could follow my own advice and use a baseline grid for this blog.)

3. Blow it all up once or twice

Maybe you're a programmer and have gone down a long road with your class structure before realizing that you should have used a different structure in the first place. It takes time and experience as a programmer to identify when that's happened and even more to prevent it from happening.

You owe it to yourself to do the same thing with the visual design of your app. Once you've mocked up something that kinda works, you'll be tempted to keep working on it and keep working on it until it starts to look good. Julie Zhou, a Product Design Director at Facebook, addressed this in a post yesterday on "The 5 Most Common Design Mistakes". She called it "Refining too early", which is right on the mark and applies to any creative endeavor.

I can't put it any better than Julie did, so I'll let Julie do the talking:

This is a classic designer’s mistake: you start off exploring a big, ambiguous problem. You have a cool concept in your head. You sketch it out. Looks sweet! Excitement builds! You start working on a high-fidelity mock or prototype. So sick! The design questions start piling up. Should you go with black or white as the background? Maybe the buttons should be round. Oh! This would be a great use case for that new nav idea you’ve been thinking about! Before you know it, 80% of the design time has been on refining one idea instead of exploring multiple ideas.

Maybe your first idea is always the best idea. Maybe you’re that person who touches things and then they turn to gold. I wouldn’t bet on it. You’re better off not falling in love with your first idea and instead doing broader explorations on a number of different systems, models, and approaches when you’re in the exploration stage. At this point, specific interaction and visual details only matter in that they need to be clear enough to support the story you’re trying to tell with your concept so that others can understand it and help you critique it. Any addition time spent refining the concept is like rearranging deck chairs on the Titanic. Too often, I see designers getting so enamored with deep-diving on one idea that they don’t leave themselves any room to explore other very different—and potentially much better—ideas.