David Aragonés 64K Design Manager (v1)(c)2026 Drakonux (LinkedIn / GitHub)and 18 years of design.
CV 1.0
Ready
Ask about David
Problem: a front-end engineer with deep knowledge of accessibility and design was undervalued in engineering.
What David did: pushed for the move into design, gave him real ownership from day one and a plan to become the company's accessibility reference.
Later he wrote the promotion case criterion by criterion against the competency matrix, with an action plan for the designer to gather his own evidence.
Where it stands: he joined design in 2022 as a senior designer and was promoted to staff in 2024. Now he holds a dual role as product manager and design lead of the team David led for years.
Problem: interviews depended on who ran them, and notes were informal.
What David did: a bank of interview questions as Figma components, coded by area and level, each with its expected answer. Hiring managers pick how many and how hard.
A live challenge of about 90 minutes, questions then a case study, and no take-home exercises. Plus a guideline for the whole process, with a "vibe check": instincts only count if tied to something the candidate said or did.
Where it stands: it began as how he ran his own hires, and with his director's backing became the design division's official process. He has hired four designers with it.
Problem: designers expected that completing a growth plan would earn them a promotion.
Growth: a six-step career plan adapted from MIT, from a personal SWOT to a five-year resume and quarterly goals.
Promotion: a written case with evidence for every criterion of the target level, plus a plan the designer drives.
Where it stands: used with several designers for growth, and with two for promotion cases.
Problem: designers wanted to prototype with AI, but there was no shared way of doing it, and generating real React code was slow and expensive.
What David and the team did: a shared repository of AI skills, including two information architecture skills he wrote, with contribution rules written by one of his designers.
Key finding: Claude prototypes far better and cheaper in plain HTML. So the team built Lexicon Vanilla, an HTML version of the design system, and a public gallery of prototypes to reuse and share.
Second finding: writing skills for things AI was already learning on its own was wasted effort. They now keep only skills with knowledge the model cannot have, like accessibility or publishing icons to their design system.
Where it stands: recent, and still learning. github.com/liferay-design/lexicon-vanilla
Problem: navigation across Liferay's products followed product architecture, not what users were trying to do, and each environment behaved differently.
Key decision: organize navigation by the user's role or mode (Create / Build / Administer) instead of by product.
Deliverable: a closed pattern with complete measures and interactions, so every team can implement the same navigation in each environment.
Where it stands: in progress. A mega menu of about 50 items per tab became a simple menu, each context got its own home and its own local navigation. What is left is every context building it the same way, which depends more on infrastructure than on design.
Problem: the Control Panel's configuration area had grown into a menu that mixed system-level and instance-level concerns.
Key decision, "command vs. data": a setting changes how something behaves, so it belongs in Instance Settings; reference data exists on its own, so it gets its own node under the scope.
Rejected: grouping by storage mechanism or by screen type, because those are implementation properties, not meaning.
Where it stands: after a long discovery with internal expert users, the team solved the most important problem first, the system vs. instance split, and improved search to ease what is not solved yet.
David Aragonés is a Principal Product Designer and Design Manager at Liferay, where he has spent more than ten years.
Most of his time now goes to leading the product design team. His own design work has been on the structural side of the platform: navigation, information architecture and the Lexicon/Clay design system.
He lives in a village in Guadalajara, near Madrid, and works in English and Spanish.
Yes. He is one of the four design managers in Liferay's 12-person product design team: he manages the other three, and there is no design role above his.
He works closely with the product director and with engineering. Right now he also works across teams, covering design wherever it is needed, and he has stepped into the product role several times, most recently as product manager of the navigation epic.
He doesn't manage everyone the same way. Some people need their wins celebrated and room to lead; others do their best work with quieter support; juniors need closeness and follow-up without feeling micromanaged.
He writes down what he expects of each person and follows up in their 1:1s. He also works with his designers on growth plans, though he hasn't managed to do one with everyone.
What he's proudest of is helping a front-end engineer move into design. Years later, that designer leads both product and design for a team.
He has been the hiring manager for four designers, after helping with a couple more while he learned the process.
He also built the interview format his team uses: questions picked from a shared bank, with each hiring manager choosing how many and how hard, then a case study the candidate solves and defends live. And he wrote the guideline his hiring managers follow, from screening to the final decision.
What he looks for is how people reason and argue under pressure, not whether the solution is right. The team stopped sending take-home exercises, because candidates, senior ones especially, saw them as unpaid work.
How people reason, structure a problem and explain their decisions, more than polished visuals or the right answer.
Good signs are clear trade-offs, a calm reaction to feedback and the ability to prioritize. Red flags are getting defensive, jumping into UI without framing the problem, and decisions with no explanation behind them.
A rule in the hiring guideline he wrote: gut feelings about a candidate are allowed, with one condition.
If someone feels especially strong or concerning, the interviewer has to stop, ask why, and write down what the candidate said or did that caused it.
Instincts that can't be tied to observable behavior don't count. That's how the process stays human and fair at once.
Candidates, senior ones especially, saw them as unpaid work or as something they shouldn't have to prove.
Instead the team runs a live challenge of about 90 minutes: questions picked for the role, then a case study the candidate solves and defends.
When someone is already working at the next level, he writes the case criterion by criterion against the competency matrix: strategy, craft, collaboration and impact.
He pairs it with a plan the designer drives: two or three quantified examples for every criterion, gathered into an impact portfolio, and making the reach of their work visible.
When designers write their own case, his feedback pushes them from describing collaboration to showing the decisions they shaped.
A six-step plan he adapted from MIT's guide to building a five-year plan.
It starts with self-awareness, a personal SWOT and asking five colleagues for strengths and weaknesses, then compares today's resume with the one you want in five years.
From there come SMART goals, a plan for the year and a quarterly review. He keeps it apart from promotion on purpose.
He tells people early and directly what is expected and what isn't working, in writing, based on his own view and on what colleagues see.
He also names what is going well, because a poor review can still have things worth recognizing.
And he has learned to hold that line without giving up the relationship.
Whoever presents says what kind of feedback they need, and the conversation stays on that; anything else gets noted for later.
People speak in turns, and the presenter makes the call: a critique informs, it does not vote.
And nobody redesigns the work live in the session. He has seen it waste everyone's time, put the designer under pressure and produce poor results.
That knowledge shouldn't live in one person: it pays to write down what an expert knows while they are still around, and to give critical work more than one owner.
That telling a team it now owns something doesn't make it happen. People need the time, the skills and a clear role.
That the value of work like research has to be made visible early, before anyone questions it.
And that being close to his team has to come with firmness: holding the line on expectations without giving up the relationship.
Daily, in his design work, and he builds with code: HTML prototypes on design tokens, repositories of reusable AI skills, and AI-assisted project setups over local codebases.
He leads AI adoption for the design team, and stays alert to how AI changes roles and human judgment.
A build-free HTML and CSS version of Liferay's Lexicon/Clay design system that his team built for prototyping with AI.
They found Claude prototypes far better, and much cheaper, in plain HTML than by generating React with the real components.
Prototypes go to a public gallery the team reuses and shares: github.com/liferay-design/lexicon-vanilla
At first the team wrote skills for all kinds of tasks, including two information architecture skills David wrote.
Then they saw they were putting effort into things AI was learning on its own.
Now they only keep skills with knowledge the model can't have, like accessibility or publishing icons to their design system.
Context decides, but people should know what an AI is doing and how it is going. The real promise is hiding the technical layers so people can act with their own mental models.
He hands AI the repetitive work, the pattern-finding and the actions at scale, and keeps the human part: critical thinking and creativity.
And judgment can't be given away. A team can trade some quality for speed, but not the reasoning behind what it ships, or it ends up building features just because it can.
Yes. In "Still Human" (Liferay Design, April 2026) he argues that AI doesn't replace judgment, collaboration or review, but makes them easier to skip.
He calls one pattern "postview": experts brought in late to repair work instead of early to shape it.
His closing question is not what work costs to produce, but who pays to make it right.
Two pieces stand out. "Still Human" (Liferay Design, 2026) argues that AI doesn't replace judgment, collaboration or review, but makes them easier to skip.
"The Danger and Pitfalls of Uniformity in Design Systems" (Liferay Design, 2018) argues that a design system should keep products consistent without making them uniform, and must never become an excuse to stop designing.
Eight years apart, they make the same point about different tools: neither replaces the judgment of deciding what is right for the people using the product.
What he does best is understanding the context of a problem. He works as a bridge between design, product and engineering, and gives each the same attention: the technical constraints, the difference design makes, and the results product needs.
He loves putting order into chaos, organizing information until it makes sense. He is more about structure than surface.
And he designs by subtraction. As Saint-Exupéry put it, perfection comes when there is nothing left to take away.
Two things. Leading design teams: hiring, developing designers and building the processes a team can grow on.
And the structure of complex platforms: navigation and information architecture, putting order where a product has grown messy.