# Incomparable — Full Content

Incomparable is a tiny product design studio based in Finland, partnering with teams across 5 continents and 17 countries. Founded by Paul van Oijen. Services: product design partnerships (embedded UX/UI, design systems, data visualization, optional full-stack development) and in-person workshops. Workshop alumni include designers and product leaders from companies such as Shopify, Unity, GetYourGuide, Coinbase, Hoxhunt, Insense, Workbounce, Focal, and Magic Eden. Over 1000 workshop participants delivered across 5 continents.

This file contains the full text of every published post, book chapter, and workshop description. It is intended for LLM consumption.

---

# About the Studio

URL: https://incomparable.design/about

Incomparable is a tiny product studio helping you build big software. We're tucked away in the heart of the Finnish forest — the land of a thousand lakes, the real land of enchantment.

But, much like the Finnish diaspora, we're everywhere. We've run workshops and helped teams build the next big thing across 5 continents, 17 countries, and counting. From the humid Laotian rainforest to the neon-lit streets of Tokyo, and from the foggy hills of San Francisco to the breezy shores of Cape Town — we go where we're needed, when we're needed.

We believe in keeping things simple — like life in Finland. Straight to the point, no excess. That's how we build software too. Good software makes the complex accessible and the day-to-day effortless.

Founder: Paul van Oijen. Over a decade of product design experience, having collaborated with Unity, GetYourGuide, Shopify, Coinbase, and many others. Facilitator of design workshops delivered to 1000+ participants across 5 continents.

Contact: hello@incomparable.design. Intro call: https://cal.com/paul-van-oijen/30min.

---

# Workshops

## Design Principles

URL: https://incomparable.design/workshops/design-principles

A live, full-day (8-hour) in-person workshop that helps teams define and apply design principles. Participants leave with a draft set of principles, a principle-writing rubric, and a rollout plan. Ideal for teams debating what 'good design' means, teams building or evolving a design system, and leaders who want design critiques to reference shared language instead of opinion. Delivered on-site by Paul van Oijen; tailored to each team during an intro call.

---

## Designing for Empathy

URL: https://incomparable.design/workshops/designing-for-empathy

A live, full-day (8-hour) in-person workshop teaching teams how to cultivate genuine empathy for users and translate that understanding into design decisions. Participants build empathy maps, run interview exercises, and leave with methods they can apply immediately. Ideal for product teams shipping features without qualitative user grounding, teams transitioning from persona-driven to empathy-driven research, and leaders who want user research integrated into everyday design work.

---

## Philosophical Foundations

URL: https://incomparable.design/workshops/philosophical-design

A live, full-day (8-hour) in-person workshop applying philosophical frameworks (from Plato's ideal forms to Heidegger's concept of being) to modern product decisions. Participants leave with a decision-making framework grounded in 2500 years of philosophical thought, applied to their own product. Ideal for teams making high-stakes product bets, design leadership setting long-term direction, and mature teams ready to move beyond tactical discussions.

---

# Blog

## The Language Games of Design
Category: Design Philosophy
Published: Apr 29, 2026
URL: https://incomparable.design/blog/the-language-games-of-design

Every design system I've worked on eventually has the same fight.

Someone insists the button component should be called `<Button>`. Someone else argues it needs to be `<PrimaryButton>` because the plain name is ambiguous. A third person thinks both are wrong because the component isn't really a button anymore once it has an icon slot, a loading state, and a link prop. The thread runs three days. Nothing ships.

Here's what everyone in that thread is missing. They aren't actually fighting about the name. They're fighting because nobody has stabilized the language game yet.

## Meaning as use

![A black-and-white portrait of Ludwig Wittgenstein.](/blog/the-language-games-of-design/wittgenstein-portrait.png)
##### Ludwig Wittgenstein (1889–1951). Published one confident book, spent the rest of his life quietly unwriting it.

In 1921 Ludwig Wittgenstein published the *Tractatus Logico-Philosophicus*, one of the strangest and most confident books in 20th-century philosophy. His argument, roughly: every meaningful sentence pictures a fact in the world. Words are labels. Language is logic in disguise. Case closed, philosophy solved.

Then he spent the next thirty years deciding he was wrong.

His later work, published after his death as *Philosophical Investigations*, took the opposite position. Words don't get their meaning from what they refer to. They get their meaning from how they're used inside specific practices. He called these practices "language games," and his best example of one is the word "game" itself. There's no single essential property that unites board games, sports, solitaire, word games, and video games. What unites them is a web of overlapping similarities, what he called family resemblance.

Meaning comes from use. That's the whole move. And it turns out to be the single most useful piece of philosophy a working designer can steal.

## Your design system is a language game

A component named `<Button>` in your codebase means what your team's use of it makes it mean. It doesn't mean whatever Wikipedia says a button is. It doesn't mean whatever Material Design or Apple's HIG says. It means the set of things your team has actually shipped with that component across six months of pull requests.

I worked with a company once where the `<Card>` component had ballooned to forty props. Every use that resembled a card had been welded onto it. A dashboard tile, a blog preview, a settings group, a modal body, a checkout summary. By the time I saw the codebase, nobody was using `<Card>` to render cards. They were using it to render elaborate page sections that happened to have rounded corners.

The team spent a lot of energy trying to rename the component to match what it had become. Rename it to `<Panel>`. Rename it to `<Surface>`. Rename it to `<Block>`. None of the names felt right, because the component's use had become incoherent. It wasn't doing one thing. It was being pulled toward five different language games simultaneously.

The rename didn't fix anything. What fixed it was splitting the component back into distinct uses, stabilizing each one, and then letting the names settle. The language game got re-established. Only then did the right names become obvious.

The people who argue loudest about naming are usually the ones who haven't yet watched the component get used in production. They're reasoning from the dictionary. Ship a few pull requests with the thing in the wild and the name tends to become obvious, because the language game has done its stabilizing work.

## Family resemblance explains why your tokens keep slipping

There's no essential property that unites all games. There's no essential property that unites all "primary colors" either.

Primary is a family. It's brand accents, CTAs, active states, selection indicators, focused inputs, interactive links. These uses resemble each other without sharing one underlying thing. Each makes its own demands. A CTA might need slightly more saturation to pop. A selection state usually needs a calmer version. A focused input needs enough contrast to read as a ring.

Teams that try to pin tokens to single essential definitions end up fighting their own systems. They decide that `--primary-500` is THE brand color, full stop. Then the CTA needs a different hue than the brand header. The selection state needs a muted variant. Suddenly `--primary-500` is wrong in three places. The fight begins.

The Wittgensteinian move is to stop trying to find essences. Tokens aren't definitions; they're family-resemblance nodes. Name them after what they're for, not what they are. A token called `--accent-interactive` will age better than one called `--brand-primary`, because the first describes a family of uses and the second tries to be an essence.

![A grid of color swatches showing a central "primary" color surrounded by drifting variants — primary-hover, primary-active, primary-pressed, primary-selected, primary-focus, primary-link. Each is close to the center but noticeably different.](/blog/the-language-games-of-design/primary-token-drift.png)
##### No essential "primary." A family of related uses, each making its own demands. Naming the family rather than any single member is what lets the system stay coherent.

Style Dictionary does this quietly. Radix does it explicitly. Most of the hand-rolled tokens files I've seen in the wild don't, and they're the ones where nobody can agree on what primary means.

## The private language argument

This is the strangest and most powerful part of Wittgenstein's later work.

He argues that a genuinely private language is impossible. Not impractical. Incoherent. If only one person has access to the rules of a language, there's no way to distinguish following a rule from misremembering what the rule was. You can't correct yourself against a private standard, because the standard is whatever you happen to remember at the moment you check. Rules require a public, someone who can point at your use and say, "that's not how we use this word."

Which is why a design system that lives in one designer's head isn't a design system. It's a set of private associations. The designer feels consistent, because they remember what they chose. Nobody else can correct their memory. When they're sick, the system stops working. When they leave the company, the system evaporates.

Design systems become real on the day the second person uses the system and says, "I used this wrong — what should I have done?" That sentence is the whole point. It's the public rule, being corrected by another user. Language games require players, plural.

The highest-leverage thing a solo design system owner can do, practically, is get someone else using the system under review. Not to audit the work. To create the conditions for public correction. Without that, you don't have a system. You have your own memory, dressed up.

## Language grows the world

Wittgenstein wrote in the *Tractatus* that the limits of his language meant the limits of his world. He softened that line later, but the intuition stayed. We can only think clearly about what we can name clearly.

Teams that lack vocabulary for subtle product qualities argue in circles. "I want it to feel more premium." "I want it to feel more approachable." These aren't arguments. They're two different languages bumping into each other, and neither side has the words to describe what they actually mean.

Writing design principles is, among other things, language work. You're giving the team public terms to think with. "Density serves utility; generosity serves welcome" is a principle that expands what the team can say. It lets someone argue, "this is a density moment, not a welcome moment." Before the principle, they just had taste versus taste. After, they have a claim that can be agreed with, or disagreed with, on shared ground.

The harder a product decision is, the more likely it's a decision that lacks language. The craft isn't picking the right answer. The craft is growing the language until the right answer becomes speakable.

## Back to the button argument

Which brings us back to the thread that wouldn't end.

The team isn't fighting about naming. They're fighting because different members have seen the component used differently, and each is proposing a possible meaning drawn from the use they've seen. The fight is productive if it ends with a shared rule that others can follow. It's destructive if it loops forever without one.

The way out is to stop trying to find the correct name. Ask instead: what use are we actually making of this component, across current pull requests? What rule would let someone new on the team use it correctly without asking us? That's the language game the name has to serve. Fix the use, name follows.

## What your system actually is

The uncomfortable payoff from spending this much time with Wittgenstein: language games are what make design systems exist at all.

Not tokens. Not Storybook. Not Figma libraries. Those are artifacts of the language game, not the game itself. What keeps a system coherent across fifty designers is a shared practice of use, publicly correctable, continuously re-stabilized against real decisions.

When the practice breaks, the artifacts stop helping. No naming convention, no linting rule, no governance model saves you. You have to return to the use.

The system you think you're maintaining is downstream of a language game you may not have noticed was happening.

---

This is one of the arguments at the heart of the [Philosophical Foundations workshop](/workshops/philosophical-design). We practice it against your actual product, with your team, over the course of a day.

---

## A Design Principle Should End an Argument
Category: Design Leadership
Published: Apr 19, 2026
URL: https://incomparable.design/blog/how-to-write-design-principles

Most design principles are bad.

Not wrong. Not actively harmful. Just bad. Too vague to decide anything. Too aspirational to argue with. Too safe to be wrong.

You've read them. "Be bold." "Design for humans." "Start with why." Put those three next to each other and tell me which one I'm supposed to use when my product manager and my engineering lead disagree about where the primary button should go.

That's the test. A good principle should end the argument. If you can't use it to make a decision when two smart, reasonable people disagree, you don't have a principle. You have a poster.

## Principles are written backwards

Early in my career I wrote a beautiful set of design principles for a product I worked on. Six months later, when the team was arguing about a redesign, nobody cited them. Not once. They weren't being defied. They were just useless.

Here's how most teams end up there.

Someone schedules a workshop. The team brainstorms words. They pick five or six that feel true. They massage the words into sentences. They put the sentences on a Figma board. Someone offers to put them on the office wall.

The whole process starts with the wrong end of the question. It starts with "what words do we like?" It should start with "what argument keeps happening?"

Design principles are retrospective, not aspirational. They're the written form of patterns you've already decided on — patterns that should have been obvious, but somehow had to be relearned every time. The purpose of writing them down is to stop relearning.

## The keyword rule

If I can swap your principle into any other product's design doc and nothing changes, your principle is too general to be useful.

"Be delightful" works for Slack, a burial plot marketplace, or a nuclear plant control room. That's not a strength. That's a tell.

Specific principles name something specific. Shopify has a principle along the lines of "Strong opinions, loosely held." That isn't decorative. It's a real guideline for how to run a critique and when to update your position. You can use it to close a debate: "We decided that last quarter and the arguments haven't changed, so we're moving forward." Or to reopen one: "New data came in. Old opinion should update."

Compare that to "Be bold." Bold how? Bold in color? Bold in scope? Bold enough to ship a controversial feature, or bold enough to kill one? "Be bold" is a vibe. It doesn't end arguments. It just makes people feel like they're winning them.

## A better process

Here's the process I use with teams in the workshop.

**Start from real decisions, not words.** Take ten design decisions your team made in the last six months. Ship decisions, kill decisions, edge cases you had to argue about. Write each on its own card.

**Find the pattern.** Most teams will see two or three recurring themes across the cards. The recurring ones are candidates for principles. The one-offs aren't principles; they're just decisions.

**Write the rule, not the vibe.** For each pattern, try to write a sentence that would have ended the earlier debate. "When density and legibility conflict, legibility wins." "We don't ship a new flow without a way for a user to escape it." "An edge case above 0.5% of users gets treated as a case, not an outlier." These don't sound inspirational. That's correct. They're meant to be used, not quoted.

**Test against live arguments.** Take a debate that's open in your team right now — a real one, with both sides still believing they're right — and apply the candidate principle. Does it resolve the debate? If yes, keep it. If no, you either need to sharpen the principle or admit it isn't really what you believe.

**Prune hard.** Most teams end up with more principles than they need. Five is a lot. Three is better. A principle you can't remember when you're arguing at 5pm on a Thursday is a principle that doesn't exist.

## What principles are not

A short list, because these get confused constantly.

Principles are not values. Values are what you care about. Principles are how you decide.

Principles are not brand voice. Brand voice tells you how to write marketing copy. Principles tell you what to ship.

Principles are not a manifesto. A manifesto is written to announce. A principle is written to adjudicate.

Principles are not aspirational. Aspirational principles describe the team you wish you were. Real principles describe the team you are on your sharpest days, so you can be that team more often.

## The test, again

It's genuinely hard to do this on your own. It's easy to spot vague principles when they're somebody else's. It's very hard to spot them in your own draft, because they feel meaningful to the person who wrote them.

The test is brutal but clean: would this principle end an argument you're actually having, or would both sides claim it supports their position? If both sides would claim it, you don't have a principle. You have the absence of one, dressed up in nice words.

Good principles don't make your team sound better. They make your team decide faster. That's the whole point.

---

If the critiques on your team keep looping, or you're building a design system and need a conceptual foundation before you pour a year of engineering into it, that's the specific problem the [Design Principles workshop](/workshops/design-principles) is built to solve.

---

## Dear (Future) Designer: Accessibility Is Not A Feature
Category: Design Insights
Published: Jan 14, 2026
URL: https://incomparable.design/blog/accessibility-not-a-feature

Dear (Future) Designer,

At some point in your career, you will hear this sentence:

> We will add accessibility later.

It usually sounds reasonable. The deadline is close. The scope is full. The design already works for most users. Accessibility becomes a task parked somewhere between polish and cleanup.

This is where things quietly go wrong.

Accessibility is not something you add on top of a finished design. It is not a toggle. It is not a checklist you complete at the end. Accessibility is a quality of the design itself.

Imagine designing a building with stairs everywhere, then adding a ramp as an afterthought. Technically, you made it accessible. Practically, you told some people they were not part of the original plan.

Digital products work the same way.

Color contrast, text size, focus order, keyboard navigation, readable labels, and clear hierarchy are not edge cases. They define whether someone can use what you designed at all. A button that looks beautiful but cannot be reached by a keyboard is not a slightly flawed button. It is a broken one.

![Donut chart showing a single highlighted segment and the label "32 million adults in the United States have visual impairments"](/blog/accessibility-not-a-feature/accessibility_stats.png)

A common misconception is that accessibility is about designing for a small minority. In actuality, it is about designing for the real world.

Taking the figure above, 32 million adults in the United States having visual impairments, that's just shy of 12% of the entire adult population of the country. That's very much a not insignificant amount.

People use products in bright sunlight. With one hand. With aging eyes. With temporary injuries. With slow connections. With screen readers. With cognitive load. Accessibility covers permanent, temporary, and situational limitations. At some point, it covers all of us.

When accessibility is considered early, it rarely compromises aesthetics. Clear hierarchy improves scanability. Sufficient contrast improves legibility. Predictable interactions reduce cognitive effort. These things make designs better for everyone, not worse.

The real cost appears when accessibility is ignored. Retrofits are expensive. Engineering work increases. Design intent gets compromised. What could have been a simple decision becomes a negotiation.


As a designer, you are often the first person to decide who a product is for. Every choice you make either widens or narrows that circle. Accessibility is how you keep it open.

So future designer, do not ask whether something is accessible enough. Ask whether accessibility was part of the decision in the first place. Design as if everyone belongs there, because they do.

## Further Reading

- [The Designer's Guide to Web Accessibility](https://www.smashingmagazine.com/2015/11/web-accessibility-primer/) on Smashing Magazine
- [Designing for Web Accessibility](https://www.w3.org/WAI/tips/designing/) on W3C Web Accessibility Initiative

## More in this series

- [Dear (Future) Designer: Don't Learn How To Code](/blog/dear-designer-dont-code)
- [Dear (Future) Designer: Understand Why Touch Matters](/blog/fitts-law)

---

## Where Are The Humans?
Category: Design Insights
Published: Jan 13, 2026
URL: https://incomparable.design/blog/where-are-the-humans

Design is fundamentally about two things. Just two things. 

Humans, and their experiences.

Everything we do as designers, regardless of what form of the craft we practice, digital or physical, can be reduced to just these two things. It might be a tad reductionist, but I'd find it hard to argue there's a more foundational baseline for the practice that is design, than this.

And yet, with just a literal couple of things to keep track of, we seem to be losing sight of one of them. 

**Where are the humans?**

Where, in this landscape that seems to fervently hurl itself into a future driven by artificial intelligences, are the humans? The focus has seemingly shifted away from the person at the receiving end of the experience. And we're heading towards an environment wherein we craft and tailor experiences without considering who's actually engaging with them. If anyone is, at all.

Modern design has an empathy crisis. 

## Abstractions, and Reductions

Before we hastily attribute our collective loss of focus to the artificial intelligence boom, let's pause and reflect. While the AI surge is undoubtedly buzzy and convenient to blame, it's not the exclusive culprit for our diminishing empathy.

Beneath the surface, there's a pervasive practice that predates the rise of technologies like ChatGPT. A practice that silently undermines our connection with users. Enter the world of reductive research practices in user understanding and product development.

Very early on in my now well over a decade long career, the idea of a persona was dogmatically instilled into my young designer brain. It's impossible, after all, to design for all users. Or so I was told, repeatedly, and so I believed.

So what we do instead, is we take a handful of users, and attempt to identify a common set of traits among some of them. Then we take those common traits, draw a box around some subset of them, and another box around the remainder. And ba-da-bing ba-da-boom. We've got ourselves a set of personas.

This is then the point where we pretend to have majored in Statistics, and declare that it is statistically likely for the majority of users to fall within either of these buckets. And the ones that don't are outliers. We don't care about outliers. 

But none of this tells us anything about the human that this is supposed to be describing. We're already severals levels deep into abstracting the person who's supposed to be benefiting from our work at this point. Not humans or people, but "users". And not just any users. No. Predefined, shoved-into-a box-that-meets-our-business-goals personas.

Let's take my dad for example. My dad is male. A white male. Retirement-aged. Likes to work on computers in his spare time. Supposedly enjoys spending time with his children. Donates to charity where he can. 

Easy fit for a persona one might think. We can probably dig a little deeper to define it further, but we've got a good start. A decent amount of information to draw haphazard conclusions from, and present them to our executive stakeholders, showing them we know exactly who our users are, and what they want.

Or is it?

Because that persona just as well describes Bill Gates as it does my dad. And yet I've worked in many a product development environment where that doesn't matter. It's enough to base our decisions off of and move forward. Despite the fact that my dad and Bill Gates could not be more different in practice.

![Somewhere along the way, people went from being people to being generalized Post-It sized footnotes.](/blog/where-are-the-humans/humans_personas.png)
##### Somewhere along the way, people went from being people to being generalized Post-It sized footnotes. 

Because we can't stem the flow of features. We can't afford to spend time asking ourselves who we're actually designing for. That's not our job anymore.

Because there's no empathy. We don't care for the human side of the experience. There's only abstractions and reductions. Traits and attributes carefully distilled to fit an existing mold.

It's important to note that personas aren't inherently harmful. But the moment we allow them to stand in for real people, we give ourselves permission to stop listening.

Artificial intelligence notwithstanding, we've been trained to do this. To not care. To design for the masses. For uniformity. Which is exactly why I believe this path we're going down is so perilous. 

## The Ghost in the Machine 

Anyone who has spent any amount of time on social networks, online forums, or other forms of online social engagements, has likely noticed a disturbing trend. An increasingly large number of replies, or even topics, wasn't authored by a human at all.

LinkedIn might currently be the most egregious example of this. A post that gains any amount of traction at all, is soon swarmed by bots pretending to be a real user. They'll jump into the replies and neatly summarize the key points of the post, before complimenting with a series of loosely cohesive adjectives.

And then another bot might reply to the first bot, who in turn replies to said reply. And so forth.

While these forms of "fake" communication and engagement are often still called out, the inflection point where bot-generated content and real user content are indistinguishable, draws ever closer. Which again, begs the question:

**Where are the humans?**

The tools that provide the foundation for these types of interactions don't care for the end-consumer. Not end-user, mind you, because that would be the person allowing the bot to write content on their behalf. No, the end-consumer is the person on the receiving end of the probabilistic calculation of nouns and adjectives.

## No Exit

It isn't just social media platforms that suffer from the disappearance of humans either. Whereas the blame for this can to some degree be laid at the feet of users on these platforms, it's a far too common occurence nowadays to see companies, from startups to megacorporations, eschewing this human connection, in favor of a more mechanical replacement.

Recently, I had the pleasure of needing to track down a package that was supposed to be delivered to me. Something I'm sure a larger number of our dear readers are all too familiar with. Now, call me old-fashioned, but I still believe that sometimes, a single phone call is all you need.

Not so much in this case.

You see, the not-to-be-mentioned carrier that was delivering my packages with their yellow-and-red livery, had opted to replace what seemed to be their entire customer service with a voice-activated directory. Not the ones I encountered many times in the past, where you enter a specific series of numbers to narrow down your query. 

This was entirely dictated by myself speaking to a computer-generated script. And it did not work. At all.

"Could you repeat that?", "I'm sorry, I didn't catch that", and the phrase repeated ad infinitum that now haunts me, "Please tell us how we can help", formed 90% of the conversation. Not counting the immense frustration on my end that built up over the course of the call. If one can even can even really call it that.

At no point, was I offered a way out. An opportunity to speak to a real, live human being. Someone who understood what I was trying to communicate without the confines of their narrowly-defined script. A person to whom "detail" was an actual word in their accepted vocabulary.

I ended up driving to the nearest office location of the carrier, some one-and-a-half hours one way, in order to find out what had happened to my delivery. Because it was easier for the organization to place the onus of getting a delivery on me, rather than for them to actually offer a complete, end-to-end service.

![At no point was I offered an opportunity to speak to a real, live human being.](/blog/where-are-the-humans/humans_customer-service.png)

## A Way Out, and Forward

All is not lost. But reclaiming what we've given up will require intention, not tools.

If modern design finds itself in an empathy crisis, it's not because we lack frameworks or methodologies. It's because we've grown comfortable designing at a distance, buffered by abstractions, mediated by dashboards, and insulated from the people who actually live with the consequences of our decisions.

The way forward starts with proximity.

Not focus groups. Not surveys. Not personas refined within an inch of their lives. But actual conversations with actual people. Unscripted, uncomfortable, occasionally inconvenient conversations that resist neat categorization. Conversations that don't immediately map to a feature request or a KPI, but instead reveal motivation, frustration, context, and contradiction. In other words, humanity.

This kind of qualitative research isn't efficient. It doesn't scale cleanly. And that is precisely its value. Empathy has never been scalable. It has only ever been transferable through attention and care. When we trade that away for velocity, we shouldn't be surprised when the results feel hollow.

Designers don't have to do this alone. Some of the richest sources of human understanding already exist inside our organizations, quietly ignored. Sales teams, account managers, support staff, people whose entire role revolves around building and maintaining real relationships with customers. These teams carry stories, not segments. Detail, not averages. They understand why a customer hesitates, what they're afraid of, and what finally convinces them to trust.

And yet, we rarely listen.

Instead, we privilege artifacts over experiences, metrics over moments, and abstractions over people. We optimize funnels while eroding trust. We automate empathy and then wonder why our products feel cold, brittle, and interchangeable.

Bringing the human back into design does not mean rejecting technology. It means refusing to let technology dictate the terms of engagement. It means designing systems that leave room for exception, for failure, for conversation, for exit. It means remembering that on the other side of every interface, every flow, every "user," is a person who did not consent to be reduced.

The future of design is not artificial intelligence. It is not automation. It is not scale.

**It is choice.**

The choice to care.  
The choice to listen.  
The choice to design with humans, not merely for them.

Because if we can no longer answer the question "Where are the humans?" then the problem isn't our tools.

**It's us.**

---

## Dear (Future) Designer: Understand Why Touch Matters
Category: Design Insights
Published: Jan 12, 2026
URL: https://incomparable.design/blog/fitts-law

Ever heard of Fitts's Law? No, it's not the latest social media trend or a design buzzword. It's a simple, fundamental principle that packs a punch in the world of design.

Picture this: You're navigating through a bustling city, aiming to reach a specific destination. Would you opt for a narrow, cluttered alley or a wide, clear path to your spot? It's a no-brainer, right?

> The law predicts that the time required to rapidly move to a target area is a function of the ratio between the distance to the target and the width of the target.
>
> — Wikipedia, Fitts's Law

Fitts's Law is that wide, clear path in the digital world. It's a straightforward concept stating that the time required to reach a target area is determined by the size of the target and its distance from the starting point. In design, it translates to this: the bigger and closer a clickable area is, the easier and quicker it is for users to interact with it.

Let's bring this theory into a practical, user interface context. Think of your mobile app's navigation bar. Larger icons or buttons placed closer to the user's thumb zone are easier to tap, reducing the effort required for users to select an option.

![A black screen displaying a music app](/blog/fitts-law/fitts-law_spotify.png)
##### Screenshot captured in Spotify.

For instance, think of Spotify. Or any other music player app. In practically all of them, the "Pause" button is generously sized and strategically placed within thumb-reach at the bottom-center of the screen.

It follows Fitts's Law by providing a larger and more accessible target, leading to quicker and more accurate user interactions. Likewise, Fitts's Law ensures higher accessibility, especially on touch-oriented devices.


![Various icons with colored touch areas highlighted](/blog/fitts-law/fitts-law_material.png)
##### Image by Google for Material Design Guidelines.

Especially in elements like iconography, having a tappable area that is larger than the icon itself is key to making these components accessible to users. By embracing Fitts's Law, designers can create interfaces that not only look sleek but also work well. Remember, aesthetics matter, but so does designing for effortless interaction, making the user experience a smooth path from point A to B.


Understanding and applying Fitts's Law is a useful principle in a designer's arsenal. It's not about simply making things bigger; it's about strategically enhancing usability and interaction design. So, future designer, let's champion user-friendly designs that make every interaction feel like a breeze.

## Further Reading

- [Fitts's Law and Its Applications in UX](https://www.interaction-design.org/literature/article/fitts-s-law-the-importance-of-size-and-distance-in-ui-design) on Interaction Design Foundation.
- [Fitts' Law In The Touch Era](https://www.smashingmagazine.com/2022/02/fitts-law-touch-era/) on Smashing Magazine.
- [Fitts's Law: The Importance of Size and Distance in UI Design](https://www.nngroup.com/articles/fitts-law/) on Nielsen Norman Group.

## More in this series

- [Dear (Future) Designer: Don't Learn How To Code](/blog/dear-designer-dont-code)
- [Dear (Future) Designer: Accessibility Is Not A Feature](/blog/accessibility-not-a-feature)

---

## Case Study — Shopify
Category: Case Study
Published: Jul 21, 2025
URL: https://incomparable.design/blog/store-differentiation

import { 
  StoreDetailsCard,
  ShopifyPlusNav,
  CustomizeStoreModal,
  FlagEmojiScatter,
  StoreListAbbreviated,
  AbbreviationRules,
  StoreSettingsMockup,
  StoreDifferentiationMetricsCard
} from "@/app/components/CaseStudy";

## Setting the Scene

Imagine you're a merchant selling gym clothes and exercise equipment under the brand name **Titan**. You started with a single Shopify store serving Canadian customers.

<div className="not-prose my-8 text-base">
  <StoreDetailsCard 
    storeName="Titan Canada" 
    storeUrl="titan-canada.myshopify.com" 
  />
</div>

Business is booming. As a Shopify Plus merchant, you're now expanding into new markets: the US, Europe, Australia. Each region needs its own storefront with localized pricing, currency, and fulfillment.

You've hired developers who need sandbox environments to test new features without breaking production. Your ops team wants a staging store to preview holiday campaigns before they go live. And your B2B arm? That's a separate wholesale channel entirely.

What was once a single store is now a network of **20+ Shopify stores** you manage daily. Each with their own domain, admin panel, and team members logging in and out.

<div className="not-prose my-8 text-base relative overflow-hidden">
  <div className="grid grid-cols-1 md:grid-cols-2 gap-4">
    <StoreDetailsCard 
      storeName="Titan Canada" 
      storeUrl="titan-canada.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan US" 
      storeUrl="titan-us.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan EU" 
      storeUrl="titan-eu.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan Australia" 
      storeUrl="titan-au.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan Staging" 
      storeUrl="titan-staging.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan Dev" 
      storeUrl="titan-dev-sandbox.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan Wholesale" 
      storeUrl="titan-b2b.myshopify.com" 
    />
    <StoreDetailsCard 
      storeName="Titan QA" 
      storeUrl="titan-qa-testing.myshopify.com" 
    />
  </div>
  <div className="absolute bottom-0 left-0 right-0 h-40 bg-gradient-to-b from-transparent to-white pointer-events-none" />
</div>

See the problem?

This was the challenge we tackled alongside Shopify's product team.

## The Navigation That Wasn't Helping

<div className="not-prose my-8 flex flex-col md:flex-row gap-8">
  <div className="md:w-64 flex-shrink-0">
    <ShopifyPlusNav />
  </div>
  <div className="flex-1">
    <div style={{ marginBottom: "32px", color: "#4b5563", lineHeight: "38px", fontSize: "17.5px" }}>
      This was the Shopify Plus navigation at the time. Your stores lived in a flat list at the bottom of the sidebar. Identical icons, no visual hierarchy, no way to distinguish production from staging at a glance.
    </div>
    <div style={{ marginBottom: "32px", color: "#4b5563", lineHeight: "38px", fontSize: "17.5px" }}>
      This wasn't an oversight. It was a consequence of Shopify's origin story. Unlike Amazon, which built top-down to serve big box retailers and massive conglomerates with tens of thousands of SKUs, Shopify focused on the little guy. Mom and pop shops. Vendors with two products and a dream to build something of their own.
    </div>
    <div style={{ marginBottom: "32px", color: "#4b5563", lineHeight: "38px", fontSize: "17.5px" }}>
      Stores were never meant to span regions, operate across countries, or support the kind of development workflows that enterprise teams demand. One merchant, one store, one dream.
    </div>
    <div style={{ color: "#4b5563", lineHeight: "38px", fontSize: "17.5px" }}>
      But Shopify Plus changed everything. Suddenly you're managing 20+ stores, switching between them dozens of times a day, and every single one looks identical. One wrong click and you're editing prices on your live Canadian store instead of staging. That mistake has real consequences.
    </div>
  </div>
</div>

<div className="not-prose">
  <FlagEmojiScatter />
</div>

We spoke to **120+ merchants** from across the globe. San Diego to Santiago, Amsterdam to Cape Town, and across as many languages, writing directions, and character systems as we could find.

The goal was to gather a truly multi-national, multi-cultural dataset. How do merchants in Japan think about store organization? What mental models do German teams use? How do right-to-left languages change the way people scan a navigation?

From this research stemmed a series of experiments in wayfinding. One early direction: let merchants customize how their stores appear in the navigation. Give them control over abbreviations, emojis, even custom images to create instant visual differentiation.

<div className="not-prose my-12 text-base flex justify-center">
  <div className="scale-90 origin-top">
    <CustomizeStoreModal />
  </div>
</div>

The emoji picker was particularly interesting. Flags became an intuitive way to represent regional stores. A Canadian flag for Titan Canada, a US flag for Titan US. No reading required, just instant recognition.

But emoji proved problematic in ways we hadn't anticipated.

First, the practical constraints. Emoji didn't fit Shopify Plus's carefully constrained color palette. For accessibility reasons, the platform relied on specific color combinations that ensured sufficient contrast and readability. Emoji render differently across operating systems and browsers, making contrast ratios unpredictable and impossible to control at the platform level.

More fundamentally, emoji carried [cultural baggage that varied across regions](https://www.bbc.com/future/article/20181211-why-emoji-mean-different-things-in-different-cultures). A clapping hands emoji 👏 might signal applause in some contexts but carry very different connotations elsewhere. The thumbs up 👍 that feels casual in North America can land poorly in other cultures. What seems like a universal visual language is anything but.

Flags presented their own minefield. National representation is never neutral. It privileges some identities while erasing others. Which flag represents a merchant serving the Kurdish diaspora? What about regions with contested sovereignty, or communities whose identities have been systematically suppressed? Flags flattened complicated ethnoracial identities into neat national boxes that many of our merchants didn't fit into.

The emoji experiment taught us something important: simplicity that ignores complexity isn't simplicity at all. It's exclusion wearing a friendly face.

## The Power of Three Letters

We kept circling back to one option that initially seemed too boring to be the answer: simple letter abbreviations.

Two to three letters. No colors. No cultural symbolism. Just text.

What abbreviations lacked in visual flair, they made up for in practicality. They were scannable at a glance, worked in any color palette, and carried no hidden cultural meanings. "TC" for Titan Canada. "TS" for Titan Staging. "TX" for Titan Experimental.

More importantly, abbreviations were *shared*. Unlike personal emoji choices that might differ between team members, abbreviations were synchronized across all admin users on a store. When Sarah in Toronto and Priya in London both saw "TS", they knew they were looking at staging. No ambiguity. No miscommunication.

Yet there was still room for differentiation. Merchants could craft their own conventions, using numbers for sandbox environments, letters for regions, or any system that matched their mental model. The constraint of three characters became a creative canvas rather than a limitation.

<div className="not-prose my-12 flex justify-center">
  <StoreListAbbreviated />
</div>

The navigation transformed from a wall of identical icons into a scannable list where each store had its own identity. Production environments stood apart from staging. Regional stores were instantly distinguishable. The cognitive load of context-switching dropped dramatically.

## The Rules Behind the Letters

Of course, "just use letters" sounds simple until you try to systematize it across tens of thousands of merchants with stores named everything from "Bob's Bikes" to "クラシルセレクト公式通販".

We developed a rule system that automatically generated sensible abbreviations while remaining predictable and consistent. At launch, the system accepted A-Z, numbers, and accented characters, covering Latin scripts and their variations.

<div className="not-prose my-12">
  <AbbreviationRules />
</div>

The rules were designed to extract meaningful abbreviations from store names of varying lengths. Single-word names took the first three characters. Two-word names combined the first letter of the first word with the first two letters of the second. For three or more words, we took the initials of the first, second-to-last, and last words, capturing both the brand identity and the store variant.

For merchants operating in mixed-language environments, like Japanese stores with romanized brand names, the system intelligently extracted Latin characters while gracefully handling the rest. And for stores named entirely in non-Latin scripts? We fell back to a simple store icon, acknowledging that forced transliteration would only create confusion.

In subsequent releases, we expanded the rule system to support additional character sets under slightly more restrictive guidelines. Cyrillic and Greek alphabets were added, along with select characters from other scripts that maintained clear visual distinction at small sizes. The goal was always the same: provide enough flexibility to feel personal, with enough constraint to remain scannable.

## Live in Shopify Plus Today

This three-letter abbreviation system is the configuration that shipped, and it's still accessible in Shopify Plus today. Every merchant with multiple stores can customize their internal store name and identifier through the store settings.

<div className="not-prose my-12 flex justify-center">
  <StoreSettingsMockup />
</div>

The "Internal store name and identifier" setting lives right below the customer-facing store name. It's a small distinction with significant implications: merchants can keep their public branding clean ("Gymshark Finland") while their admin teams navigate using whatever shorthand makes sense internally.

## Measuring Success

How do you measure whether people are clicking on the right store?

This question haunted us through the entire project. Traditional metrics didn't quite fit. We couldn't track "accidental clicks" directly. There's no way to know someone's intent when they navigate to a store. Task completion rates were too coarse. User satisfaction surveys felt too subjective and lagging.

We went in circles for weeks, building increasingly complex instrumentation proposals, before taking a step back and realizing the answer had been in front of us all along.

**Bounce rate.**

Specifically: how frequently were users navigating to a store URL or tab, then navigating away again within five seconds? A bounce that quick strongly suggested they had landed on the wrong store, realized their mistake, and corrected course.

Before the rollout, this bounce rate sat at **21%**. One in five store navigations was immediately abandoned. For merchants managing dozens of stores with dozens of team members, that's thousands of wasted clicks every month. Thousands of moments of confusion. Thousands of opportunities for someone to accidentally make changes to the wrong environment.

Six months after launching the three-letter abbreviation system, that bounce rate had dropped to **under 4%**.

A reduction of over 80%. Not through forcing new behaviors or adding friction, but by making the right choice easier to see at a glance. The abbreviations worked exactly as intended, creating just enough visual differentiation that merchants could trust their navigation without second-guessing.

<StoreDifferentiationMetricsCard />

What started as a research question about wayfinding became a foundational piece of the Shopify Plus experience. A quiet improvement that thousands of merchants use every day without ever thinking about it. That's the goal of good design work: to solve problems so thoroughly that they stop feeling like problems at all.

## Our Role

Working closely with Shopify's product and engineering teams, our team led the design research and UX strategy for this multi-store wayfinding initiative. Our product designer drove the user research across 120+ merchants globally, while our team collaborated on prototyping, testing, and iterating on the abbreviation system that shipped to production.

---

## The Art of Disappearing Tech
Category: Design Philosophy
Published: Mar 26, 2025
URL: https://incomparable.design/blog/disappearing-tech

Most of our devices shout for attention. It's refreshing to consider a perspective that cuts through the noise. Martin Heidegger was a 20th-century German philosopher who wrote about how we relate to tools, spaces, and the rhythms of daily life. He challenges us to rethink our relationship with technology. He wasn't interested in flashy features or buzzwords. He cared about how tools become part of our daily grind, almost like old friends who just get it.

Heidegger’s ideas push us to look beyond the screen and consider how technology fits into our lives. His philosophy isn’t about turning devices into relics of the past; it’s about designing products that quietly support us, almost like a trusted sidekick on a wild adventure. This approach has serious implications for how we design. Making sure that our tech isn’t just smart but feels like an extension of who we are.


## The Vanishing Act of Technology

Heidegger talks about “ready-to-hand”—a state where a tool is so intuitive, you barely notice it. Think about that moment when you’re riding your bike, and you’re not thinking about the pedals or the gears; you're just moving. That’s the kind of smooth interaction we’re talking about here. Great design shouldn’t scream for your attention; it should be there, reliably in the background, letting you get on with your day.

When technology achieves that level of invisibility, it stops being a distraction and starts being a genuine aid. Imagine an app that’s so effortlessly easy to use, you hardly ever notice it’s there, yet it’s always ready when you need it. That’s the magic of designing with Heidegger’s ideas. Creating products that blend into your life like a well-worn leather jacket, always there without ever being in the way.


## Embracing Your World

At the heart of Heidegger’s philosophy is the idea of “being-in-the-world.” This isn’t some lofty, abstract concept—it’s a reminder that our lives are deeply connected to the spaces and moments we live in. Every interaction you have with your environment, including with technology, is part of a bigger picture. It’s not just about the gadget in your hand; it’s about how it fits into your day-to-day adventures.

![Screenshot of the Waze app showing real-time traffic updates and route suggestions, adapted to the user's current location.](/blog/disappearing-tech/heidegger_waze.png)
##### Waze transforms the navigation experience by adapting to the user’s environment, whether it's the chaos of city traffic or quiet rural roads, making it a smooth, context-aware tool for the drive.

For product designers, this means crafting experiences that resonate with real life. Whether it's a navigation app that intuitively understands your local shortcuts or a smart device that adapts to your routine, the goal is to design technology that feels right at home in the world you live in. When products are designed with an acute sense of place, they don’t just function. They enhance the very texture of your daily experience.


## Crafting Real Experiences

Heidegger’s notion of “dwelling” isn’t about building houses—it’s about creating spaces where you truly feel at home. In digital design, this idea translates into crafting experiences that aren’t cluttered with needless distractions. It’s about building interfaces and apps that invite you to relax, to pause, and to interact on your own terms, without overwhelming your senses.

Imagine a meditation or wellness app that doesn’t bombard you with pop-ups and relentless notifications but instead creates a serene digital space where you can just be. It’s that kind of authentic, human-centered design that makes technology feel less like a taskmaster and more like a friendly companion. By focusing on genuine, tailored experiences, designers can help users carve out pockets of calm in an otherwise hectic digital world.


## Breaking Free from the Data Trap

One of Heidegger’s more pointed critiques is how modern tech tends to “enframe” our lives, squeezing our rich experiences into neat little data points. This isn’t just a philosophical gripe; it’s a wake-up call for anyone designing digital products. The risk is turning technology into a relentless taskmaster that monitors every move, rather than a helpful tool that supports your flow.

The antidote? A healthy dose of mindful minimalism. Instead of stuffing products with every possible feature, aim to strip back the clutter and focus on what really matters. Design with an eye toward simplicity and clarity, so your technology becomes a trusted partner rather than a controlling overseer. It’s about giving users room to breathe and engage with the world on their own terms, without the constant digital shove.


## Down-to-Earth Design Takeaways

So, what does all this mean when you’re staring down at a blank canvas for your next project? First off, aim for those invisible interfaces. Build products that are so naturally intuitive, they blend into the background of everyday life. When tech works that smoothly, you’re not forced to think about it. It just happens.


Next, keep your design grounded in the user’s world. Think about where and how your product will be used. Is it meant for a bustling city commute, a quiet home office, or maybe on the go in the great outdoors? By understanding the context, you can create experiences that truly resonate. 

![Photo of a Nest thermostat displaying the current temperature and an automatic adjustment based on user habits.](/blog/disappearing-tech/heidegger_nest.png)  
##### The Nest thermostat blends into daily life by learning and adapting to your routine, automatically adjusting the temperature to match your habits, creating comfort without conscious effort.


And finally, embrace a minimalist approach. Resist the urge to pile on extra features. Instead, focus on making your product a reliable, unobtrusive companion that enhances life rather than complicating it.


## A Fresh Look at the Future of Design

Heidegger’s philosophy isn’t about rejecting technology—it’s about reimagining it. It invites us to see design not just as a way to solve problems, but as a means to enrich our daily experiences. By focusing on context, authenticity, and mindful interaction, we can create products that do more than just work. They make life a little bit better.

In a world that often feels overwhelmed by digital noise, designing with Heidegger’s insights can be a breath of fresh air. It’s about creating technology that supports you without getting in the way, that feels like a natural extension of who you are. And in doing so, we might just find a way to navigate our increasingly complex digital lives with a bit more ease and a lot more soul.


**More in this series**

- [From Plato to Pixels](/blog/plato-to-pixels)
- [Cultivating Virtue in Design](/blog/cultivating-virtue)

---

## Cultivating Virtue in Design
Category: Design Philosophy
Published: Sep 23, 2024
URL: https://incomparable.design/blog/cultivating-virtue

Many years ago, when I was deep in the halls of academia, Aristotle, a Greek philosopher from the 4th century BCE, stood out as one of the most practical thinkers in a sea of abstract thinkers. His philosophy wasn’t about contemplating unattainable ideals or engaging in intellectual exercises divorced from real life. Instead, Aristotle concerned himself with how we could live a good life by cultivating virtue. Fast-forward to today, and that same Aristotelian focus on practical wisdom can guide us in an unlikely domain: digital product design.

Tech products increasingly dominate our lives. Designers often focus on user engagement, efficiency, and aesthetics. But what if we could use Aristotle’s philosophy to design products that do more than just meet immediate needs? What if our products could help people live better, more virtuous lives?

## Living a Good Life

For those unfamiliar with Aristotle’s philosophy, his concept of *virtue ethics* is key. Aristotle didn’t think that living a good life meant following rigid rules or simply aiming for personal pleasure. Instead, he believed in developing *virtues*, positive habits that help us find a balance between extremes. For instance, courage lies between the extremes of recklessness and cowardice, and generosity sits between stinginess and wastefulness. According to Aristotle, living a good life requires practicing these virtues in a balanced way, a concept he referred to as the *golden mean*.

Virtues, for Aristotle, are not innate but learned through experience and repetition. The more we practice a virtuous behavior, the more it becomes part of our character. His philosophy teaches that real happiness and fulfillment, or what he called *eudaimonia* (flourishing or well-being), come from developing and practicing these virtues over time. 

So, how does this ancient wisdom apply to product design? If we design with an Aristotelian mindset, we’re not just creating products that solve surface-level problems or satisfy immediate desires. We’re creating products that help users build good habits, support balance, and promote their long-term well-being.

## Building Habits, Not Addictions

Aristotle would argue that the best products aren’t those that keep users hooked through addictive engagement loops. Instead, they are products that encourage users to grow and cultivate virtues, helping them find balance in their digital lives. Many products today focus on capturing attention and maximizing engagement, often leading to addictive behavior rather than self-improvement.

Take the app **Forest**, for example. Rather than promoting endless scrolling or attention-draining notifications, Forest encourages users to develop focus and time-management skills. The app works by allowing users to “plant a tree” when they need to focus. If they stay on task, the tree grows; if they leave the app or get distracted, the tree dies. Over time, this simple, gamified system promotes the virtue of *self-discipline*, helping users develop healthier work habits and find balance between productivity and distraction.

In an Aristotelian sense, Forest helps users practice moderation, finding the balance between the chaos of constant distractions and the rigid overemphasis on productivity. It’s a product that cultivates virtue, enabling users to improve themselves, not just engage for the sake of it.

## Designing for Long-Term Fulfillment

At the heart of Aristotle’s philosophy is the idea of *eudaimonia*, a deep, long-lasting sense of fulfillment that comes from living a virtuous life. It’s different from pleasure, which is fleeting, and focuses instead on living in a way that promotes growth and well-being. In product design, this means shifting the focus from short-term rewards to encouraging users to take actions that lead to long-term fulfillment.

Consider apps like **Duolingo**, which guide users through the challenging but rewarding process of learning a new language. Instead of offering instant gratification, Duolingo emphasizes steady, consistent effort. Through features like streaks and daily practice goals, the app encourages users to develop the *virtue of perseverance*—sticking with a difficult task over time to achieve real progress. This approach reflects Aristotle’s belief that mastery and growth lead to true fulfillment.

![An illustration of Duolingo's language learning app, featuring its iconic mascot and 5 other people.](/blog/cultivating-virtue/aristotle_duolingo.png)
##### Toeing the line between addiction and habit-building, Duolingo reinforces the concept of the virtue of perserverance, encouraging users to stick with the difficult task of learning a new language.

Similarly, fitness apps like **Fitbit** go beyond tracking daily steps. They encourage users to cultivate *moderation* and *self-care* by setting reasonable goals and promoting gradual improvements in health and fitness. By helping users strike a balance between being too sedentary and overexertion, these products guide people toward healthier habits, ultimately promoting their long-term well-being.

## Practical Design Implications: The Golden Mean

Aristotle’s idea of the *golden mean*—finding the balance between extremes—has clear implications for product design. Many digital products either overwhelm users with too many features or oversimplify to the point of frustration. The ideal product, like Aristotle’s virtues, strikes a balance between functionality and simplicity.

![An illustration of Duolingo's language learning app, featuring its iconic mascot and 5 other people.](/blog/cultivating-virtue/aristotle_notion.png)
##### Notion's large selection of templates illustrates its flexibility. Users can engage with as little (or as many) of these features as they need.

A great example of this balance is **Notion**, a popular productivity tool. Notion offers a robust set of features for note-taking, planning, and organization, but it’s flexible enough for users to choose how much or how little they want to engage with. It doesn’t burden users with too many preset templates or limit their creativity. Instead, it allows them to shape the app to meet their unique needs, encouraging the *virtue of autonomy* by giving users control over their workflow while fostering discipline in organizing their tasks.

## Encouraging Growth and Virtue

If we apply Aristotle’s teachings to product design, we should aim to create products that go beyond helping users achieve surface-level tasks. They should help users grow. This might mean designing experiences that promote reflection, support genuine interactions, or guide users toward healthier, more virtuous habits.

For example, **Headspace**, a popular meditation app, doesn’t just offer quick stress relief. It helps users cultivate important virtues like mindfulness, patience, and calm. These are traits essential for living a balanced and fulfilling life, and Headspace encourages users to practice these virtues regularly, leading to long-term personal growth. Aristotle would likely appreciate how the app fosters *eudaimonia* by helping users find inner peace and clarity through daily meditation.

By integrating Aristotle’s wisdom into our design philosophy, we can create products that not only serve users’ immediate needs but also contribute to their long-term well-being. When we focus on helping users become better versions of themselves, our designs gain deeper meaning and impact.

## Designing to Flourish

In the fast-paced world of product design, it’s easy to focus on quick wins, features that boost engagement or trendy visual aesthetics. But Aristotle reminds us to think beyond the immediate. By designing products that encourage users to cultivate virtue, find balance, and pursue long-term well-being, we can create a richer, more meaningful digital experience for them.

Next time you sit down to design, consider Aristotle’s teachings. Ask yourself: How can I design a product that promotes balance, encourages growth, and helps users flourish? By incorporating these enduring principles, you might just find that your product not only meets user needs but also helps them lead better, more virtuous lives.

## Further Reading

- [Nicomachean Ethics, by Aristotle](https://www.gutenberg.org/files/8438/8438-h/8438-h), is available for free on Project Gutenberg.
- [Cultivating Virtue in Design](/blog/cultivating-virtue)
- [The Art of Disappearing Tech](/blog/disappearing-tech)

---

## From Plato to Pixels
Category: Design Philosophy
Published: Sep 2, 2024
URL: https://incomparable.design/blog/plato-to-pixels

A long time ago, in college, I studied philosophy. And I absolutely loved every single second of it. Yet the reality is that philosophy does not a career make. At least, not for most people. So life took me down a different path. All the while though, I have been looking for connections between my love for (often ancient) philosophical wisdom, and the practicality of my day-to-day job. Which isn't as far-fetched as you might assume.

In the ever-evolving world of product design, where every pixel is meticulously planned and every user experience carefully crafted, it's easy to get caught up in the latest trends, tools, and technologies. But what if the key to truly innovative design lies not in the newest software or most popular aesthetic, but in ideas from over two thousand years ago? This might sound unlikely, but the philosophy of Plato, an ancient Greek thinker, offers surprising ideas that can guide modern design practices in practical ways.


## An Ideal World

For those who may not be familiar, Plato was a philosopher who lived in ancient Greece around 400 BCE. He is one of the most influential figures in Western philosophy, and his ideas have shaped many aspects of thought, from politics to science to art. Central to his philosophy is the concept of "Forms" or "Ideas," not the kind of ideas we have when brainstorming, but a deeper, more fundamental notion.

Imagine every object you encounter: a chair, a smartphone, a coffee cup. These are all specific instances of a general category of objects. They are "copies" or "shadows" of a perfect, ideal version that exists in a non-physical space. This ideal version is what Plato called a "Form." According to him, all the chairs in the world, no matter how different they are, share something essential that makes them "chairs." The Form of a chair is this essence, the perfect, unchanging blueprint that all real-world chairs try to emulate but never quite achieve

![Two chairs of different design. One Eames lounge chair, and one Ikea set.](/blog/plato-to-pixels/plato_chairs.png)
##### To Plato, despite their different designs, these chairs all aspire to the same ideal or "Form".

Plato believed that our physical world is a reflection of a higher, more perfect reality, and that true knowledge comes from understanding these perfect Forms rather than just their imperfect manifestations in the real world. In a similar way, modern designers can think about their work not just as a response to immediate user needs or aesthetic trends, but as an attempt to get closer to some ideal version of their product, a perfect, enduring design.


_Interesting. So, how does this ancient philosophy apply to product design today?_

Great question. Here are a few practical implications of Platonism that can inform and inspire your approach to creating products:

## The Pursuit of Perfection

Plato’s philosophy encourages us to strive for an ideal form, a perfect version of whatever we are designing. In the context of product design, this could mean aiming for a product that is not just functional or aesthetically pleasing, but one that perfectly balances both qualities in a way that feels enduring and universally appealing.

Consider Apple products, for instance. Apple’s design philosophy is often seen as a pursuit of perfection, a Platonic ideal of technology. The design of the iPhone or MacBook is not just about the latest trends; it’s about creating something that feels simple, elegant, and intuitive. Apple’s commitment to minimalist design and usability reflects the Platonic idea of striving toward a perfect form, a product that is not just good for today but remains relevant and desirable over time.

Or, in furniture design, we have the famous Eames Chair, seen above. This chair is celebrated for its balance of form and function, combining high-quality materials with ergonomic design to create a piece of furniture that is both beautiful and comfortable. It’s an attempt to create the ideal chair, one that satisfies aesthetic desires while meeting the practical need for comfort.

When designing a product, ask yourself: What would the perfect version of this look like? Consider not just the current needs and preferences of users, but what would make this product fundamentally excellent. This might lead to different design choices, ones that prioritize longevity, simplicity, and clarity over flashiness or trendiness.

## Where Form Meets Function

Plato’s theory of Forms emphasizes that the ideal version of an object combines perfect form and perfect function. This balance is crucial in product design, where usability and aesthetics must work hand in hand. A beautiful product that’s hard to use is just as flawed as an ugly product that works well. The ideal product seamlessly integrates both aspects.

Approach your design with a dual focus: aesthetic beauty and functional efficiency. For instance, consider the principles of Material Design, which integrates tactile elements and visual cues that mimic real-world behaviors to create intuitive user experiences. Or [Shopify's recent revamp of its design system, Polaris](https://ux.shopify.com/uplifting-shopify-polaris-7c54fc6564d9), which saw a greater focus on a simplistic, tactile, real-world inspired direction. It’s not just about looking good. Every design choice serves a functional purpose, making the user experience both beautiful and effective.

![A Braun Control calculator, designed by Dietrich Lubs and Dieter Rams.](/blog/plato-to-pixels/plato_calculator.png)
##### While Dietrich Lubs' and Dieter Rams' rounded buttons may seem old-fashioned now, there's something to be said for the longevity of the calculator design in itself. It has no embellishments, no unnecessary details, not sacrificing function over form.

Similarly, we could think of Google’s homepage. It’s famously minimalist, a single search bar on a blank white page. This design hasn’t changed much in the decades since Google's first entry onto the world wide web, and that’s because it gets to the heart of what the product is: a search engine. The design doesn’t distract from that core function, making it a kind of Platonic ideal of a search interface.

## Meaningful Experiences

Plato believed that true fulfillment comes from engaging with higher ideals. For product designers, this means thinking about how a product can create more than just a functional interaction, but a genuine experience. What higher purpose does your design serve? How does it enhance the user’s life in a significant way?

Think beyond the immediate use case of your product. Consider how it fits into the larger context of your user’s life. Does it make their day easier? Does it connect them with others? Does it help them achieve a goal or learn something new? A product that contributes to the user's higher needs, like community, growth, or well-being — will resonate more deeply and be more valued. It's a fundamental reason why social networks, regardless of their particular niche, are such an incredibly sticky product.

A great example of this is meditation apps like Headspace or Calm. They are designed not just to be easy to use or visually appealing, but to genuinely help users find calm and clarity in their daily lives. This aligns with Plato’s idea that true value comes from engaging with higher, more genuine purposes.

By embracing some of the foundational principles of Platonism, product designers can lift their work beyond the constraints of current trends or technological limitations. Instead of merely responding to what users want today, designers can strive to create products that reflect a deeper, more enduring standard of excellence. This approach can lead to designs that are not only more enduring but also more valuable to users.

So, next time you sit down to design a new product, ask yourself: What would Plato do? How can you strive for the ideal, balance form with function, and create something that truly enhances the human experience? By thinking in these terms, you might just find that the path from Plato to pixels leads to a whole new way of thinking about design.

## Further reading
- [The Republic, by Plato](https://www.gutenberg.org/files/1497/1497-h/1497-h), is available for free on Project Gutenberg.
- [The Art of Disappearing Tech](/blog/disappearing-tech)
- [Cultivating Virtue in Design](/blog/cultivating-virtue)

---

## On Design Evangelism
Category: Design Leadership
Published: Jun 3, 2024
URL: https://incomparable.design/blog/on-design-evangelism

The developer world has seen a recent upsurge in roles and titles such as Developer Advocate or Developer Evangelist. The vagueness of these titles has prompted questions such as “What does a developer evangelist/advocate do?” and “What in the world is a developer evangelist?” Champions of this advocacy movement have rushed to provide an answer to these burning questions, even going as far as writing The Developer Evangelist Handbook.

Yet on the design side of this spectrum, things have been remarkably quiet. While Design Operations (DesignOps for short) has enjoyed a spot in the limelight for some time now, it’s not a true design counterpart to this developer evangelist movement. Design evangelism remains relatively underexplored and underexplained. So it still begs the question:

*What in the world is Design Evangelism?*

The title of Design Evangelist might sound like one of those startup-only titles that don’t really describe anything about this role and still leave us wondering what these people actually do. Even for those who might be familiar or have met someone with the title of Developer or Designer Evangelist, it might still be hard to truly understand what someone who calls themselves an evangelist actually does.

To clear up the confusion around the concept of Design Evangelism, let’s start from the bottom, the foundations of what evangelism means in tech, and work our way up to evangelism in the context of design.

## Demystifying evangelism

Chris Heilmann, writer of the aforementioned Developer Evangelist Handbook, describes the concept of an evangelist as follows:

> A developer evangelist is a spokesperson, mediator, and translator between a company and both its technical staff and outside developers.

While Heilmann specifically refers to developer evangelists, I’d argue this definition stretches beyond the confines of developer roles and could apply to any evangelist. What that means is that an evangelist, regardless of their trade, is a spokesperson, mediator, translator, and advocate for their respective division. They champion the cause of their discipline to both the internal stakeholders of a company as well as the outside world.

Evangelism at its core, within both its original religious context and the modern-day tech world, is a fundamentally human-centric endeavor. It’s about communicating and projecting the thoughts, ideas, practices, and principles of a specific group of people.

Being an evangelist requires a relatively uncommon combination of abilities. It necessitates having the social skills to communicate with stakeholders at various levels and feel comfortable doing so. Evangelists are usually natural communicators, and they radiate an almost tangible passion for their craft. Not only do they want to communicate their ideas, they’re eager to educate and share their knowledge with the masses.

Communication is only one side of the coin though. Aside from their ability to convey their thoughts and advocate for their area of expertise, evangelists need to be great at what they do. Developer Evangelists need to be great developers. Design Evangelists need to be great designers, both in creating and explaining their designs.


> If pressed, I’d articulate “design evangelism” is the passionate advocacy, education, and coordination of people/principles/practices throughout an organization, using various levers and switches (social, political, economic, technological, etc.), while respecting people’s needs and goals. It’s a human-centric thing, naturally. Uday Gajendar, “What is design evangelism?"

Here, Uday Gajendar identified three core principles, a trifecta, if you will — that form the foundation of this concept. In my framing of what constitutes evangelism for designers, I’ve aimed to reword and expand these principles in order to cover the extremely large field that is design.

This effort has lead to defining the four cornerstones of design evangelism. They form the foundations of what the term encompasses and what a design evangelist actually does. These are:

- Advocate
- Educate
- Collaborate
- Inspire

Let’s dig a little deeper into each of these four domains.

## Advocate

An evangelist is first and foremost a spokesperson for their craft, a cheerleader. In order to do this right, an evangelist needs to love what they do and love what they’re advocating for. It doesn’t matter whether that’s a product, a service, or a craft.

> If you don’t love it, don’t evangelize it
> —
> Guy Kawasaki, “The Art of Evangelism”

For design, that means being passionate about everything that design touches upon. It means advocating for not just the role of designers in the product development process, but also emphasizing the role of design within the organization. Ensuring the organization understands why good design matters is a key aspect of the job.

Advocacy is where these efforts come closest to the more traditional meaning of evangelism. As an advocate for the efforts of the design craft, evangelists are zealously promoting the purpose of design and the impact it can make. It’s a means to convert those who are skeptical about what designers bring to the table and to get nondesigners to understand how design influences both the process and the outcome.

A key aspect of this advocacy is empathy. There will be people who tend to only see the world from their own perspective and are hesitant or even intimidated by anything that appears different. Relentlessly jamming information down that person’s throat is most definitely not the answer. Evangelists need to be able to empathize with or even adopt the other person’s point of view, in order to figure out what it takes to align this view with their own. This way, they can build genuine connections, built on mutual understanding.

## Educate

Advocating for what designers do and why it matters does not quite cover it. Just because you’re saying the right things, in the right order, to the right person, does not mean they fully grasp and understand the extent of why good design is tremendously important.

Like a teacher, an evangelist needs to be able to help others understand what exactly it means to be a designer, and what design, as a craft, actually entails. Simply preaching loudly to every passerby is not enough. To advocate for design, evangelists have to be able to break the entirety of their discipline down into manageable, easily digestible chunks of information.

This includes teaching developers how to critique a design, or working with stakeholders to break down any artifacts that designers create, like wireframes or mockups. Helping others to learn, understand, and appreciate the various processes, deliverables, practices, and patterns that make up the field of design is essential.

And this doesn’t just extend to external stakeholders who operate outside of the domain. It is equally important for an evangelist to be able to educate other designers, to be a guide and a mentor to help them evolve, become better designers, and perhaps even grow to become evangelists in their own right.

> The path to becoming a […] evangelist can vary from person to person and company to company, but a desire to mentor and help people is a defining part of the role. […] Evangelists don’t necessarily thrive on being the smartest the person in the room, but rather on being the most empathetic and open to questions — Clubhouse Blog, “What in the world is a developer evangelist?”)

Moreover, it’s not just about the craft and the processes, or the output of a designer. Design is as much about the user as it is about the product. Building a solid understanding of what the users of a product or service need is an integral part of being an evangelist. Great evangelists help an organization and its employees understand and empathize with their users.

Evangelists have to be able to break the entirety of their discipline down into manageable, easily digestible chunks of information.

## Collaborate

Evangelism is not a solitary effort. Establishing design as a positive force within the lives of those around you requires lending a hand and actively contributing to the efforts of others. Whether this means facilitating meetings or workshops, taking notes, or organizing and researching tools and resources, evangelists are as much supporters as they are facilitators.

> Being an evangelist gives me the ability to do something different. I can do support tickets, blog posts, write docs, go to a meetup and sit down with people to talk about their job — Ricardo Feliciano, Developer Evangelist at CircleCI

A great evangelist is able to take the backseat, let someone else drive the conversation, and only jump in whenever necessary. Great evangelists place the other person’s interests above their own. Offering to help the other person out will help build a connection and open them up to whatever it is you might have to say.

## Inspire

The ability to inspire others and rally them to your cause is an incredibly important aspect of evangelism. For design evangelists, this is likely to be even more prevalent than in other disciplines. Establishing design as a positive force within the lives of those around you requires lending a hand and actively contributing to the efforts of others.

Designers have the ability to paint a picture of the future, whether it’s an industrial designer’s CAD drawing of the newest smartphone or a UI designer’s mockup for the latest innovation in social media.

Ultimately, designers are (likely) not the ones building the final product. While there are some unicorns out there who are both developer and designer, the outcome of the product development process is a combined effort, involving many different stakeholders. Being able to create and visualize what that outcome might look like before it’s actually out there allows designers to rally others around their cause and their ideas.

> “Evangelist who cannot give a great demo” is an oxymoron. If you can’t give a great demo of your product or service, you cannot be an evangelist for it. Demoing should be as second nature, even involuntary, like breathing — Guy Kawasaki, “The Art of Evangelism”

At the heart of this ability to inspire lies the skill to give a great demo. Creating a visual representation of what will be built and sticking it on the wall like a ’90s boy band poster won’t necessarily get people excited to build a great product. Explaining your thought process, helping others understand how the finalized product would work, and walking them through this vision step by step is more likely to rouse them.

More than anything else, these four cornerstones can be boiled down to what design evangelism is truly about: empowerment. Advocating for good design. Educating others on what design is and why it matters. Collaborating to build upon that understanding. And inspiring others to build the future. All of these things are fundamentally about empowering those around you to do the best job they can and reduce friction along the way.

---

## What Bed Linen Can Teach Us About Usability
Category: Design Insights
Published: Dec 11, 2023
URL: https://incomparable.design/blog/what-bed-linen-can-teach

35 years ago, Don Norman studied the design of everyday objects in his seminal work, *The Design of Everyday Things*. Norman teaches us that everyday objects have affordance, an intrinsic attribute it offers to the user. Long, rounded bars that serve as door handles afford pulling, while small, finger-sized buttons we come across on elevators afford pushing.

Now, before I get lost in recapping the entirety of what is one of the most influential books in the history of modern product design, I want to talk about bed linen.

Because bed linen, in my opinion, afford madness.

Now, there's some confusion to clear up here. It turns out, European, British, and American (and possibly other cultures') practices of making a bed differ slightly. Some use top sheets, some use duvets only, some don't use duvets at all. When I say "bed linen" or "bedsheets", I meant the totality of the fabrics that cover your bed, mattress, pillow, etc.

With that said, let's get back to it.


## The Drool-Covered Reality

You see, I have two little kids. They're adorable in all the ways that Hollywood portrays toddlers to be. Absolutely delightful. They're also well and truly disgusting. They drool. A lot. Their hands get all grubby from the various different liquids, oozes, and goos that they manage to stick their hands in throughout any given day.

And as such, I find myself changing sheets a lot. And there a few household chores that I dislike as much as changing sheets. Maybe I'm just clumsy, maybe these things are just awful by design (hint: it's the latter. But there comes a point during the whole spectacle of changing sheets where I am dressed head-to-toe in a duvet cover like a version of Casper the Friendly Ghost, if Casper cursed like a sailor.

But things are different now. For the better.

Some time ago, I, for the second time in my life, moved to Finland. Home of reindeer, Santa Claus, the world's highest concentration of heavy metal bands, and most importantly, bed linen that will turn your world upside down.


## Rounding the Corner

To learn how to properly fit a duvet cover over said duvet, is not unlike driving a car. After figuring out the basics on how to move forwards and backwards, we get to the part where we have to deal with the dreaded enemy of both drivers and duvet cover wranglers:

Corners.

In my two-and-then-some decades of living before my fated arrival in Finland, I had wrestled with the process of crawling halfway up the cover countless times.

Tried many a different solution, and even watched high quality educational content on techniques such as "The California Roll", or "The Hand Puppet". Even got a set of covers with corner ties. Only to consistently land back at my Casper cosplay.

Until I moved to the Nordics, that is.

You see, your regular duvet cover has a singular hole. At the bottom. The part where the duvet goes in, and you inevitably stick your head. The duvet covers up here in the north, however, have three. Yes, three.

There's two extra holes, in the corners. To stick your hands into, and grab the duvet without going for an indoor spelunking session.

<div className="not-prose w-full my-12">
  <img src="/blog/what-bed-linen-can-teach/duvet-cover-method.gif" alt="A GIF demonstrating the Nordic method of fitting a duvet cover using corner hand pockets" className="w-full rounded-xl border border-neutral-200" />
  <h5 className="text-sm mt-2 text-neutral-600">The Nordic method: corner hand pockets revolutionize the duvet cover experience.</h5>
</div>

The Nordic readers amongst you are probably looking at your screens as though I'm explaining that ice is cold and the sun is hot. But to this rest of you, and my past self, this is unheard of.

> When growing up with this efficiency, you cannot imagine ever doing it the 'haphazardly cramming the duvet in whilst crawling through the duvet cover' way the rest of the world seems to insist on. […] That's how life-changing this is; you will never hate putting duvet covers on again, this we can promise you.
> 
> — Knotte, *Nordic Design Duvet Cover Hand Pockets*

It doesn't end there, however.

Whilst the addition of extra holes could be a one-and-done innovation to the ye olde duvet cover, there's more.


## Sealing the Deal

Humanity, in all its creative glory, has come up with all manner of mechanisms to deal with the pesky hole where the duvet goes. That gaping maw at the bottom of the sheet.

In my explorations, I've across a number of distinct ways in which the designers of these covers sought to close that gap. Each more baffling or deliberately time-wasting than the next.

Buttons, those charmingly old-fashioned features that adorn many duvet covers, seem harmless at first glance. They line up so obediently, waiting for you to delicately maneuver them through their corresponding holes, promising security and snugness.

Yet, the illusion is soon shattered as you attempt this routine. You fumble, struggle, and occasionally, succeed at pinching the barely fitting discs into their just-large-enough openings. But the satisfaction is often short-lived as you realize you've misaligned one button, rendering all your previous efforts futile.

Then, there are those fabric ties. Imagine a sort of tango between two pieces of fabric. With yourself as the hapless dancer trying desperately to tie them into some semblance of a knot. They mock you with their apparent simplicity. Lulling you into a false sense of security. Before transforming into a Gordian knot that Hercules himself would struggle to untangle. You pull, you tug, and you wonder if these ties are secretly conspiring against you. And really, could these ties be any smaller?

And lastly, there's those duvet covers that opt for the minimalist approach. Offering no closure mechanism whatsoever. Just an open invitation for your duvet to escape. And escape it will. Maybe not tonight. Maybe not tomorrow. But one day in the near future your duvet edges will start peeking out, mocking your feeble attempts to contain it.

![A duvet cover with a zipper seal](/blog/what-bed-linen-can-teach/zipper-duvet.png)
##### Blåvinda Duvet Cover by IKEA, the zipper solution that changes everything.

Imagine instead, the effortless glide of zipping up your jacket, now smoothly integrated into the world of bedding. No more fiddling with buttons, no more wrestling with ties, and definitely no more duvet duels. A swift, assured zip, and your duvet nestles in, snug as can be. It's not just an upgrade; it's a quiet revolt against the outdated mechanisms that once disrupted your peaceful sleep.

That's right. Duvet covers with zippers. No more button-hole pinching, tie-tying, or the imminent sense of dread that comes from watching the edges of your duvet slowly creep further out of its cover.

It's this small, simple solution that delivers immeasurable convenience. And once you've experienced the elegance of a zippered duvet cover, there's no turning back.


## Finding the Right Fit

Let's momentarily divert our attention to another understated genius in the world of beddings: the humble fitted sheet. But before we champion its praises, it's only fair to scoff, albeit lovingly, at its awkward cousin, the unfitted sheet. Its existence is akin to clinging to outdated technology in a world that's long embraced the sleek and practical. Like hanging on to your first-generation iPod.

Enter the fitted sheet. The unsung king of bedding practicality, and its often-overlooked sidekick, an inconspicuous little tag that simply reads "Head or Foot." Now, in the grand scheme of things, this tag might seem trivial, almost comical in its simplicity. But let me tell you, this tiny addition is a silent time-saver.

Picture this: you're on a mission, putting your fitted sheet on with precision, and suddenly, you're stuck in a wrestling match with the sheet, trying to figure out which end goes where. Cue frustration, sighs, and a moment of existential dread. You've got it all wrong.

![A tag at the bottom of a sheet that reads "Top or bottom"](/blog/what-bed-linen-can-teach/sheet-tag.png)
##### A simple tag transforms the fitted sheet experience. No more guessing games.

But fear not. The head-or-foot tag steps in, swooping down like a caped crusader in the alleyways of Gotham. It whispers to you, "This way up," guiding you through the maze of sheet-fitting antics. It's a small tag with monumental power, saving you precious minutes that you'd otherwise spend in a heated debate with a piece of fabric.


## The Design Lesson

At this point, you might be wondering whether this has anything to do with design or usability practices, or whether this grumpy-old-man ramble is actually going anywhere. Hang in there for just a little bit longer.

> Complacency is the enemy of progress.
> 
> — Theodore Roosevelt

Consider the evolution of bed linen you've just been witness to. A seemingly mundane aspect of everyday life. The innovation from buttons to zippers, the addition of corner holes, and the introduction of head-or-foot tags are small yet significant changes. They signify an unending pursuit of comfort and efficiency in an ordinary bedtime routine. These incremental improvements are a testament to the notion that complacency is the adversary of progress. Even in the world of beddings.

In the world of product design, this pursuit parallels the path toward creating smooth user experiences. Products are never truly "done."

They exist in a perpetual state of evolution. Ripe for enhancements and refinements. For opportunities to save time, or to facilitate an easier onboarding. Just as the duvet cover's closure mechanisms underwent metamorphoses, digital products also undergo iterative changes to improve usability.

And standing still is simply not an option. Much like the duvets and sheets that were promptly given the boot for ones that were more respectful of my time, so too do the digital products we interact with. Like Facebook beating MySpace to the punch on innovating their interface, and offering a cleaner, more streamlined experience. Or DoorDash cornering the food delivery market by focusing on an otherwise neglected audience.

Moreover, the tiny, intricate details within our designs wield substantial influence over user experience. A seemingly insignificant element, such as the color palette of our CTAs, or the wording we use to communicate with users, can profoundly impact how users engage with a product. These little looks and crannies can be exactly where you find and carve out your product-defining niche.

The overarching narrative of bed linen and my burning hatred for its ill-performing variants, resonate with the essence of product design: constantly seeking refinement, embracing change, and acknowledging that even the tiniest elements contribute to a product's success.

It's a reminder that every detail matters. And that the pursuit of an exceptional user experience demands a commitment to continuous improvement, and an openness to evolution. Even when it's something as simple as taking a picture of your friends and loved ones, there's always room for innovation.

Because thankfully, design is never "done". Even 35 years down the line, the design of everyday (and not-so-everyday) things, is still evolving.


**Further Reading**

- [The Design of Everyday Things, by Don Norman](https://www.amazon.com/Design-Everyday-Things-Revised-Expanded/dp/0465050654)
- [From Plato to Pixels](/blog/plato-to-pixels)
- [The Art of Disappearing Tech](/blog/disappearing-tech)

---

## Micro Design Systems: Breaking the Monolith
Category: Design Systems
Published: May 17, 2019
URL: https://incomparable.design/blog/micro-design-systems

Designers love to talk about a single source of truth. A singular, universal solution that forms the foundation of everything we do. A pervasive, all-encompassing system.

A design system.

But, is that centralized, monolithic approach to structuring and documenting all things design the best way to go? I'm not sold on it.

Sure, structuring a design system as a one-size-fits-all repository sounds wonderful. And it might work out at first, but our teams will likely continue to expand. As our products grow, the number of designers working on them rises. And soon enough there's a dozen, or several dozen, designers working on the same system.

And that's when this monolith starts to crack, crumbling under the ever-increasing size of the design system. With every use case added or design pattern documented, its glamorous facade starts to fade.


## Microservices for designers

In recent years, the microservice has picked up a tremendous amount of momentum. Touted by large-scale, complex services such as [Uber](https://eng.uber.com/soa/), [Netflix](https://medium.com/netflix-techblog/tagged/microservices), and [Amazon](https://aws.amazon.com/microservices/) as the best way to tackle the complexity of scaling system architecture, it's easy to see where its popularity stems from.

For those unfamiliar with the term, Amazon describes microservices as follows:

> Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs.
>
> […] Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

Microservices allow engineering organizations to split services into small autonomous, functioning parts. Where companies used to construct a monolithic system architecture, nowadays they increasingly favor the idea of building self-contained services. This reduction in dependencies allows them to build faster, scale more easily, and maintain a continuous pace in innovation.

Our developer counterparts are increasingly adopting the mindset of microservices. While they hack away at their monolithic systems to break them up into manageable pieces, us designers still hold that single be-all and end-all design system as our holy grail.

With that in mind, I propose that we instead build our design systems to form a collection of individual, purpose-driven services. By mimicking the concept of microservices, our systems can build on top of one another and allow us to design faster. Likewise, they'll be less dependent on a single point of failure.

![Diagram showing how micro design systems connect and interact](/blog/micro-design-systems/systems_start.webp)


## Breaking up our systems

When modularizing our design systems, turning each part into a separate cog in a larger machine, it can be beneficial to categorize each of these services according to their purpose, origin, and degree of dependency on other services. By setting out with a clear definition of what makes up a certain type of service, it becomes easier to decide when to extract a service, rather than having to go through the painstaking process of extracting components later on.

There are three service types that we can define from the get-go. These will likely spring up as our design system continues to grow.

- **Core**: The foundation of each design system.
- **Extension**: These services extend a particular element or set of elements in the Core service. They embed extra properties, often for a handful of specific use cases.
- **Framework**: Frameworks are purposeful services that can be reused across our products. They consist of several interrelated components.

At this stage, that still sounds rather vague. Let's walk through each of the different service types one by one. Along the way, I'll illustrate examples of the elements they can contain and how the services relate to one another.


## A strong core

![A strong core forms the heart of our design system](/blog/micro-design-systems/systems_core.webp)
##### A strong core forms the heart of our design system.

At the center of each design system sits a Core. This Core is where we start when mapping out use cases, defining their patterns, and laying the foundation of our products.

This is the service that every designer in the organization will contribute to, borrow from, and iterate on. Our Core houses foundational elements such as Color, Iconography, Spacing, and Typography. Additionally, we can define components here that stretch across the entirety of our products, components that will be used by every designer in every part of the product, such as Input, Checkbox, Button, or Dropdown.

As each designer will borrow from the Core, it's vital that we establish and maintain a certain standard of quality. After all, any changes to these parts of our design system will likely affect every area of our product.

Note that Core is not a definitive naming convention. Call it whatever works for you and your team, be it Core, Foundation, Blueprint, etc., as long as it's clear that these form the fundamental, essential base layer of the product.


## Core extensions

![Extending elements beyond their original scope](/blog/micro-design-systems/systems_extend.webp)
##### Extending elements beyond their original scope.

Extensions are services that borrow a component or a number of elements from our Core and extend their usage. By embedding additional properties, they enable us to utilize these components to address a different variety of use cases. These are often required to address complex issues in a specific context.

In the example above we see a Table consisting of a Table Header and multiple Table Cells. This simple table represents a handful of data points that exist on the same level. Its purpose is to visualize a categorized selection of data.

But what happens when we want to introduce more layers of complexity? What if we want to group the different data points or append more properties to our cells, such as Thumbnails? We'd need to extend the original header to display the different levels. And likewise, the cells should extend to contain the actions to expand or collapse data, as well as the lines indicating depth.

It's likely that not every table in our product would need to display such complex levels of data. So if we were to insert each variation of a cell or table header in our existing Core, we'd quickly start bloating our design system. These components aren't commonplace enough to constitute an essential part of our system.

Instead, we can extract these extended elements to a separate service. This allows us to iterate on the existing elements and build in additional properties that serve a specific purpose. All while maintaining a functional, minimal foundation.


## Purpose-driven frameworks

![Frameworks are defined by a common purpose](/blog/micro-design-systems/systems_framework.webp)
##### Frameworks are defined by a common purpose.

Frameworks do not rely or expand on existing foundational elements. Rather, they house a collection of elements that share a common purpose. Their main objective is to speed up the design process and enable quicker design iterations.

The example above demonstrates a Sidebar Framework. The sidebar in our example contains a handful of components used to construct it: A header indicating the general purpose of a page or product area, subsection headers to group content, and the different navigational components.

The different elements of the Framework are bound together by a common purpose. They don't hold much significance on their own. Nor are they able to communicate their intent without relying on the entirety of the Framework. This sets them apart from the foundational elements in our Core. Components such as Buttons are able to communicate a specific function. We don't need to rely on any other parts of our system to identify their purpose.

Extracting Frameworks has the benefit of keeping the Core light and agile. Framing these different elements makes it easier for any designer on our team to recognize what the intended function of an element is. This circumvents the need for convoluted naming conventions.

Whereas Extensions borrow from the existing elements and insert additional layers of complexity, Frameworks form a more complete, interconnected package from the get-go. Moving that to a separate service will thus result in a more immediate reduction in the number of moving parts in the Core.


## A growing number of services

![The number of services grows as we scale our teams and products](/blog/micro-design-systems/systems_services.webp)
##### The number of services grows as we scale our teams and products.

As our products develop, our design systems continue to expand in scale and scope. A monolithic approach can get unwieldy rather fast. Knowing that, we should aim to proactively extract different elements to a purposeful service.

In a perfect world, the number of different services will scale up parallel to our product development. Elements will flow at regular intervals between our foundational Core and the separate services, both upstream and downstream. Either we extract services the moment they grow so big that their size pollutes the foundation, or make a deliberate call to do so from the very start.

By moving elements into separate modules, we leave more room for experimentation. Whilst the Core maintains the highest standard due to its pervasive nature, the smaller, predefined scope of the other services opens up the ability to explore different variations.


## Broadening the scope

![Expanding our service types](/blog/micro-design-systems/systems_service-types.webp)
##### Expanding our service types.

At times we'll come across various elements of our design systems that don't fit the bill for either an Extension or a Framework. And that's okay. The beauty of the proposed architecture is that there is room for expansion. Meaning we can add extra service types if we see a distinct need for them.

One such service type that we could come across is a Pattern. We've defined that Extensions build on top of existing components and add to their functionality. Likewise, Frameworks have a shared purpose. Patterns don't exhibit either of these properties.

![Card Pattern example showing various card layouts](/blog/micro-design-systems/systems_patterns.webp)

In the example above, there's an instance of a Card Pattern. It's composed of several elements that don't adhere to either of the service types we defined earlier.

Cards are in essence containers for other elements. As seen in the three examples above, they can contain a large variety of different components, with little to no mandatory elements. The actual bare-bones Card, the combination of Background, Border, and Spacing, could very well be a foundational element.

The contents themselves aren't bound together by a single shared purpose. Illustrations, photos, videos, and buttons can all appear in multiple places in our products. They can appear in different setups, with or without a Card to serve as a container. As such, Patterns are neither Extension nor Framework.

Rather, they serve as building blocks or guidelines. Their aim is to provide a frame of reference on how to lay out, combine, and piece together an interface of different parts. They're templates that function as a starting point, rather than an end-to-end solution.

It's easy, then, to see that as we continue to expand our design systems, we'll come across use cases that are not categorized by the service types we set out with. And that's exactly the point.

Our systems are no longer rigid, single-category monoliths. They are instead made up of different services that spring forth from the product development process. Different setups and companies necessitate different types and categorization. Defining service types beyond our initial set forces us to question our own classification and hierarchy.


## Drawbacks

Like any approach, this too has its fair share of drawbacks. Many of the same issues that plague microservices also surface when building these micro design systems.

> The biggest disadvantage of a microservices architecture is its increased complexity over a monolithic application. The complexity of a microservices-based application is directly correlated with the number of services involved.
>
> , Phil Wittmer, Tiempo Development

Complexity is the main disadvantage for our systems, as well. A growing number of different services means that the responsibility for maintaining these services is spread out, rather than centralized. Additionally, it forces us to consciously extract existing elements out of our Core service. This means that we need to assign dedicated resources to do so.

While this is certainly a drawback, it also provides some benefits. Spreading out the responsibility of maintaining different services means less individual workload. It also enables us to enforce a higher level of quality on the Core, while keeping a degree of independence in the extracted services. This independence allows us to develop these extractions at a faster pace. We can thus innovate more rapidly and speed up feature development.

Luckily for us designers, recent developments in design tooling allow us to realize this approach in a rather efficient manner. Tools such as Abstract support this model out of the box, by allowing users to plug-and-play different Sketch Libraries per project. We can thus easily assign different Extensions and Frameworks to projects as needed.

Another drawback is that micro design systems are not true microservices. Whereas microservices exhibit complete autonomy, our design systems still rely on a certain degree of interconnectivity. Extensions still borrow from the Core service, and our features still rely on several degrees of connectivity. These connections are unlikely to go away at any point in the future. The nature of design work — and front-end development for that matter — is intrinsically bound by this.

As a counterpoint, these relationships between elements also enforce a distinct degree of visual consistency. Any given interface is likely to consist of several elements, borrowing from different services. Having these services be visually different would then become immediately clear.

With many of our design systems still in their infancy, now is the time for us to mature our work. By modeling, categorizing, and extracting the different services in our systems, we force ourselves to answer questions about the nature of different elements, set quality standards for their foundation, and prepare them for the future.

Our tools are already paving the way for us to change the way we think about our work. Following in their footsteps will allow us to establish a shared language and improve our design systems for the better.


## Further Reading

- [The Problem of Creative Scaling](/blog/the-problem-of-creative-scaling)
- [On Design Evangelism](/blog/on-design-evangelism)

---