First Get It Working, Then Make it Look Good

I recently completed a winter survival course where we built shelters in just ten minutes with only the contents of our packs. The pack I brought was nearly empty, so I made a tent out of my parka. It was ugly, but it could have saved my life. How does this apply to software? When building a feature, first get it working, then make it look good.

Let’s say you’re building an app that queries a third-party API to get data. “Get it working” could mean getting the API to return the data you need, and then dumping it onto the page as a raw object with JSON.stringify. It works!

Next, “make it look good”: style it like an appropriate twenty-first-century webpage.

I’ve had a lot more success and happiness building in this order than in the reverse. Here’s why.

Why Get It Working First

When you get it working first, you prioritize shipping. You’re getting the data you need to ship. Seeing that data is a powerful step past a blank screen.

When you get it working first, then run out of time, you have at a minimum created something real: data. Most people can look at raw data printed on the page and imagine what it could be.

You can then make it look good when the time is right. Very often that time is not now. In some cases, it may never be that time.

I’ve also found that this technique relieves my stress because I’m not trying to solve two unrelated problems– how something works and how it looks– at the same time. Styling is fun when it’s the last step of a feature. It’s stressful when I’m not even sure that I’m styling the right thing.

Often during the “get it working” phase, I iron out a collection of misunderstandings, obstacles, and edge cases we never considered during design. This lets the real world of APIs and data influence the design, which I think is preferable to folding and bending the experience to fit a picture in a wireframe. I’m not wasting time designing a beautiful radio input that’s ultimately going to be a checkbox.

What About Making it Look Good First?

What about making it look good first? Maybe you’re a programmer who loves HTML and CSS and that’s where you prefer to start. Here’s what happens to me when I take that route.

❌ I build the wrong thing. Perhaps your data comes in a table, and you built a beautiful HTML list. API documentation and API behavior do not always agree, and you don’t know for certain how the data is going to look until you’ve made a query or two.

❌ I run out of time. If you run out of time and must ship, a beautiful table full of Lorem Ipsum isn’t going to inspire your stakeholders or earn investment. I’ve found that people can make a mental leap from raw data to pixel-perfect HTML, but most struggle in the reverse.

Rework and running out of time are not fun, and they don’t solve customer problems.

Who Am I Building For?

Something to consider is the Iceberg Secret. In this post, Joel Spolsky argues that nontechnical stakeholders assume that a polished UI means that the underlying behavior is complete, even if that’s incorrect. And vice versa, that same person sees an incomplete UI and assumes incomplete software.

Restated, some stakeholders will dismiss working features that look bad. With this in mind, maybe we should prioritize design for those people by making it look good first, or earlier in the process?

I think Joel’s assessment applies only to the least-technical people involved with software. As software eats the world, these people are becoming less common. Many people can read at least a little code. Prioritizing your MVP for people who are mystified by raw data structures is short-sighted. You’re gold-plating while your competitors are shipping.

In a Perfect World

At Hashrocket, we had skilled frontend engineers who built simple, beautiful, and responsive Lorem Ipsum placeholder UIs for the dev teams. We, developers, got to think almost entirely about data flow because the UI details were solved. I’ve only been on a few teams that worked this way, but it was sublime. Thanks to Cameron, Rye, Mike, and Daniel.

Get it working, then make it look good. My thanks to Chris Erin, who taught me to think this way a long time ago.

• Agile