3 posts on North Star UI

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 can be immediately understood by anyone who has seen Henrik’s illustration, and fit nicely into a fixed time, variable scope development process, such as Shape Up.

1. 🛹 The Skateboard (aka the Pessimist’s MVP): What is the absolute minimum we can ship, if need be? Utilitarian, bare-bones, and somewhat embarrassing, but shippable (only barely). Anything that can be flintstoned gets flintstoned.
2. 🛴 The Scooter (aka the Realist’s MVP): The minimum product that delivers value. Usable, but no frills.
3. 🚲 The Bicycle (aka the Optimist’s MVP): Stretch goals — UX polish, “sprinkles of delight”, nonessential features with high I/E. Great if we get here, fine if we don’t.
4. 🏍️ The motorcycle: Next-phase improvements we want to reach soon after launch.
5. 🚗 The car: Medium-term vision; more complete and refined.
6. 🏎️ The race car (aka the North Star UI): The ideal experience — unconstrained by time, resources, or compatibility. Not meant to ship, but to guide everything else.

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 may not even be feasible?” I hear you cry.

Stay with me for a moment. Paradoxical as it may sound, I hope that by the end of this I will have convinced you that fleshing it out pays dividends in the long run and actually saves you time.

1. It exposes the hidden driver of all product design decisions

Whether you realize it or not, every shipping goal is derived from the North Star, like peeling layers off an onion. In some contexts the process of breaking down a bigger shipping goal into milestones that can ship independently is even called layering.

The process is so ingrained, so automatic, that many product designers don’t realize they are doing it. They go from race car to car to 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 daydreaming? We must 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 cruise ship — you might want to try a wooden raft for that.

This North Star will likely change a lot down the line, informed by experience and user feedback. That’s okay; having an initial destination does not remove your ability to course correct.

2. It makes impossible product problems tractable

Nearly every domain has a version of divide and conquer: instead of trying to solve a complex problem all at once, break it down into smaller, more manageable components and solve 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:

1. North Star: What is the ideal solution?
2. Ephemeral constraints: What prevents us from getting there right now?
3. Compromises: How close can we reasonably get given these constraints?

Depending on the product problem, this could simplify things a little or a lot. This framework really shines when you’re dealing with really tough product problems, where two or three of these components are hard, so focusing on one at a time really helps cut down complexity.

3. It facilitates 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 version of it.

Since MVPs are products of the North Star, this will manifest as difficulty reaching consensus at every step of the way, because the root disconnect is never addressed head on.

Here is a story that will sound familiar to many readers: Alice has designed an elegant solution that addresses not just the problem at hand, but several prevalent longstanding user pain points at once — an eigensolution. She is aware it would be a little trickier to implement, but she thinks the tremendous improvement in user experience is worth the very modest increase in effort. She has even outlined a staged deployment strategy that allows it to ship incrementally, adding value and getting customer feedback earlier. Excited, she presents her idea to the product team, only to hear Bob dismiss it with “this is scope creep and way too much work, it’s not worth doing”. However, what Bob is actually thinking is “this is a bad idea; any amount of work towards it is a waste”. The design session is now derailed. At best, instead of figuring out whether Alice’s solution is good, the team is now spending all remaining time discussing how much work it would be and whether it could be reduced. This is a dead end because the amount of work was never the actual problem. Or worse, Alice backs off and agrees to Bob’s “simpler” idea that is overfit to the very specific use case being discussed, because she does not want to be seen as unfocused, or not a team player.

Arguing over effort feels safer and less confrontational than arguing over vision — but it’s often a proxy war. Fleshing out the North Star UI as an explicit goal strips away this noise and brings clarity.

This is not productive. First, if the idea is not good, the amount of work is irrelevant and spending time costing it is putting the cart before the horse. And if it is, often implementation proves to be easier than expected once it is properly investigated.

It is important to answer the questions above in order, and reach consensus on what the North Star 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 discuss 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 cannot do a cost-benefit analysis without being aware of both the cost and the benefit.

Additionally, fleshing the North Star out separately ensures that everyone is on the same page about what is being discussed. All too often have I seen design sessions where one person is discussing the skateboard, another the bicycle, and a third what the car, no-one realizing they are talking cross purposes.

4. It can improve the MVP via user testing

Conventional wisdom is that we strip down the North Star to an MVP, ship that, then iterate based on user input. With that process, our actual vision never really gets evaluated. By the time we get to it, it has already changed tremendously. But did you know you can actually get input from real users without writing a single line of code?

Believe it or not, you don’t need to wait until a UI is prototyped to user test it. For some reason, this seems to be almost unheard of outside usability circles, but you can even user test a low-fi paper prototype or even a wireframe. The user tells you where they would click or tap on every step, and you mock the UI’s response by physically manipulating the prototype or showing them a wireframe of the next stage. This allows you to user test your North Star UI from the start, and adjust your MVP accordingly.

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 when it does work, it can have a very high Impact/Effort ratio. It can be especially useful when there are vastly different perspectives within a team about what the North Star UI might be, or when the problem is so novel that every potential solution is low-confidence. 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 all that great.

5. It paves the way for getting there (someday)

Just like the mythical North Star, a North Star UI serves as a guide to steer us in the right direction. Simply articulating what the North Star is can make it more feasible. It’s not magic, just human psychology.

First, once we have a North Star, we can use it to evaluate proposed solutions: How do they relate to a future where said North Star is implemented? Are they a milestone along that path, or do they actively prevent us from ever getting there?

Prioritizing solutions that get us closer to the North Star can be a powerful momentum building tool. Once we’re partway there, it naturally begs the question: can we get closer? How much closer? it is much easier to convince people to move further along a path they are already on than to start a different path. Even if we can’t get all the way there, maybe we can close enough that the remaining distance won’t matter. And often, the closer you get, the more achievable the finish line gets. In fact, sometimes simply reframing the North Star as a sequence of milestones rather than a binary goal can be all that is needed to make it feasible.

6. It makes the design process robust and adaptable

North Star UIs make the product design process more resilient and adaptable. I have often seen “unimplementable” solutions become implementable down the line, due to changes in internal or external factors, or simply because someone had a lightbulb moment.

Without a solid foundation to fall back on, this means our only options are to either go back to the drawing board, or miss out on the opportunity to adapt. With a solid North Star UI in place, when constraints get lifted we only need to re-evaluate our compromises, which is usually much easier than starting from scratch.

Case studies

In my 20 years of product design, I have seen ephemeral constraints melt away so many times I have learned to interpret “unimplementable” as “kinda hard; right now”. Some examples from my own experience below.

Context Chips

This is a case where I was originally operating under the constraint extremely minimal engineering resources and having to aggressively prioritize, a constraint that was later lifted due to a change in engineering momentum. It is described at length in Context Chips in Survey Design: “Okay, but how does it feel?”.

In a nutshell, the relevant bits are:

• The engineer hated the original low-effort, entirely client-side idea so much, he prototyped a much higher-effort solution which involved a backend and API changes in a day. Previously, this would have been entirely out of the question.
• Initial opposition to the later proposed UI was completely reversed once the engineer observed user testing sessions using a prototype.

Here is a little secret that applies to nearly all software engineers: neither feasibility nor effort are fixed for a given task.

Engineers are not automatons that will blindly implement whatever they are told with the same energy and enthusiasm. If you are content getting Engineering to reluctantly agree to implement your vision, you’re typically getting very poor ROI out of it.

Often all that is needed to make the infeasible, feasible is engineering momentum. Investing the extra time and energy to get engineers excited can really pay off. When good engineers are excited, they become miracle workers. The difference is not small, it is orders of magnitude. Things that were impossible or insurmountable become feasible, and things that would normally take weeks or even months are prototyped in days.

One way to get engineers excited is to convince them about the value and utility of what they are building. All too often, product decisions are made in a vacuum, based on gut feelings and assumptions about user needs. Backing them with data, such as usability testing sessions is an excellent way to demonstrate their basis. And having engineers observe user testing sessions firsthand can be much more powerful than secondhand reports.

CSS Conic Gradients

background: conic-gradient(in hsl,
	red, orange, yellow, lime,
	cyan, blue, magenta, red);

Often, what makes a high effort feature feasible (or even trivial) is a change in the environment. An example that comes to mind is CSS conic gradients. Conic gradients are the type of gradient that is created by (conceptually) rotating a ray around a center point.

I originally proposed adding conic gradients to CSS in 2011, and they first shipped in 2018 (in Chrome 69)! Someone observing this timeline without context may just conclude “pffft, standards just take forever to ship”. But there is always a reason, either technical, human, or both. In this case, the reason was technical. Browsers do not implement things like shadows and gradients from scratch, they use graphics libraries such as Skia, Cairo, or Core Graphics, which in turn are also abstractions over the OS-provided graphics APIs.

At the time these libraries did not support any primitive that could be used to render conic gradients (e.g. sweep gradients, mesh gradients, etc.). In the years that followed, one after another these libraries added support for some kind of gradient primitive that could be used to easily render conic gradients, which took the proposal from prohibitively high to low effort. I also created a polyfill which stimulated developer demand, increasing Impact. These two things together took the Impact/Effort ratio from “not worth it” to “let’s do this, stat” and in 2 years the feature was implemented across all major browsers.

Relaxed CSS Nesting Syntax

Sometimes high effort things just take a lot of hard work and there is no way around it. Other times, feasibility is one good idea away.

One of my favorite examples, and something I’m proud to have helped drive is the relaxed CSS Nesting syntax, now shipped in every browser. It is such an amazing case study on the importance of having a North Star UI, I even did an entire talk about it at Web Unleashed, with a lot more technical details that I have included here.

In a nutshell, CSS nesting was a (then new) CSS syntax that let CSS developers better organize their code by reducing repetition through nesting CSS rules inside other CSS rules.

table.browser-support {
	border-collapse: collapse;
}
table.browser-support th,
table.browser-support td {
	border: 1px solid silver;
}
@media (width < 600px) {
	table.browser-support,
	table.browser-support tr,
	table.browser-support th,
	table.browser-support td {
		display: block;
	}
}
table.browser-support th {
	border: 0;
}
table.browser-support td {
	background: yellowgreen;
}
table.browser-support td:empty {
	background: red;
}
table.browser-support td > a {
	color: inherit;
}

table.browser-support {
	border-collapse: collapse;
@media (width < 600px) {
&, tr, th, td {
display: block;
}
}
th, td {
border: 1px solid silver;
}
th {
border: 0;
}
td {
background: yellowgreen;
&:empty {
background: red;
}
> a {
color: inherit;
}
}
}

This is one of the few cases where the North Star UI was well known in advance, since the syntax was already well established in developer tooling (CSS preprocessors). Instead, the big challenge was navigating the practical constraints, since CSS implemented in browsers has different performance characteristics, so a syntax that is easily feasible for a preprocessor may be out of reach for a browser. In this case, the North Star syntax had been ruled out by browser engineers due to prohibitive parsing performance ^[1], so we had to design a different, more explicit syntax that could be parsed more efficiently.

At this point, it is important to note that CSS Nesting is a feature that once available, is used all over a stylesheet, not just a couple times here and there. Both conciseness and readability are paramount, especially when conciseness is the sole purpose of the feature in the first place!

Initial attempts for a syntax that satisfied these requirements introduced a lot of noise, in the form of an awkward, noisy @nest token that needed to be placed in the beginning of most nested rules. Worse yet, these attempts were actively incompatible with the North Star syntax, as well as other parts of CSS (namely, the @scope rule). This meant that even if the North Star UI became feasible later, CSS would need to forever support syntax that would then have no purpose, and would only exist as a wart from the past, just like HTML doctypes.

This proposal sat dormant for a while, since implementors were not exactly in a hurry to ship it. This all changed when State of CSS 2022 showed Nesting as the top missing CSS feature, making Google suddenly very keen to ship it.

A small subset of the CSS Working Group, led by Elika Etemad and yours truly organized a number of breakouts to explore alternatives, an effort that produced not one, not two, but four competing proposals. The one that the group voted to adopt ^[2] was the one I designed with the North Star in mind, by asking the question: If the North Star syntax is out of the question right now, how close can we get and still be compatible with it in case it becomes feasible later on?

Once we got consensus on this intermediate syntax, I started exploring whether we could get any closer to the NSUI, even attempting to propose an algorithm that would reduce the number of cases that required the slower parsing to essentially an edge case. A few other WG members joined me, with my co-TAG member Peter Linss being most vocal. This is a big advantage of NSUI-compatible designs: it is much easier to convince people to move a little further along on the path they are already on, than to move to a completely different path. With a bit of luck, you may even find yourself implementing an “infeasible” NSUI without even realizing it, one step at a time.

We initially faced a lot of resistance from browser engineers, until eventually Anders Ruud and his team experimented with variations of my proposed algorithm and actually closed in on a way to implement the NSUI syntax in Chrome. The rest, as they say, is history.

Conclusion

Hopefully by now you’re convinced about the tremendous value of spending time reaching consensus on an explicit North Star UI that has buy-in from the entire product team. However, it is important that everyone is on the same page and understands the steps and benefits of this framework. Trying to design the North Star with people that see that as a pointless thought experiment does not confer any of these benefits, and just adds friction.

One would think that we’ve more or less figured survey UI out by now. Multiple choice questions, checkbox questions, matrix questions, dropdown questions, freeform textfields, numerical scales, what more could one possibly need?!

And yet, every time Google sponsored me to lead one of the State Of … surveys, and especially the inaugural State of HTML 2023 Survey, I kept hitting the same wall; I kept feeling that the established options for answering UIs were woefully inadequate for balancing the collection good insights with minimal friction for end-users.

The State Of surveys used a completely custom survey infrastructure, so I could often (but not always) convince engineering to implement new question UIs. After joining Font Awesome, I somehow found myself leading yet another survey, despite swearing never to do this again. 🥲 Alas, building a custom survey UI was simply not an option in this case; I had to make do with the existing options out there ^[1], so I felt this kind of pain to my core once again.

So what are these cases where the existing answering UIs are inadequate, and how could better ones help? I’m hoping this case study to be Part 1 of a series around how survey UI innovations can help balance tradeoffs between user experience and data quality, though this is definitely the one I’m most proud of, as it was such a bumpy ride, but it was all worth it in the end.

Continue reading

Continue reading