Operating as a Principal Designer
With Principal Designers from Zalando, Shopify and Mews.
Job title inflation in design is rife.
There are many people with titles and claims to be operating at levels which they just are not. This happens when companies don’t know how to hire, attract and retain talent. This results in designers getting out of their depth, levelling gets diluted, and design ends up underutilised in the organisation.
The Principal title is one of the most misunderstood roles in design.
I wanted to go deep into the weeds of people genuinely operating at Principal levels in organisations who understand this level, so in this article, it’s a combination of voices from José Torre (Senior Staff Designer at Shopify), Thiago Hapner (Head of Product Design IC at Zalando), and Diana Arizmendi (Principal Designer at Mews)
TL;DR:
Principals spend more time working on the problem itself.
The work is about reducing the number of problems that need to be solved in the first place.
Anyone can claim the work that’s already on the roadmap, but my job is to find the work that isn’t.
Make yourself progressively less necessary.
1. What is a Principal Designer?
Jose: The easiest way to misunderstand a Principal role is to think it’s just a very experienced designer, who’s better and faster than everyone else. Or someone who doesn’t need collaborators.
Craft is important, but that’s not the point. The real challenge is having someone capable of navigating complexity (multiple teams, competing priorities, evolving systems, long-term aim). You are trying to help an organisation make better decisions earlier, before the work becomes execution.
The biggest shift is not about how well or how fast you design; it’s about which problems you spend time on. Mid/Senior designers spend time on solutions, whereas Principals spend more time working on the problem itself.
You’re still doing it through design. The medium doesn’t change; what changes is how you use it.
At higher levels, execution becomes a tool for creating clarity and bringing people along. You design concepts, prototypes, or directions not just to solve the problem or hand them off to engineering, but to help others see it, react to it, and align around it.
The artefact is rarely the goal; it’s more a way to make an idea tangible, so teams debate it, improve it, and move forward together.
You might not ship as many screens directly, but you help shape the direction that affects entire product surfaces or multiple teams at once.
The biggest shift from senior roles was where the work starts.
One thing that I learned through my years designing, is that clarity rarely comes from discussion alone. Clarity comes from making. Sketches, concepts and prototypes aren’t just communication tools, they are how I think through ambiguity, and help other see a direction that otherwise would be stuck in my head.
Thiago: The simplest way I’d describe a Principal (from C8 onwards) is that it’s a designer experienced enough to drive high-impact projects autonomously, while at the same time helping the less experienced designers around them raise their craft and maintain consistency. They should also be able to spot synergies across projects within the wider company and contribute to the design community beyond their immediate team through knowledge sharing, mentoring, or other ways to lift the collective quality of the field.
One thing I’d add that often gets missed: a Principal is not just a “very senior” designer who does more hands-on work without hand-holding. That’s a common and costly misconception. Companies often see someone doing good work and pile more tasks on them. That leaves little time and energy for anything else, and the person defaults to what I call firefighter mode: jumping in to fix things, then moving out again, instead of building long-term capability in the people around them. That pattern feels productive in the short term, but it’s actually a bad one. It doesn’t scale and leaves less-experienced designers without real support.
People managers are often years away from their craft, and if not, they just don’t have the bandwidth to be the ones raising the bar on craft quality on scale, in addition to everything else they do for our teams. That’s where a Principal comes in. At Zalando, we’ve built mutual respect between people leaders and craft leaders, supporting and learning from each other.
As for how I split my time, it’s less a fixed ratio and more a set of hats I wear depending on what’s needed. At the SC1 level, those hats include hands-on design leadership on key projects, recurring craft reviews and quality oversight across teams, mentoring individual designers, sponsoring specific initiatives in the broader design community, hiring and sometimes managing external freelancers. The further you go up the IC track, the less it’s about what you personally produce and the more it’s about how you enable and support others.
2. Principal vs Staff vs Senior
Thiago: The clearest way I can describe my own progression: at C7, I worked on design tasks within a defined project scope. My lead was involved in bigger decisions, and although I had a good understanding of what needed to be done, I still needed guidance on direction. My job was to execute well on what was in front of me.
At C8 (Principal), I started leading larger, higher-stakes projects autonomously. I could guide other designers, researchers, copywriters, and engineers who work alongside me. I took on more stakeholder management, more pressure and higher-impact work. But I could still put my headphones on, work alone and hide behind my craft.
When I moved to SC1 (Head of Design), it became clear that I am part of the company's design leadership. I can’t jump in and do things myself at the scale I am expected to operate in. I had to learn how to scale my impact as an individual, and that required a very different set of skills: motivation, feedback (sometimes harsh feedback), guiding people through ambiguity and simplifying scopes that got out of hand due to complex stakeholder environments and working in unintended siloes.
3. How to grow into a Principal Role?
Jose: The shift happens when you stop seeing design as solving an isolated problem and start seeing it as sharing how problems are understood and solved across a system.
Principal designers look at the system behind the problems. The work is about reducing the number of problems that need to be solved in the first place.
To grow into that, you need to:
Use design to drive alignment, not just executions. Design becomes a way to make ideas tangible so others can react to them. You sketch, prototype and explore, but the goal is not the artefact itself. It’s to help teams and stakeholders see a direction clearly, challenge it, and ultimately align around it.
Get comfortable finding and defining problems. You can wait for someone to hand you a problem, but you need to lead. Find what feels off, what doesn’t scale, where teams are doing the same thing slightly differently. But don’t stop at pointing it out. Your job is to turn that into something actionable. Sometimes that’s a direction, other times it actually means preventing a team from solving the wrong problem.
Build judgement, not just skill. Design always comes with trade-offs. The perfect design rarely ships. You’re constantly navigating real-world complexity. Technical constraints, business priorities, and organisational reality almost never play well with the ideal solution. But what matters is your ability to navigate the tension and move the work forward in a coherent direction.
Focus on leverage. You don’t need to work on everything. The real goal is to have an impact beyond the work you touch directly. That means making your work visible and reusable, because sharing solutions is what prevents fragmentation later. It’s not just about what you design, but what the organisation designs because of you.
Titles matter less than the work you can point to. What defines your level is the problems you take on, the scope of your impact, and the direction you help shape. The title, hopefully, catches up sooner or later.
4. How do you operate as a Principal?
Diana: The reality of the role looks nothing like the official job description.
The expectations my CPTO has of me are different from those of a Senior Designer on the team. And we have to be okay with that ambiguity; figuring out what the role should be is a significant part of the role.
As a Principal, I have one or multiple big problems per day. My job is to unblock direction on each of them. I’m not always the one doing the work but the one making sure the work can move.
In a given week I might be designing a new feature or an initial concept to hand off to a team, jumping in as a PM on an initiative that needs one, enabling designers through mentoring or shared frameworks, working on the career ladder, defining a new Design System governance model, or training AI agents — embedding our design voice, principles, and standards into their outputs — so that good design thinking scales beyond any individual designer and becomes accessible to non-designers as well.
Another interesting part of the role is making problems. Finding the gaps where design is under-leveraged, where no one is looking, where the product quietly becomes fragmented without anyone noticing. Anyone can claim the work that’s already on the roadmap, but my job is to find the work that isn’t.
On not being a bottleneck
You can’t be in every conversation, own every design decision, set every standard and take every judgment call. Centralising decisions around yourself doesn’t scale and isn’t leadership; it just creates a single point of failure.
When I first started the role, I stepped in constantly to connect dots and unblock cross-team work. It was useful in the moment, but it also concentrated too much clarity and decision-making around me. Teams were making progress, but within frameworks, only I fully understood.
You don’t need to solve every problem yourself. Sometimes asking a different question is enough to reframe a team’s thinking. Some of my most useful moments have been single conversations in which I asked something no one had asked before, and a team shifted direction as a result.
What I believe in now is spotting what’s already working and amplifying it.
One of the designers on my team, Rachel, started running Show & Tells to share work across tribes, a ritual she invented herself. I didn’t create it. My job was to recognise it mattered, promote it and make it the standard.
Another shift I’ve been making is going from “how do I improve this?” to “how can good decisions happen without me?”
We’ve embedded design into go/no-go quality gates. Design quality is no longer solely the responsibility of the design team; it’s part of how we ship, and everyone is responsible for it. Structural changes outlast individuals.
Make yourself progressively less necessary. If you’re always the one unblocking things, you’ve failed to build anything that lasts, and you’ve stolen the opportunity to let others grow.
On rituals and systems
We’ve tried the “official” way of documented processes, templates for everything and many rituals, but in a fast-moving company, most of it becomes noise. People work around it, or you end up maintaining the documentation instead of doing the work.
What actually works is much simpler: good principles and a shared vocabulary.
At Mews, we defined a Design Ethos: “Design for Familiarity” and a set of five principles around what good design means for us. The goal wasn’t a document designers reference once and forget it was to create a shared language that reduces debate. When a team disagrees about direction, the principles become the reference point, not me. Faster alignment on tricky calls, less design-by-committee, fewer escalations. They’re now part of how we show work and part of our quality gates before delivery.
Terms like “simple by default” or “design for familiarity” have changed how Mews teams discuss trade-offs. It’s easy to ask whether a solution feels “familiar” or whether it contradicts what “simple” means to us. The vocabulary does the work and it scales across teams, across new hires, and across the AI agents now trained on those same principles.
The gap between the idea and the value presented to customers needs to be as short as possible. Heavy processing doesn’t help that. A shared language is lightweight, carries meaning, and outlasts any individual.
Conclusion
Senior designers ship great features.
Staff designers help the product make sense as a whole.
Principal designers look at the system behind the problems.
Every company has different job levels, so my advice when assessing companies to work for and how to level up is to focus on the outcomes they require rather than the title.
Job titles do not matter; the work does. Many design teams are quietly dropping titles. They are moving to everyone just being “Designer” externally, but keeping internal levelling.
A few reasons I see:
Teams want flatter structures, so decisions move faster and less energy goes into company politics.
Scope and impact now matter more than titles. AI is blurring roles so fast. Someone with 3 years of experience might know more about AI than someone with 20+.
To focus on hiring designers focused on just the work, and obsessing about the craft of design.
When looking at jobs, focus on the work, not the title.
Until next time!
Great read, thanks Tom! Nice to see the Zalando perspective. Couldn't agree more with Thiago; spot on with all his thoughts.