Hiring Leveling Systems in Design: Building Frameworks That Actually Work | Paths.Design

If you manage a design team of any size, you will eventually face a question that sounds simple but is deceptively hard to answer: what does "senior" mean here? Not in the abstract. Not on a job posting. What does it mean on your team, in your organization, for the people who report to you? If you cannot answer that question with specificity and consistency, you have a leveling problem. And leveling problems metastasize. They show up as compensation inequity, promotion frustration, inconsistent hiring decisions, and attrition among your strongest contributors.

I have built and inherited leveling systems across organizations of different sizes and maturities. The pattern is remarkably consistent: teams that invest in clear, well-calibrated leveling frameworks retain better, hire more consistently, and have fewer painful surprises during performance reviews. Teams that wing it accumulate friction until something breaks, usually a valued designer walking out the door because they could not see a path forward.

This article walks through how major technology companies structure design levels, what competency dimensions matter most, how to build your own leveling system without over-engineering it, and the most common mistakes that undermine the whole effort. The audience is design managers and leads who are either building a framework from scratch or improving one that is not working.

Why Leveling Systems Matter

A leveling system is not bureaucracy for its own sake. It is infrastructure that serves four critical functions, and when any one of them breaks down, the consequences are immediate.

Calibration. Without a shared framework, "senior designer" means whatever the last hiring manager decided it meant. One team's senior is another team's mid-level. This is not a theoretical problem. It creates real resentment when designers at the same level on different teams have wildly different expectations, autonomy, and scope. Calibration ensures that level titles carry consistent meaning across the organization.

Career clarity. Designers need to know what growth looks like. Not vague assurances that they are "doing great" or that promotion is "on the horizon," but concrete descriptions of what the next level requires. What does a senior designer do that a mid-level designer does not? What does a staff designer own that a senior designer does not? When these questions have clear answers, people can direct their own development. When they do not, people either stagnate or leave to find clarity elsewhere.

Hiring consistency. Every interview loop that operates without a shared rubric is making independent, uncoordinated judgments about candidate quality. One interviewer values craft execution. Another values strategic thinking. A third focuses on collaboration skills. Without leveling criteria that map to interview signals, you end up with hiring decisions that reflect interviewer preferences rather than organizational needs. A leveling framework gives your interview panel a shared language for evaluating candidates against the same bar.

Compensation equity. Levels tied to pay bands are the primary mechanism for ensuring that people doing equivalent work receive equivalent pay. Without this linkage, compensation decisions drift toward whoever negotiated hardest at offer time, which systematically disadvantages underrepresented groups. A well-maintained leveling system with transparent pay bands is not just good management. It is an equity imperative.

How Major Companies Structure Design Levels

There is no industry-wide standard for design leveling. Each company structures levels around its own culture, organizational shape, and values. But studying how large technology companies handle leveling reveals common patterns worth understanding, even if you ultimately build something different. The frameworks below are based on publicly available information, published career ladders, and well-documented industry knowledge.

Microsoft

Microsoft uses a numeric individual contributor (IC) track that typically spans IC2 through IC6 for design roles, though the most commonly discussed range is IC2 through IC5. The levels map roughly as follows:

IC2 (Designer) — Entry-to-early-career. Works on well-scoped problems within a feature area. Receives regular direction and mentorship. Focuses on developing craft fundamentals and learning team processes.
IC3 (Senior Designer) — Independently handles complex feature-level design work. Begins influencing design direction within their product area. Expected to mentor IC2 designers and contribute to team practices.
IC4 (Principal Designer) — Owns design direction across a product or a significant product area. Drives cross-team alignment on design strategy. Expected to influence engineering and product management decisions, not just execute within design.
IC5 (Partner-level Designer) — Sets design vision across multiple products or an entire organization. Shapes the company's design culture and practices. This level is rare and typically requires industry-recognized impact.

The defining characteristic of Microsoft's leveling approach is its emphasis on scope expansion. Each level increase corresponds to a meaningful jump in the breadth and complexity of problems a designer is expected to own. The question at each transition is not "are they doing their current job well?" but "are they consistently operating at the scope of the next level?"

Google

Google uses a numeric system that begins at L3 for most design hires and extends to L7 and beyond for the most senior individual contributors:

L3 (UX Designer) — Early career. Executes design work within defined problem spaces under guidance from senior designers.
L4 (Senior UX Designer) — Independently drives design for a product area. Delivers high-quality work with minimal oversight and begins mentoring others.
L5 (Staff UX Designer) — Leads design strategy across multiple product surfaces or a complex product area. Expected to resolve ambiguous, cross-functional problems.
L6 (Principal UX Designer) — Defines design direction for a large product organization. Influences company-wide design standards and practices.
L7 (Distinguished UX Designer) — Extremely rare. Sets the design agenda at an organizational or industry level. Recognized as an authority within and outside the company.

Google's system puts heavy emphasis on ambiguity tolerance at senior levels. The transition from L4 to L5 is often described as the hardest in the system because it requires a shift from executing well-defined work to identifying and framing the right problems to solve. At L5 and above, designers are expected to operate effectively when the problem space, the stakeholder landscape, and the success criteria are all unclear.

Amazon

Amazon applies its broader job-level framework to design roles, with levels typically ranging from L4 to L7:

L4 (Designer) — Entry-to-early-career design work. Scoped tasks with clear requirements.
L5 (Designer) — Independent contributor handling feature-level design across a product.
L6 (Senior Designer) — Owns design for a product area. Expected to drive decisions and influence cross-functional partners.
L7 (Principal Designer) — Organizational-level design leadership. Shapes design practices and strategy across business units.

What distinguishes Amazon's approach is that design evaluation criteria are heavily influenced by the company's Leadership Principles. Designers are not only assessed on craft and scope but on behaviors like Customer Obsession, Ownership, Bias for Action, and Earn Trust. This means two designers with identical craft skills and identical scope might receive different level assessments based on how they demonstrate these behavioral principles. Whether you agree with this approach or not, it is worth studying because it illustrates how organizational values can be embedded directly into leveling criteria.

Common Competency Dimensions Across Frameworks

Despite differences in structure and naming, these companies converge on a set of competency dimensions that define what changes between levels. Understanding these dimensions is more useful than memorizing any single company's level names, because they translate to any organizational context.

Craft Quality

This is the most intuitive dimension: how good is the work? At junior levels, craft quality means executing visual design, interaction design, or research to an acceptable standard with feedback and iteration. At senior levels, it means producing work that sets the standard for quality on the team and that less experienced designers learn from. At staff and principal levels, craft quality is assumed, and the focus shifts to elevating craft standards across the organization.

A common mistake in leveling systems is making craft quality the only dimension. This creates a system where promotion is essentially "do the same work, but better," which caps out quickly. The strongest frameworks use craft quality as a necessary-but-not-sufficient condition for advancement.

Scope of Work

Scope is the dimension that increases most obviously between levels. It follows a predictable progression:

Feature scope — Designing within a well-defined feature area. "I own the settings page."
Product scope — Owning design across an entire product or product area. "I own the consumer experience."
Organization scope — Influencing design direction across multiple products or teams. "I shape how we approach design across the platform."
Industry scope — Defining practices that influence the broader design discipline. "I set standards that other companies learn from."

The key insight about scope is that it is not just about the size of the problem. It is about the complexity of the stakeholder landscape, the ambiguity of the problem space, and the number of competing priorities that must be navigated. A designer operating at product scope is not just designing more screens. They are making tradeoffs across competing user needs, coordinating with multiple engineering teams, and aligning with product strategy in ways that feature-scoped work does not require.

Autonomy and Direction

This dimension tracks the shift from receiving direction to providing it:

Directed — Works on tasks that are defined and scoped by others. Receives regular check-ins and feedback. This is not a negative quality. It is the appropriate mode for someone building foundational skills.
Independent — Identifies and scopes their own work within a defined problem space. Seeks feedback proactively but does not require it to make progress.
Directing others — Defines the problem space for other designers. Sets the direction, delegates effectively, and ensures quality without doing all the work themselves.

The transition from independent to directing others is where many strong IC designers struggle, because it requires a fundamentally different relationship with the work. Your value is no longer measured by what you produce personally. It is measured by what you enable others to produce.

Communication and Influence

At junior levels, communication means clearly presenting your own work and rationale. At mid levels, it means persuading cross-functional partners and stakeholders. At senior levels, it means shaping organizational narratives and building alignment across groups that may have competing priorities.

Influence is the mechanism through which senior designers create impact beyond their direct output. A staff designer who identifies a systemic usability problem and builds organizational will to fix it is exercising influence. A principal designer who redefines how the company thinks about accessibility is exercising influence at an even broader scale. If your leveling system does not account for communication and influence, it will systematically undervalue the work that your most senior designers do.

Mentorship and Team Development

At mid levels, mentorship means helping junior designers improve their craft. At senior levels, it means developing other designers' careers, not just their skills. At staff and principal levels, it means building the team's overall capability and culture, creating an environment where designers at all levels can do their best work.

This dimension is especially important for the IC track, because it provides a mechanism for senior ICs to create multiplied impact without becoming people managers. A staff designer who elevates the capabilities of five other designers is creating more total impact than they could ever create through their own individual output.

Building Your Own Leveling System

The frameworks above are useful as reference points, but you should not copy them directly. A startup with eight designers has different needs than a company with eight hundred. The goal is to build a system that fits your organization's current size and complexity, with enough structure to be useful and enough flexibility to evolve.

Start with Three to Four Levels

The most common over-engineering mistake is creating too many levels too early. If you have fewer than twenty designers, three or four levels are sufficient: junior, mid, senior, and possibly staff or lead. Each additional level requires clear differentiation from adjacent levels, and if you cannot articulate what meaningfully separates Level 4 from Level 5 in your organization, you do not need both.

Companies like Google and Meta have seven or more levels because they employ thousands of designers across hundreds of products and need fine-grained differentiation for compensation, promotion velocity, and organizational hierarchy. If that is not your situation, a simpler system will serve you better. You can always add levels as the organization grows. Removing levels once people hold those titles is far more painful.

Define Levels with Observable Behaviors, Not Vague Traits

This is the single most important principle for building a system that actually works. Every level description should be anchored in behaviors that can be observed, evaluated, and discussed with concrete evidence.

Bad: "Senior designers demonstrate strong strategic thinking."

Good: "At the senior level, a designer independently identifies the highest-impact problem to solve within their product area, frames it for cross-functional alignment, and drives the design direction without requiring their manager to define the scope or approach."

Bad: "Staff designers show exceptional craft."

Good: "At the staff level, a designer's work consistently sets the quality bar that others on the team reference. They proactively identify and address systemic craft issues, such as inconsistent interaction patterns or accessibility gaps, across multiple product surfaces."

The test is simple: could two reasonable managers read this level description and agree on whether a given designer meets it? If the answer is no, the description is too vague. Rewrite it with specific, observable behaviors.

Calibrate with Real Examples

Level descriptions on paper are necessary but not sufficient. The descriptions come alive when you calibrate them against real people and real work. This does not mean publicly ranking your team. It means that you, as a manager or leadership group, can point to concrete examples of what each level looks like in practice.

"At Level 3 on our team, a designer would handle a project like the recent dashboard redesign: well-scoped problem, clear success metrics, collaboration with one engineering team, delivered with minimal direction from their lead."

"At Level 4, a designer would handle something like the cross-platform navigation overhaul: ambiguous problem space, multiple stakeholder groups with competing priorities, required identifying the right approach and building alignment before any design work began."

These examples create shared understanding that abstract descriptions cannot. When you run calibration sessions during performance reviews, having these reference points prevents the conversation from dissolving into subjective debates about what "strategic" means.

Establish Separate IC and Management Tracks

One of the most consequential structural decisions in a leveling system is whether to create distinct tracks for individual contributors and managers. The answer should almost always be yes.

Without separate tracks, the only path to higher levels is management. This forces your best designers into people management roles they may not want and may not be suited for, and it drains your team of the senior IC talent that elevates craft quality and design standards. The result is a management layer staffed by reluctant managers and a design team without senior role models.

A dual-track system lets designers advance as far as they want on either path. The IC track rewards deepening craft, expanding technical scope, and increasing organizational influence through design excellence. The management track rewards people development, team building, organizational strategy, and operational leadership. Both tracks should have equivalent levels, equivalent compensation, and equivalent organizational respect.

The hard part is making the IC track feel real, not like a consolation prize. This means staff and principal IC designers need genuine scope, genuine influence, and genuine recognition. If your staff IC designers are still being assigned work by mid-level managers and have no voice in organizational strategy, you have a dual-track system on paper and a single-track system in practice.

Review and Update Annually

A leveling framework is a living document, not a constitution. Review it at least once a year to ensure it still reflects how the organization actually works. As the team grows, as the product matures, as the company's expectations evolve, the leveling system needs to evolve with it.

Annual reviews should involve calibration sessions where managers discuss whether current level descriptions match the actual bar being applied. If every promotion case for the past year required caveats and exceptions to the framework, the framework needs updating. If the team has grown from twenty to sixty designers, you may need to add a level or split an existing one. If the company shifted from a product-focused to a platform-focused strategy, scope expectations at senior levels may need to be reframed.

Building Hiring Rubrics That Map to Levels

A leveling system that only applies to your existing team is doing half the job. The same framework should inform how you evaluate candidates during the hiring process.

Start by identifying which competency dimensions are evaluable in an interview setting. Craft quality is straightforward to assess through portfolio review and design exercises. Scope of work is assessable through behavioral interviews about past projects. Communication is observable in real time during presentations and discussions. Mentorship and team development are harder to assess in interviews but can be probed through structured behavioral questions.

For each competency dimension, define what you expect to see at the level you are hiring for. If you are hiring a senior designer (your Level 3), you should know exactly what "senior-level craft" looks like in a portfolio review, what "senior-level scope" sounds like in a behavioral interview, and what "senior-level communication" looks like in a cross-functional collaboration exercise.

Build an interview rubric that maps directly to these expectations. Each interviewer should assess specific dimensions, not just give a general thumbs up or thumbs down. After the interview loop, the debrief discussion should be structured around the rubric: "Did the candidate demonstrate Level 3 craft? Level 3 scope? Level 3 communication?" This creates a disciplined evaluation process that reduces bias and increases consistency.

One practical technique that improves hiring accuracy: write "bar descriptions" for each level in the interview context. These describe the minimum signal you need to see for a candidate to be considered at that level. For example: "To be considered at Level 3 (Senior), the candidate's portfolio must include at least one project where they owned the end-to-end design for a product area, not just individual features. They must be able to articulate the tradeoffs they made, the stakeholders they aligned, and the outcomes the work produced." These bar descriptions give your interview panel a concrete standard rather than relying on gut feeling.

Common Pitfalls

I have seen the same mistakes across dozens of organizations. They are predictable, and most of them are preventable if you know what to watch for.

Levels That Reward Tenure Instead of Demonstrated Skill

The most corrosive version of this is the implicit expectation that anyone who stays long enough will eventually be promoted. This turns leveling into a seniority system, which demoralizes high performers who are growing fast and rewards mediocrity with patience. Time in role is a prerequisite for developing skills, but it is not evidence that the skills have developed. Your leveling system should promote on demonstrated capability, not calendar time.

A related failure mode is "loyalty promotion," where you promote someone because they have been on the team for years and you are afraid of losing them. This creates a level mismatch where the person has the title but not the capability, which causes calibration problems for the entire team. If someone has been at the same level for years, the right response is an honest development conversation, not a hollow promotion.

No Distinction Between IC and Management Tracks

We covered this earlier, but it bears repeating because of how common and how damaging this mistake is. If your leveling system implies that the only way to advance past senior is to become a manager, you will lose your best senior ICs. They will leave for organizations that offer a real IC leadership track. And you will end up with managers who became managers not because they wanted to lead people but because it was the only available path to higher compensation and scope.

Leveling Inflation

Leveling inflation occurs when you promote people to retain them rather than because they have grown into the next level. The short-term benefit is obvious: the person stays, and they feel valued. The long-term cost is severe. It devalues the level for everyone who earned it legitimately, creates calibration chaos when you try to compare across teams, and sets up the inflated individual for failure when they are held to expectations they were never actually ready to meet.

If you are promoting to retain, you have a compensation problem, not a leveling problem. The solution is to widen pay bands within levels so you can reward strong performance without misrepresenting someone's scope and expectations. Many companies address this with "senior" and "distinguished" sub-bands within a single level, allowing meaningful compensation growth without title inflation.

Not Communicating the System to the Team

A leveling system that lives in a manager's private document is not a leveling system. It is a secret. If your designers do not know what their current level means, what the next level requires, and how they will be evaluated for promotion, the system is not serving its purpose. Transparency is not optional. Publish the framework. Walk through it with each person on your team. Use it explicitly in performance reviews and career development conversations. Let people ask questions and push back on criteria they find unclear.

The most common objection to transparency is "but people will just game the criteria." This concern is backwards. If your criteria can be gamed, they are bad criteria. Observable behaviors grounded in real work are hard to game. Vague traits like "demonstrates leadership" are easy to game. Fix the criteria, then publish them.

Applying One Framework Across Incompatible Disciplines

Design is not a monolith. A leveling system that works for product designers may not map cleanly to content designers, UX researchers, design technologists, or design program managers. Each discipline has different core competencies, different scope models, and different ways of creating impact. Forcing all design disciplines through the same rubric leads to awkward evaluations where half the criteria do not apply.

The solution is to share the competency dimensions (craft, scope, autonomy, communication, mentorship) across disciplines but define the specific behaviors and expectations for each discipline independently. "Craft quality" means something different for a UX researcher than for a visual designer. "Scope" looks different for a design systems engineer than for a product designer. Build the shared skeleton, then flesh it out per discipline.

Making It Stick: Embedding Leveling in Daily Practice

A leveling framework has no value if it only comes out during promotion discussions. The organizations that get the most out of their frameworks integrate them into regular management practice.

Use the framework in every one-on-one career conversation. When a designer asks "what do I need to do to get promoted?" you should be able to point to specific competency dimensions, identify where they are currently performing, and describe the gap between their current level and the next one. This turns a vague, anxiety-producing question into a concrete, actionable development plan.

Use the framework in design critiques and project retrospectives. When reviewing work, explicitly connect your feedback to leveling expectations. "This work demonstrates senior-level craft, and the way you navigated the ambiguity in the problem space is exactly what we look for at the staff level for the scope dimension." This reinforces the framework as a living tool, not a bureaucratic artifact.

Use the framework in calibration sessions with your management peers. When multiple managers discuss their teams against the same framework, inconsistencies surface quickly. "Your IC4 is doing work that looks like our IC3" is a useful and necessary conversation to have. Calibration sessions are uncomfortable, but they are the primary mechanism for maintaining the integrity of the system.

Run promotion packets through the framework explicitly. A promotion case should map the candidate's demonstrated behaviors to the competency dimensions at the proposed level. If you cannot provide specific evidence for each dimension, the case is not ready. This discipline prevents both premature promotions and promotions based on likability rather than capability.

Getting Started

If you do not have a leveling framework today, do not try to build the complete system in one pass. Start with three actions.

First, define your levels. Three or four, with a one-paragraph description of each. Focus on scope and autonomy as your primary differentiators, because those are the dimensions that create the clearest separation between levels.

Second, write observable behaviors for each level across two or three competency dimensions. Start with craft quality and scope of work, because those are the easiest to define concretely. Add communication and mentorship once the foundation is stable.

Third, calibrate against your current team. Walk through your roster with a peer manager or your own manager and see if the framework produces sensible results. If it does not, revise the framework. If it does, you have a working first version.

Resist the temptation to borrow a framework wholesale from a company whose blog post you admired. Their framework was built for their organizational context, their compensation structure, and their cultural values. Yours needs to be built for yours. Study their approach, learn from their principles, but write your own descriptions in your own language for your own team.

The goal is not perfection. The goal is clarity. A simple, well-communicated framework that your team understands and trusts is worth more than an elaborate one that lives in a document nobody reads. Start simple, calibrate regularly, and iterate based on what you learn. Your designers, your candidates, and your organization will be better for it.

HiringLevelingSystemsinDesign:BuildingFrameworksThatActuallyWork