Hero — the leveling framework
Обложка/ключевой слайд из дека (двойной трек или титул «UX/UI & Product Designer Leveling»). Экспорт PNG/WEBP из презентации — она уже на бренде JATAPP.
When I joined JATAPP there was no design department — just five or six designers, each attached to a product unit, with no shared structure, standards, or knowledge base. As Head of Design I built the function end to end: a 20+ designer org across product, creative, and AI, the leadership to run it, and a career-leveling system — a shared knowledge base that defines every level and how designers grow through it.
By the time I left, that structure was the company's — and the same leveling matrices had spread beyond design into several other roles.
- Role
- Head of Design
- Team
- 6 → 20+ designers
- Scope
- Org · knowledge base · leveling
- Adopted by
- Design + 4 more roles
Where it started: no department, just designers
When I came in, design wasn't a function — it was five or six designers, each attached to a product unit, doing good work in isolation. No structure, no shared standards, no knowledge base, and no path for anyone to grow. “Senior” meant something different to everyone; promotions were a negotiation, not a decision.
The job was to turn that into a real design organisation — a structure that scales, and a shared language for scope, autonomy, and impact, so growth is about evidence, not persuasion.
First, the org
The scattered designers became a real organisation. I grew it to a 20+ designer org spanning product, creative, and AI — embedded across five product lines — then split it into leadership areas and handed the day-to-day to leads: a Lead Product Designer over the product designers, a Project Manager over the creative studio (UI, motion, graphic, ASO), and an AI lead for a new AI-creative vertical.
- Product Designers
- 8
- UI Designers
- 2+1
- Motion UI
- 1
- Illustration
- 1
- Graphic — Brand
- 1+1
- Graphic — ASO
- 1
- AI Lead
- 1
- AI Creator
- 1
That let me own the things a Head of Design should — strategy, the quality bar, and the business relationship — while the leads ran the day-to-day. Here's who owned what:
- Design strategy and the quality bar across Product, UI, Brand, ASO, and AI
- Built the function — structure, roles, growth paths — and set up leadership areas, handing the day-to-day to leads
- Represented design with the CEO, product, marketing, and engineering; tied design to company goals
- Set up team-wide metrics — quality, load, effectiveness
- Runs the product designers — priorities, hiring, onboarding, growth plans, 1:1s, Performance Review
- Owns product-design quality and the design system
- Builds and maintains the competency matrix — and assigns levels from it
- Runs the non-product designers — UI, motion, graphic, ASO
- Takes in tasks, plans, and balances workload; the single place design requests come in
- Co-owns the competency matrix for UI, brand, and ASO designers
One detail matters for what comes next: both leads co-own a competency matrix — they use it to assign levels, review, and hire. That matrix is the framework I built to make growth fair across the whole org.
Two tracks, not one ladder
UX/UI and Product Designer aren't separate roles — they're one path that forks. The craft track rewards depth in UI quality and design systems; the product track adds an active role in product decisions. Each product level is built on top of a UX/UI level, so moving across is a change of direction, never a step down.
Works to a clear brief, under guidance
Owns a feature, requirements → handoff
Sets design standards, mentors
Thinks in product — starts from “why”
Hypotheses + metrics
Product strategy, partners with PM
The knowledge base: a leveling framework
This is the knowledge base the team never had — one place that documents what every level means and what each competency looks like in practice. Every level is described across the same categories. Each competency is either CORE — required, the level is impossible without it — or OPT, a bonus. Product Mindset is the category that defines the product track.
Craft, UI/UX, design systems, tooling & AI
Working with the team and stakeholders
Responsibility for the outcome
Effect on the product, team, and processes
Metrics, hypotheses, business context
The matrix isn't a checklist where you “score 8 of 10.” It describes the patterns of behaviour, results, and autonomy for a level. You move up when you consistently show the next level's CORE expectations — judged on scope, autonomy, consistency, and knowledge — not on a perfect 100% match.
One category, across levels
To give you a feel for it — here's a single category, Ownership, across the three UX/UI levels. Every category is written out this way, for both tracks.
Executes assigned design tasks under guidance — clarifies requirements, follows priorities, gives regular updates.
Owns a feature from requirements to final delivery with minimal guidance — breaks work into steps, aligns with PMs and devs, flags risks early.
Owns design expertise within the team — sets standards, enforces them across the team, detects UX/UI risks early and proposes mitigations.
The full matrix
Скрин полной матрицы (категории × уровни, CORE/OPT) или несколько слайдов категорий из дека — показывает глубину проработки. Экспорт из презентации/таблицы.
The craft standards
The leveling matrix is one half of the knowledge base — how people grow. The other half is how the craft stays consistent: the design-system standards the team writes to and maintains. A couple are public to read:
Source docs are in Ukrainian
How an assessment runs
The framework is only as good as the conversation around it. Leveling runs as a four-step loop, kept separate from the fixed six-month review cycle so a level can come sooner — or take longer — when it should.
- 1Self-assessment
The designer goes through the matrix and marks each CORE and OPT skill as present or not, against a target level.
- 2Tech lead + Performance Review
The tech lead assesses hard skills against real work; the team gives soft-skill feedback through the Performance Review form.
- 3Calibration with the manager
The self-assessment is compared with the lead’s and team’s view. Where they disagree, they talk it through and agree.
- 4Set the level, build a growth plan
We set the current level and write a growth plan — focused on the CORE gaps that block the next level, not every line in the matrix.
Who decides
In a setup like this, a level can't be one person's call. Each role owns a clear part of the decision, and leveling is settled by People and Functional managers together.
| Role | Owns |
|---|---|
| People Manager | Overall results (impact, ownership), communication, values, and the unit’s business need |
| Functional Manager | Judges hard skills, plus an expert view on task level and whether the team needs that skill |
| HRP | Method, consistency, and recording the decision |
| Head / Dept Lead | Final sign-off when the wider function or business needs to agree |
And a rule I built in from the start: a level isn't a bribe to keep someone. A new level has to reflect real scope and impact, backed by a real business need — if the real ask is more pay, there are better answers than a title.
From six designers to a design function
I came into five or six designers with no structure. I left a design function: a 20+ org across three verticals, the leadership to run it, and a leveling system that gives every designer a clear, fair path to grow.
The clearest proof is what happened next. The structure outlived my time there — it's the design org the company runs today — and the leveling matrices spread beyond design into iOS, QA, product analytics, and marketing, wired into hiring scorecards and the performance cycle.