What is a North Star UI and how can it help you ship?
You may be familiar with this wonderful illustration and accompanying blog post by Henrik Kniberg:
It’s a very visual way to illustrate the age-old concept that that a good MVP is not the one developed in isolation over months or years, grounded on assumptions about user needs and goals, but one that delivers value to users as early as possible, so that future iterations can take advantage of the lessons learned from real users.
The MVP as a range
While not quite what Henrik intended, I love this metaphor so much, I have been using it to describe shipping goals when writing product specs. I find they are understandable to anyone who has seen Henrik’s illustration, and fit nicely into a fixed time, variable scope development process, such as the Shape Up methodology that we use at Font Awesome.
- 🛹 The Skateboard (aka the Pessimist’s MVP): What is the absolute minimum we can ship, if need be? This is the most bare-bones set of features, without which we cannot ship at all. It skews more utilitarian: it has the basic functionality we need, but its UX is very rough, even embarrassing. Anything that can be flintstoned is flintstoned. This is meant to be less-than a traditional MVP.
- 🛴 The Scooter (aka the Realist’s MVP): It is the minimum set of features we want to ship that will still provide value and fulfill enough user needs across enough user segments to be worth it. Its UX is more well thought out than the skateboard but anything nontrivial to implement is punted unless essential. This is closer to a traditional MVP.
- 🚲 The Bicycle (aka the Optimist’s MVP): The wishlist or stretch goals. If everything goes really well, what else can we ship? This may include UX improvements, “sprinkles of delight”, and features that are nonessential but have high I/E ratios. This is where we aspire to be, but we are not going to be heartbroken if we don’t get there.
- 🏍️ The motorcycle: These are improvements that are beyond even the optimistic MVP, but we want to get to sometime in the near future.
- 🚗 The car: Improvements that we can ship in the medium to longer term future.
- 🏎️ The race car (aka the North Star UI): This is the ideal product we would ship if we were not bound by ephemeral constraints like time, resources, performance considerations, or backwards compatibility.
The meat is the first three stages, since they directly affect what is being worked on. The more we go down the list, the less fleshed out specs are, since we know they will change once we have input to customers.
The most controversial of these is the last one: the race car, i.e. the North Star UI. It is the very antithesis of the MVP. The MVP describes what we can ship ASAP, whereas the North Star describes the most idealized goal, one we may never be able to ship.
It is easy to dismiss that as a waste of time, a purely academic exercise. “We’re all about shipping. Why would we spend time on something that’s not even feasible?” I hear you say. However, in the rest of this essay I will argue that it is one of the most important milestones, and fleshing it out pays dividends in the long run.
More deliberate product design
Whether you realize it or not, the North Star is the only actual input into this process. Every other stage, the skateboard, the scooter, the bike, the motorcycle, the car, are all outputs. They are all derived from the North Star, like peeling layers off an onion. In fact in some contexts the process of breaking down a bigger shipping goal into milestones that can ship independently is literally called layering.
The process is so ingrained, so automatic, that most product designers don’t realize that they are doing it. They go from race car to car, or even motorcycle so quickly they barely realize there was anything else there to begin with. Thinking about the North Star feels like a guilty pleasure — who has time for this daydreaming? We gotta ship, yesterday!
But the race car is fundamental. Without it, there is no skateboard — you can’t reduce the unknown. Without a solid North Star, your MVP is a confused jumble of design decisions and compromises, so tangled it becomes impossible to tell them apart.
To stick with the transportation metaphor, a skateboard might be a good MVP if your ultimate vision is a race car, but it would be a terrible minimum viable ferry boat — you might want to try a wooden raft for that.
This North Star may (and likely, will) change down the line, informed by customer feedback. That’s okay and par for the course. We don’t need to wander aimlessly with no destination, to be able to course correct.
Perhaps counterintuitively, spending time fleshing out a North Star UI can actually help you ship. Allow me to explain.
Simplify problem solving
A common problem-solving strategy in every domain, is to break down a complex problem into smaller, more manageable components and solving them separately. Product design is no different. The concept of a North Star UI breaks down tough product design problems into three more manageable components:
- North Star UI (NSUI): What is the ideal solution?
- Ephemeral constraints: What prevents us from getting there?
- Compromises: How close can we reasonably get given these constraints?
In many simpler problems, their difficulty is concentrated in only one of these components, in which case this framework does not help much. Where it really shines is the really tough product problems, where the first and third question are both hard. Far easier to answer them separately than trying to answer both at once.
Facilitate team alignment
When the North Star UI is not clearly articulated, it doesn’t mean it doesn’t exist. It just means that everyone is following a different North Star.
Since MVPs are products of the North Star, this will manifest as difficulty reaching consensus at every step of the way.
Debating at a different level of abstraction than what produced the original disconnect is generally a recipe for nonterminating divergence. It pays off to zoom out and resolve the root cause separately, rather than waste time and energy debating its byproducts one after another, like fighting off a Lernaean Hydra one head at a time.
Having the space to flesh out the North Star UI separately not only eliminates future disagreements before they happen, it also strips away a lot of noise.
Often, what is fundamentally a North Star disagreement will masquerade as a disagreement about practical constraints. It feels easier to cite practical constraints than to debate the merits of an idea directly. Fleshing out the North Star UI separately eliminates this deflection at the root. Here is a story that may sound familiar: Alice has designed an eigensolution, — an elegant solution that addresses several user pain points at once. She is aware it would be a little tricky to implement, but she thinks the tremendous improvement in user experience is worth it and she can layer it in such a way that it can ship incrementally. When she presents her idea to the product team, Bob dismisses it as “this is way too much work, it’s not worth doing”. However, what he is actually thinking is “this is a bad idea and any amount of work towards it is a waste”. Instead of spending time figuring out whether Alice’s concept is a good idea, they spend their time discussing how much work it is and whether it could be reduced. As a result, they fail to reach consensus because the amount of work was not the core issue.
It is important to answer the questions above in order, and reach consensus on what the North Star UI is before moving on to the compromises. This way, we are aware of what is an actual design decision and what is a compromise driven by practical constraints. Articulating these separately, allows us to debate them separately. It is very hard to evaluate tradeoffs collaboratively if you are not on the same page about what we are trading off and how much it’s worth. You need to know both the cost and the benefit to do a cost-benefit analysis.
North Star UIs can improve MVPs via user testing
Conventional wisdom is that we strip down the North Star to an MVP, ship that, and then iterate based on input from real users. But did you know you can actually get input from real users without writing a single line of code?
While common knowledge among usability folks, this seems unheard of in product management circles. You don’t need to wait until an implemented MVP to do user testing. You can do user testing as early as a low-fi paper prototype, with the user telling you where they would click or tap and the facilitator mocking the response. This allows you to user test your North Star UI directly and adjust your MVP accordingly without having to wait for a whole deployment cycle.
Obviously, this works better for some types of products than others (it is notably hard to mock rich interactions or UIs with too many possible responses), but it is a powerful tool to have in your arsenal. It can be particularly useful useful when there are vastly different perspectives within a team about what the North Star UI is, or when the problem is so novel that every potential solution is on shaky ground. Even the best product intuition can be wrong, and there is no point in evaluating compromises if it turns out that even the “perfect” solution is not actually a good one.