When I joined JATAPP there was no design department. There were 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. I grew a 20+ designer org across product, creative, and AI, set up the leadership to run it, and wrote a career-leveling system. That last part is 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. 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 plus 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.
My 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 comes down to 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 I split it into leadership areas and handed the day-to-day to leads. A Lead Product Designer took the product designers, a Project Manager took the creative studio (UI, motion, graphic, ASO), and an AI lead took 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 own. 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. Set up the structure, roles, and growth paths, created leadership areas, and handed the day-to-day to leads
- Represented design with the CEO, product, marketing, and engineering, and tied design to company goals
- Set up team-wide metrics for quality, load, and 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 them, 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, and 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 sits on top of a UX/UI level, so moving across is a change of direction, never a step down.
Works to a clear brief, with guidance
Owns a feature, from requirements to handoff
Sets design standards, mentors others
Thinks in product, starts from “why”
Works with hypotheses and metrics
Owns 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, which is required and the level is impossible without it, or OPT, which is a bonus. Product Mindset is the category that defines the product track.
Craft, UI/UX, design systems, tooling, and AI
Working with the team and stakeholders
Owning the outcome
Effect on the product, team, and processes
Metrics, hypotheses, and 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. We judge that 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.
Does assigned design tasks with guidance. Clarifies requirements, follows priorities, and gives regular updates.
Owns a feature from requirements to final delivery with little guidance. Breaks work into steps, aligns with PMs and devs, and flags risks early.
Owns design expertise within the team. Sets standards and enforces them, spots UX/UI risks early, and proposes ways to handle them.
The full map
The same depth runs across the whole framework. Here is every dimension and what sits inside it, for both tracks.
Each area is written out per level and marked core or optional
The craft standards
The leveling matrix is one half of the knowledge base, the part about 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. That way 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
We compare the self-assessment with the lead’s and the team’s view. Where they disagree, we talk it through and agree.
- 4Set the level, build a growth plan
We set the current level and write a growth plan. It focuses 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 | Keeps the method consistent and records the decision |
| Head / Dept Lead | Final sign-off when the wider function or the 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.