One of the oldest debates in design career advice: should you do a little of everything, or go deep on one thing? The question sounds simple. The answer is more interesting than most people make it.
The short version: T-shaped. Wide enough to collaborate across disciplines, deep enough to be genuinely useful in at least one. But the T model has been misunderstood in ways that lead designers to make poor career decisions — and it's almost never accompanied by the practical step that matters most: figuring out what your T actually looks like right now.
Why the extremes both fail
A pure generalist — someone who can do branding, UX, motion, front-end, and illustration at roughly the same level — sounds versatile. In practice, they're competing in every category against people who do only that thing. The work gets commoditized. Hiring managers struggle to place them. The portfolio looks scattered.
A pure specialist — someone who does, say, only design tokens — has real depth. But they're dependent on the right team configuration to exist. They can get typecast. When the field shifts, they have limited surface area to pivot from.
The T model threads this needle: broad awareness across disciplines, genuine expertise in one. Enough breadth to understand problems upstream and downstream of your work. Enough depth that your specific contribution is hard to replace.
But knowing the model and using the model are different things. The useful question isn't "should I be T-shaped?" — it's "what does my T look like today, and is it the shape I want?"
Map your own T
Before you can grow deliberately, you need to see your current shape honestly. Here's a way to do that.
Start with the skill areas that matter in your corner of design. These will differ depending on your role and ambitions, but here's a starting set that covers most product and systems design work:
- Visual design — layout, color, typography, hierarchy, polish
- Interaction design — flows, states, micro-interactions, prototyping
- User research — interview design, synthesis, usability testing, insight framing
- Information architecture — structure, navigation, taxonomy, content modeling
- Design systems — tokens, component architecture, documentation, governance
- Accessibility — WCAG, assistive tech, inclusive patterns, auditing
- Front-end implementation — HTML/CSS, component code, design-to-dev workflows
- Motion & animation — transitions, easing, motion semantics, performance
- Strategy & communication — stakeholder management, presenting work, measuring impact
For each one, be honest about where you sit:
- No exposure — you haven't worked in this area
- Awareness — you understand the vocabulary and can follow a conversation
- Working knowledge — you can contribute, but you're leaning on templates, tutorials, or more experienced teammates
- Practiced — you can do this independently and make judgment calls
- Deep — you have genuine opinions, can teach it, can critique others' work, can spot what's missing before it's obvious
When you map this out, you'll see your shape. Most designers find one or two areas at "practiced" or "deep," several at "working knowledge," and a few at "awareness" or below. That's normal. The question is whether the shape matches where you want to go.
A designer aiming for a design systems role who has deep visual design skills but only awareness-level knowledge of tokens and component architecture now has a specific, actionable gap. That's not a failure — it's a map.
What the vertical is actually for
Most career advice frames specialization as a positioning move — "pick a niche, charge more." For designers on career paths inside organizations, depth serves a different purpose.
Your vertical gives you a frame of reference. When you go deep in one area, you develop taste — the ability to tell good from bad, to recognize patterns, to spot what's missing. That taste doesn't stay contained to your specialty. It becomes the lens through which you evaluate everything else.
A designer who has gone deep on design systems looks at a UX flow and immediately sees the token implications, the component boundary questions, the governance overhead. A designer who has gone deep on accessibility looks at a component spec and sees the interaction model gaps before anyone writes a line of code. Depth in one area sharpens vision across many.
This is why the vertical matters for career advancement. Senior and staff designers are expected to have a point of view — not just skills. That point of view comes from having gone far enough in something to have genuine opinions about it, opinions grounded in hard experience rather than best practices borrowed from a blog post.
When you did the mapping exercise above, look at whatever you marked "deep" or "practiced." That's your current vertical. Does it feel like the right one? Is it the area where you want to be the person others come to with hard questions? If not, your next career move might be less about leveling up and more about re-rooting your vertical in the right place.
Using gaps as a compass, not a critique
Once you see your shape, the natural impulse is to look at the low areas and feel behind. Resist that. Gaps are information, not indictments.
In fact, recognizing a gap is itself a sign of growth. If you look at someone's token architecture and think "that's better than what I could build, and I can see specifically why" — your taste has outpaced your skill in that area. That tension is the most productive place to be. It means you can see the target.
The key is turning vague gaps into specific ones:
| Vague gap | Specific gap |
|---|---|
| "I'm not great at design systems" | "I can build components but I've never structured a token architecture from scratch" |
| "I need to learn research" | "I can run a usability test from a script, but I can't design an interview guide or synthesize findings into themes" |
| "I should know more about accessibility" | "I understand color contrast and alt text, but I don't know how screen readers interact with custom components" |
| "I want to be more technical" | "I can read React code but I can't build a component from a spec without significant help" |
The specific version tells you what to learn next. The vague version just makes you feel inadequate. Every skill gap becomes a learning objective when you name it precisely enough.
The horizontal isn't just awareness — it's transfer
The breadth of the T is often treated as a checklist: know a little UX, a little branding, a little motion. But the more powerful mental model is domain transfer — the ability to move structural patterns from one field to another.
A weak version of this looks like surface analogy: "I read something about mental models in psychology, maybe I'll apply that to design." Useful. But the stronger version is structural: identify the underlying mechanism in one system, then find where that same mechanism operates in another.
Consider a few examples at designer scale:
| Domain you know | Mechanism you extract | Where it transfers in design |
|---|---|---|
| Typography | Hierarchy creates reading order through contrast, not just size | Component information hierarchy, dashboard layout, navigation priority |
| Design tokens | Indirection decouples intent from value — the name carries meaning, the value can change | Content strategy, API naming, any system where labels outlive their underlying data |
| User research | Surface assumptions before building solutions, not during | Stakeholder alignment, brief writing, any project with ambiguous requirements |
| Animation | Easing curves communicate physics and intention — ease-out feels natural because things decelerate in the real world | Data visualization, micro-interaction feedback, brand expressiveness |
The analogy doesn't need to be perfect. The value is in the practice: what is the underlying mechanism here, and where else does that mechanism operate? Designers who ask this question regularly build a mental library of transferable patterns that compounds over a career.
This connects directly back to your self-mapping. The areas you marked "awareness" or "working knowledge" aren't just gaps — they're potential sources of transfer. Every new area you explore, even shallowly, gives you one more domain to draw structural analogies from. Breadth isn't just about being employable. It's about having more raw material for insight.
How to grow your T deliberately
The horizontal develops naturally if you stay curious and collaborative. The vertical requires deliberate practice. Here's what that looks like at different stages.
If you're early career (building the horizontal)
Your job right now is to explore broadly and notice what clicks. Take on different types of work. Pay attention to what you lose track of time doing. That's signal.
Do the mapping exercise every six months. Watch which areas drift upward naturally and which ones you actively avoid. Both are useful data. The areas you avoid might be gaps worth closing — or they might be telling you something honest about where your energy goes.
If you're mid-career (deepening the vertical)
Go past the tutorial level in your area. Most designers have tutorial-level knowledge across many things. Depth means getting past the point where everything is explained to you — reading the actual specs, studying the edge cases, doing work that doesn't have a walkthrough. When you can teach the thing, debug it without documentation, and have opinions about where the conventional advice is wrong, you're getting somewhere.
Teach what you're learning. Explaining a concept to someone unfamiliar with it is one of the fastest ways to find gaps in your own understanding. If you can't explain why tokens use three tiers without looking it up, you don't know it yet — you just recognize it.
Do structured skill gapping. Find work you admire in your specialty and identify specifically what they did that you couldn't do yet. Not "their work is better" — that's taste without analysis. "They built a semantic color system that supports three themes from one token set, which I haven't done before" — that's a specific gap you can close.
If you're senior or staff (developing the second vertical)
At this level, the model often evolves into something closer to a π shape — two verticals connected by a wide horizontal. Deep expertise in a second area that complements the first. A design systems specialist who also went deep on accessibility. A product designer who developed genuine depth in research methods.
The second vertical isn't redundant — it creates new surface area for domain transfer, and it's often what distinguishes a senior contributor from a staff one. Re-run the mapping exercise and look for the area at "working knowledge" that you rely on most in your current role. That's usually where the second vertical wants to grow.
Practice forced structural mapping. Pick two systems you know and force a comparison. What do version control and design critique share structurally? Both create a record of decisions separated from the artifact, so the reasoning is recoverable later. What do grid systems and information architecture have in common? Both impose structure that users never see directly but always feel. This exercise trains pattern recognition independent of domain vocabulary — and it's the skill that makes senior contributors seem like they "just see things" that others don't.
The practical filter
When evaluating a role, a project, or a learning investment, your T-map gives you a filter:
- Does this deepen my vertical? Will I develop genuine expertise, or is this work I already know how to do?
- Does this expand my horizontal? Will I learn to collaborate with a new discipline, or understand a new domain's underlying logic?
- Does this close a named gap? Can I point to a specific skill gap this will address?
- Does this enable transfer? Is there something structurally interesting here that could make me better at something seemingly unrelated?
Work that does none of these isn't bad — but it's not growing you. Work that does two or three at once is rare and worth seeking out.
The generalist vs. specialist debate is a false binary. The real question is: what shape are you building, and are you building it deliberately? Map your T. Name your gaps. Choose where to go deep. The shape you have today isn't the shape you're stuck with — it's just the shape you've built so far.