# Incomparable — Full Content Incomparable is a 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. 1,000+ participants across 5 continents and 17 countries. Case study: Incomparable helped Shopify Plus cut wrong-store navigation errors from 21% to under 4%. This file contains the full text of every published post and workshop description. It is intended for LLM consumption. --- # About the Studio URL: https://incomparable.design/about Incomparable is a 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 in-person design workshops delivered to 1,000+ participants across 5 continents and 17 countries. Contact: hello@incomparable.design. Intro call: https://cal.com/incomparable/introduction. --- # 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 Incomparable; 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 Problem of Creative Scaling Category: Design Leadership Published: Jul 8, 2026 URL: https://incomparable.design/blog/the-problem-of-creative-scaling The best designers we've worked with almost all hit the same wall. They get promoted for being excellent at the work. They lead because they're the person the team keeps turning to. Their opinions are sharper, their instincts are better-calibrated, their execution is cleaner than almost anyone else's on the team. Being them is a superpower. And then the org doubles. Suddenly there are ten product streams where there used to be three. The decisions are no longer theirs to make personally. There are too many of them, happening simultaneously, in meetings they weren't in. The team is looking at them for the same quality of judgment they always provided, but the bandwidth doesn't exist. This is where creative leaders break. And it's usually a quiet break. They don't quit. They don't announce it. They start working more hours to cover the gap, which works for a while, until it doesn't. Eventually they either burn out or become the bottleneck the org routes around. Both are failures of the same problem. ## The trap The skill that got you promoted is the skill that's killing you. Being the best problem-solver on your team made you indispensable. But indispensability doesn't scale past a certain headcount. At some point the company needs more judgment than your schedule can produce, and the only way forward is to get the judgment out of your head and into other people. Most creative leaders know this intellectually. They nod when they hear it. Then they go back to solving problems personally because it's faster and the problem is right there in front of them. Here's the thing. In the short term, it is faster. A Staff-level Product Designer who drafts the fix in Figma themselves will ship a better fix, faster, than if they coached a junior through drafting it. That's real. If speed of this one fix is what matters, solving it personally is correct. But speed of this fix isn't what matters. What matters is the rate at which fixes happen across the whole team, compounded over the next two years. That rate is determined by how many people on the team can solve fix-shaped problems without you. Every time you solve one personally, you postpone building that capability by one problem. ## The role shift Scaling as a creative leader isn't primarily about managing more people. The harder shift is changing what your job is. In the IC frame, your job is to produce great work. In the leadership frame, your job is to produce great judgment in other people. The deliverable changes. The metric changes. What "a good day" looks like changes. A good day as an IC: shipped a thing, solved a hard problem, made something sharper. A good day as a leader: someone else on the team shipped a thing, solved a hard problem, made something sharper, and you weren't in the meeting. Most creative leaders struggle with this because the leadership version doesn't feel like achievement. It feels like absence. You sit in fewer decisions. Your taste shows up less directly in the work. The craft you used to do every day is now being done by someone else, less well than you would have done it. This is the job. Getting comfortable with it is most of the work of leveling up. ## Three things that actually move the needle Here's what we've seen work across several engagements with design leadership teams at scaling companies. **Coaching over critique.** When a team member shows you work, resist the urge to fix it. Ask what they tried, what they rejected, what decisions they're unsure about. Their reasoning is the thing you're developing. The final design is downstream of that. If the reasoning is sharp, the design will be fine. If the reasoning is weak, a fix you provide today won't transfer to tomorrow's problem. **Write things down.** Every time you give a piece of feedback that feels generalizable — principles, guidelines, how-we-decide rules — write it somewhere shared. You're trying to externalize your judgment. A principle on a wiki page can be applied by someone you've never met. A principle in your head can only be applied by you. **Decide who decides.** When a decision comes to you, the first question isn't "what's the right answer?" It's "should I be the one deciding this?" Half the decisions landing on your desk shouldn't be yours to make. Naming who owns what, explicitly, removes the default assumption that hard calls route to you. These are not new ideas. You've read them somewhere before. The question is whether you actually do them when it's faster, in the moment, to just solve the problem yourself. ## What doesn't work A short list of the anti-patterns we see most. **"I'll just do this one myself."** The hardest word to learn is "no" to problems you could solve. You have to say it anyway. **Expanding your calendar.** If your first move is to add more meetings to absorb more decisions, you've misdiagnosed the problem. You don't need more meeting throughput. You need fewer decisions routing to you. **Hiring more senior people to solve it.** Staff-level Product Designers don't solve the scaling problem unless you also change how you lead them. A senior report who has to check with you on every call isn't operating at the level you hired them for. You're just paying more for the same bottleneck. **Becoming a pure people manager.** The instinct to drop the craft entirely and become a pure manager is a different kind of mistake. Your taste and judgment are the reason people came to work for you. Losing them in service of "scaling" means your team loses the thing that made the leadership worth having. The point isn't to stop having taste. The job is to find ways for your taste to leave your head. ## What the job actually is Creative leadership at scale is mostly about leaving a smaller footprint while producing a larger outcome. That's a strange, counterintuitive job. And almost nobody trains you for it. You were trained to be excellent at the work. Being excellent at enabling other people to be excellent at the work is a different job, and the transition isn't smooth. Which is why so many creative leaders hit this wall and stall there. If you recognize yourself in any of this, it isn't a character flaw. It's the predictable consequence of being good at the individual version of the job. The way out isn't working harder. It's changing what you work on. --- This is one of the patterns we work on in our [Design Principles workshop](/workshops/design-principles), because the act of writing principles is often the first real externalization of a leader's taste into something a team can use without them. If your leadership bandwidth is the bottleneck, that's where to start. --- ## The Empathy Gap in AI Category: Product Design Published: Jul 3, 2026 URL: https://incomparable.design/blog/the-empathy-gap-in-ai Your AI will never be able to empathize. It's not built for empathy. It can approximate, and imitate, but it is fundamentally incapable of caring. That absence of empathy becomes a product problem the moment you stop accounting for it. ## A Growing Dependency As product builders, be it designers, engineers, product managers, or an amalgamations of all three of those roles that seem ever more pervasive these days, we've come to rely on AI more and more over the past few years. It's inevitable, and inescapable. AI is genuinely better than we are at some things. It can analyze data at scale, digest enormous volumes of text, and synthesize information in seconds. Be it Claude, Perplexity, Cursor, or whichever form your daily artificial assistant takes, it's undeniable that we've all grown accustomed to leaning on it. It's easier to let it stew on a question while you work on a different task, let it compile a slide deck for a presentation, or have five different instances work through your task list in parallel. The danger isn't *using* AI. It's forgetting which problems were never really about information in the first place. And that danger arises when we start handing over tasks that are unquestionably human in origin. When we forsake things that have traditionally landed in the domain of conversation. Of empathy. Think of user interviews. Of customer support calls. Of answering your in-product chat inbox. Or of writing help center articles about commonly (or uncommonly) occurring issues. Those are by their very nature inextricably human endeavours. And yet we're increasingly finding opportunities to outsource these to our artificial companions. ## Stuck A while back, I gave a talk at a conference, titled ["Where Are The Humans?"](https://incomparable.design/blog/where-are-the-humans) And the fundamental issue at hand here was similar, yet different, than the one outlined above. Humanity is quickly disappearing from our products, and is being replaced efficiency. Or so we like to tell ourselves. Instead, in my experience over the last two to three years, we've shifted the onus of finding a path forwards in unexpected situations from our knowledge bases, Support staff, and Customer Success teams, to the user themselves. The difficulties that one encounters using our products hasn't gone anywhere. It's just been quietly re-routed and diluted to a "them" problem, instead of an "us" problem. And the result of this, is that our users feel more stuck than ever. Isolated even. In that talk, I mentioned several instances where I, as the end-user of a product, had gotten stuck. And the only way forward was through a series of increasingly frustrated interactions with artificial support systems. Electronically voiced agents over the phone repeatedly echoing "Please tell us how we can help", with no actual capability of helping. Since then, it's gotten worse. These instances of being left at the whims of an AI that is incapable of understanding the intricacies of human emotion, and was never intended to do so, have grown exponentially. From being stuck at an airport at 5:17 in the morning because an "AI-first fraud detection algorithm" suddenly decided an Uber ride was an abnormal spending pattern amongst a history of hundreds of similar rides, to having a company-issued laptop shipped out to my home and back to the supplier because the automated agent on the other end of the conversation misconstrued my support request, I've felt more lost than ever. And that's the thing that strikes me every time. None of those situations required a more capable model. They required someone to recognize that I wasn't asking the right question. That I was frustrated. That I was tired. That I wasn't looking for another explanation of policy, but for a way forward. The failure wasn't one of intelligence. It was one of empathy. ## Staying Close So where does that leave us? Do we reject AI and return to a world before the advent of LLMs? Probably not. A blanket rejection of all things AI likely results in our roles (and products) getting cannibalized by someone who does embrace the things that it is specifically good at. Assuming we can travel back to a time before conversational UI became mainstream would be just as naive as believing AI will eventually replace every human task imaginable. Instead, I think there's something to be said for being deliberate. For consciously being slower. For being deliberate about what we choose to delegate. Not everywhere. Just in the places where speed costs us understanding. There's a time for speed. For efficiency. When you're summarizing an interview, sure. Or writing the first draft of a help centre article. Or for identifying patterns across five hundreds support conversations. But sitting in the interview itself? Writing the support ticket response? Watching someone struggle the workflows that you and your team have just spent 6 months refining? No. Those aren't outsourceable tasks. Those are where empathy originates. Where it is cultivated, understood, and embeds itself in the way you build experiences. Those are the moments that remind us our users aren't personas, metrics, or dashboards. They're people. Standing on a train platform on their way to work. Half-listening in a Zoom meeting while trying to fix an issue before the next agenda item. Trying to get through their day. Those moments are uncomfortable. But they're also irreplaceable. Because they teach us what it actually feels like to use the thing we've built. That isn't something you can generate after the fact. The interview summary tells you what was said. It doesn't tell you why someone hesitated before answering. It doesn't tell you that they apologized before asking a question. It doesn't tell you that they were clearly frustrated, but trying not to sound rude. Those details are easy to omit because they don't look like data. They're also where empathy comes from. ## Beyond Dogfooding For years we've been told to [dogfood](https://bubble.io/blog/dogfooding-startup-tech/) our own products. > “Dogfooding” refers to the practice of using your own company’s product internally. Companies dogfood to catch bugs before customers do, build genuine product empathy across teams, and test whether the product holds up under real daily use. Dogfooding has been one of those ideas in product development that has become almost universally accepted. And for good reason. If we aren't willing to use the things we build, why should anyone else? But I think we've slowly started asking dogfooding to answer a question it never really could. The goal was never to prove that we could use our product. It was to understand whether the people we built it for could. Those are fundamentally different things. When I use my own product, I bring months, sometimes years, of context with me. I know why a feature exists. I know what compromises were made to get it shipped. I know which workflows are still rough around the edges, and which ones we simply haven't gotten around to improving yet. I know what an error message is trying to tell me, even when it does a poor job of saying it. My users know none of that. Instead, they bring an entirely different kind of context. The meeting they're already late for. The train they're trying not to miss. The frustration of having already spent twenty minutes trying to solve a problem before finally reaching out for help. The expectation that this should have been straightforward, and the creeping suspicion that perhaps they're the one doing something wrong. Dogfooding will never show me that. The closest I'll ever get is by spending time with the people using my product. By watching them hesitate before clicking a button. By seeing the workaround they invent because the intended workflow wasn't obvious. By noticing the questions they apologize for asking because they assume they should already know the answer. ## The Long Way Around When I first started putting these thoughts to paper, I thought it was going to be about AI. It isn't. And it is. But more fundamentally it's about distance. Over the years we've become remarkably good at insulating ourselves from the uncomfortable parts of building products. We have dashboards instead of conversations. Personas instead of people. AI-generated summaries instead of sitting through the interview where someone spent the first ten minutes convinced the problem was their fault, before quietly admitting they'd nearly given up altogether. None of those things are inherently bad. In fact, they're often incredibly useful. I've lost count of the number of times I've asked Claude to summarize an interview transcript before going back through it myself. I'd be lying if I said I was about to stop doing that. But there's a difference between making sense of an experience, and replacing it. One saves time, the other costs perspective. I worry that we're becoming so good at removing ourselves from the messy parts of product development that we're also removing ourselves from the very things that taught us empathy in the first place. The awkward interview where nothing quite goes to plan. The support conversation that turns out not to be about the bug you thought it was. The customer who spends fifteen minutes describing the wrong problem because they don't yet have the vocabulary to describe the real one. Those moments are inefficient. They're also where the work happens. Not the work of shipping features. The work of understanding the people you're shipping them for. Somewhere tomorrow morning, someone will open your product between two meetings. They'll have a coffee in one hand and a Slack notification demanding their attention in the other. They'll click the wrong thing. They'll misunderstand what you meant. They'll blame themselves before they blame you. No dashboard will ever tell you what that felt like. You have to go and see it for yourself. --- ## Micro Design Systems, Seven Years Later Category: Design Systems Published: Jun 13, 2026 URL: https://incomparable.design/blog/micro-design-systems-revisited In 2019 we wrote a post arguing that design systems should be built like microservices — modular, purpose-driven, and composable — rather than as one giant monolith. Seven years is a long time in this field. Figma has variables now. Design tokens have a W3C spec. Design engineer became a job title with its own conference talks. AI generates components you didn't ask for. And a lot of design system teams that existed in 2019 no longer exist. So a revisit is overdue. What did the original post get right? What aged? What would we write if we were sitting down today? ## What modularity confirmed The core argument held up. Centralized, one-size-fits-all design systems collapse under their own weight. Every design system we've worked with since has either already discovered this or is on the path to discovering it. The teams that build their systems modularly — Core primitives, Extensions for brand or domain, Frameworks for product-specific patterns — move faster. They ship more. Their contributors don't have to fight a monolith to add a variant. They can reach for what they need without bringing along everything they don't. That part of the thesis aged well. What aged differently is how we implement it. ## The tokens layer changed everything In 2019, design tokens were mostly JSON files exported from Figma via plugins, regenerated whenever a designer breathed on them. Implementation was messy. Most teams didn't bother. Today tokens are a discipline. The W3C draft for design token format, around since 2022, pushed the ecosystem toward a shared definition. Figma shipped variables. Tokens Studio became the default for teams with even moderate complexity. Style Dictionary is the boring backbone nobody talks about that runs in production at enormous scale. What this enabled is more important than the tooling itself. You can now have one token layer, consumed by multiple brands, multiple products, multiple platforms. The modular argument from 2019 used to terminate at the component level. It now extends all the way down, into the raw values that components compose from. Which means a micro design system in 2026 isn't three tiers. It's four. Tokens sit underneath everything. ## Design engineers moved the line In 2019 the people maintaining design systems were mostly designers who could prototype in code and engineers who cared about components. The job title "design engineer" existed at Vercel and a few other places but hadn't really caught on. It has now. And the effect on design systems has been significant. Design engineers don't build systems the way designers build Figma libraries. They build them as code primitives, carefully typed, closely tracking how they're actually used in product code. A design engineer on a team tends to pull the design system closer to the application. The gap between the Figma library and the shipped product shrinks. This doesn't make the 2019 architecture wrong. It makes it more implementable. The Core/Extension/Framework distinction is clearer when someone is actively policing the boundary in pull requests. ## The quiet death of the design systems team Here's the one we didn't predict. In 2019, the model was clear. You had a design system, therefore you had a team that owned it. The Material team at Google. The Polaris team at Shopify. The Lightning team at Salesforce. These teams were expected to be permanent, expanding institutions. Several of them don't exist in the same form anymore. The pattern we've watched play out at multiple companies: the design system team hits a peak in year three or four. After that, the arguments for maintaining a dedicated team get harder. Product teams want to move faster than the central team can review. Central teams calcify. The conversation shifts from "we need a team to own this" to "we need this to stop being owned by a team." What replaces it is usually a federation. Primitives are owned centrally, by a handful of people. Extensions and Frameworks are owned by the product teams that use them, with a shared review process. The system remains coherent but the ownership is distributed. This is the 2019 thesis taken to its logical endpoint. If your system is modular, the teams that own it can be modular too. ## What we'd write today If we were writing the original post now, three things would be different. One: we'd start from tokens, not components. The token layer is the load-bearing part of the system. Components are downstream. Two: we'd talk about the organization as much as the architecture. The systems that work are the ones where nobody has to ask permission to extend them. Modularity in code, modularity in ownership, modularity in decision-making. One without the others doesn't hold. Three: we'd take AI more seriously. Not because AI is generating design systems (most of what's been shipped in that space is noise). But because the tedious work of keeping components and tokens in sync across platforms is the exact work AI tools can plausibly do well, and the teams who figure out how to use them without losing coherence will move meaningfully faster. ## What still stands The reason monolithic design systems fail isn't a technical limitation. It's that complex systems always fragment. The only question is whether the fragmentation is planned or accidental. Monoliths fragment accidentally. Modular systems fragment by design. That part hasn't changed. It won't. --- If your design system is pulling in opposite directions — too rigid for product teams, too chaotic for platform teams — the underlying issue is almost always the boundary between what's centralized and what's federated. Happy to talk through how to draw that line for your situation. --- ## Dear (Future) Designer: Don't Learn How To Code Category: Design Career Published: Jun 3, 2026 URL: https://incomparable.design/blog/dear-designer-dont-code At some point in your career someone will tell you to learn to code. They'll mean well. Don't listen. This isn't anti-code. Code is useful. Code is interesting. Code is, for many of the interfaces you design, the actual material you're working with. What we're against is the specific cultural assumption, still everywhere in our profession, that designers should be aspiring developers in disguise. That learning Swift or React or whatever's popular this year is the ceiling your career is trying to reach. That if you can't also ship, you're only half a designer. You're not half a designer. ## What "learn to code" usually means Most of the people telling you to learn to code aren't telling you to build applications. They're telling you to be less annoying to engineers. That's a real problem. We've watched designers hand off Figma files with pixel values that don't align to any grid, colors that aren't in the design system, and interactions that don't work because they weren't considered. But the solution to that problem isn't "write more code." It's "understand what you're handing off." These are different things. The first is a massive time investment that produces a mediocre developer who isn't being paid to be one. The second is a week of focused curiosity that makes you a better designer. ## The actual skill What you need is literacy, not fluency. When you design a button in Figma, know it maps to a `