Building a Little Bridge
A few reasons why building a “simple” MVP is hard (but fun)
One day I told my friend, Sean Coates, that I wanted to build a teeny-tiny weather app from servers to pixels. I wanted to create a Minimum Viable Product (MVP) with only enough bare-bones functionality to make it work well.
In traditional Sean fashion, he replied:
So you just want to build a little bridge.
After months of building a web app from scratch in my spare time, I’m still smarting from that zinger, and learning from it. You need to have most of the same skills, whether you want to build a little bridge or a big one. And there are the same catastrophic consequences at stake for each.
I recently launched Weather Badge, but building it taught me just how hard it is to build even a little bridge.
Simplicity Makes the Internet Human
My earliest idea for Weather Badge came from my belief that there’s simply too much information out there. Specifically, I found myself stressed out by weather apps with way more information than I needed.
Good design picks out precisely what you need from the vast Internet and presents it to you in a human way. So I thought: What if the complexities of weather could be reduced to a single, beautiful weather badge?
Here’s what a Google weather search looks like, circa 2018:
Instead, what if your morning weather query looked like this:
Just what you need. Nothing more. And in human language. That’s the idea anyway.
Simplicity Requires Being Opinionated
It was pretty darn hard to simplify the Weather Badge interface that much. Dieter Rams’ “Less, but better” manta is hard to put into practice because “better” means different things to different people.
If you’re looking for wind data, numerical stats, or far-future forecasting, then the Weather Badge interface might not work for you. If you want a simple, visual weather app that favors words over numbers, then Weather Badge might be your jam.
All this goes to say: Simplicity requires being opinionated. The only interface that works for everyone in every scenario is a data dump loaded with functionality that ends up being overly complex.
To run through the difficulty of simplicity on a micro level, I designed the weather badges myself, and even representing a straightforward weather state like rain took some doing. Here’s my process for the Rain Badge, showing different prototypes along the way:
And the final product:
Fog was even harder. How do you represent a nebulous weather state in a way that doesn’t look like a cloud? I opted for an abstracted scene that showed a famous foggy spot where I used to live in San Francisco:
And I had a great time designing the Wind Badge, taking cues from a Tibetan prayer flag:
Simplicity is hard. It required many iterations, and bit of inspiration, to figure out what product design “opinion” worked best for me on this project.
Compromise Is Part of the Process
If you’ve played around with Weather Badge and clicked on that little 9-dot icon at the bottom, you’ll notice that it expands to show more weather data:
Isn’t this against my original idea that simpler is better?
Before I launched Weather Badge, I used it everyday. And I found that while I usually only needed the super simple weather info at the top, I sometimes needed a few more bits and pieces. So I added:
- 24-hour forecast
- 5-day forecast with numerical lows, highs, and precipitation type/chance
- Extended weekly forecast
- Severe weather warnings (not shown in the screenshot above)
Without the 24-hour forecast, I didn’t know when to ride my bike to work (I got rained on). Without the 5-day forecast, I couldn’t plan family outings. And without weather warnings, I would have ridden my bike during “slippery winter road conditions” that weren’t surfaced in the original interface.
If you do a little more clicking around, you might also find the 3-dot icon in the top-right that reveals a sidebar:
This came from deeper thinking as I sat with the app and realized that I was missing a few crucial pieces:
- What about non-US users? → I added a Fahrenheit / Celsius toggle
- What about Dark Sky API attribution? → I mention it at the bottom of the sidebar
- What if someone was confused by one of the badges? → I include a description for each badge
Both for legal reasons and to accommodate all users, the app needed more information than could be included in the original simple UI. I compromised by hiding the extended weather forecast and sidebar, which is potentially bad practice. To save users from having to click through hidden menus, it would be better to show everything all the time. I kept the additional info hidden because of why I created Weather Badge in the first place.
Let Your Original “Why” Shape the Product
I created Weather Badge because other weather apps’ information overload stressed me out. Showing the additional data and functionality all the time destroyed the relaxing simplicity of the interface for me.
So I compromised: I included some additional weather info (still less than Google and others), but I hid it away to preserve that feeling of beauty and relaxation I get when I look at a single weather badge that explains the day’s weather in human language.
It’s a compromise that won’t work for everyone, but it stays true to the reason why I built the app, and it continues to shape my opinion behind the product.
Make Your Mark
Whether you hire a team or head out solo into the digital hinterlands, creating even a little bridge/MVP requires a lot of time and willingness to learn, or a lot of money to pay others to use their precious time and decades of experience in your stead.
For Weather Badge, I had to dig deeply into everything from Sketch → UX Design → DNS → NGINX → Git → Heroku → PHP → Laravel → JS → SASS → CSS/HTML and more just to get the first pixels on the screen, let alone iterate on those pixels. But that’s a story for another time.
I hope the weather’s good by you. It’s cold in Brooklyn, but the fire’s warm 🌈