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
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

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.
(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.
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!

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.
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.
¯\_(ツ)_/¯