Table of contents
Most lists like this one get recycled in January. Same ten skills, slightly different wording, every year. This one reflects what actually shifted in the past twelve months and what I would hire for if I were rebuilding a design team today. The order is roughly the impact each has on day-to-day output, not what looks impressive on a CV.
1. Integrating AI into the design process
AI changed how I work in 2024. ChatGPT and Claude generate ideas and copy that fills mockups. DALL-E produces placeholder visuals when I do not have the real assets yet. The bigger shift came with Claude paired with v0: a written description becomes a working interactive prototype, not a static screen. For projects moving from Figma to production code, this collapses the most painful translation step.
What AI does well in design today:
- Generate placeholder content to fill mockups.
- Turn a written description into a clickable prototype with Claude and v0.
- Convert mockups to working code.
- Suggest copy variants for buttons, errors, and empty states.
What AI does badly: visual judgment, edge cases, anything that requires having watched a real user struggle. Generated UIs default to the average. The designer's job is recognizing when the model is being confidently mediocre and starting over with a different angle.
The workflow that has worked for me: write a one-paragraph problem statement, ask the AI for three approaches, throw out two, expand the third manually. The AI is fastest at producing options, slowest at choosing among them. Use it accordingly.
For more, read integrating AI into UX design.
2. Mastery of nocode tools
Webflow and Bubble let you ship a working prototype without writing code. That turns a one-month engineering ask into a one-week design exercise. I have used Webflow on early-stage projects to validate ideas with real users before mobilizing developers.
The tools have limits. Bubble gets expensive fast at scale. Webflow CMS hits walls when you need real relational data. Framer is great for landing pages and bad for anything stateful. None of them replace production engineering once a product needs to actually do work. Use them for the validation phase, not the build phase.
The trap is the team that ships the Webflow prototype to real customers and then never rebuilds. The site stays "temporarily" on the prototype stack for two years. Every nocode platform has a graveyard of products that grew up there and never escaped. Plan the migration before you start, not after the company depends on the prototype.
3. Product management skills
A designer who cannot prioritize is a wireframer. Understanding how features get cut, why timelines matter, and what makes a roadmap coherent puts you in the room when decisions are made. The designers I see making the most impact are the ones who speak the same language as a Product Manager.
The specific things to learn: how a PRD is structured, what an OKR actually constrains, how to read a JIRA backlog and know which items will ship and which will not, what a stakeholder map is, how product strategy decisions cascade into design constraints. Most designers absorb this by osmosis from working with PMs, which works but takes years.
The faster path is to read what PMs read. Inspired by Marty Cagan and Continuous Discovery Habits by Teresa Torres are the two books that show up most often in PM book clubs. Then sit in on PM rituals — sprint planning, roadmap reviews, OKR-setting — even when you do not strictly need to be there. Within six months you stop being someone who designs what the PM hands you and become someone the PM consults before deciding.
4. Design systems and scalability
A design system gives you consistency at scale and faster decisions on common patterns. For products with many surfaces, this frees the team to spend time on harder problems instead of debating button colors. The work is mostly maintenance, which is the part designers underestimate before they start one.
Common failure modes: tokens that drift from code, components nobody uses because they do not match what designers actually need, governance meetings that stretch on because nobody owns the system. The rule of thumb: a design system has a maintainer, or it dies. Half-time at small scale. Full-time at large scale. Less than that and the system rots inside six months.
When not to build one: solo designer, single product, fewer than five surfaces. The maintenance overhead exceeds the savings. A shared Figma library is enough. Build the system when you have multiple products, multiple designers, or both, and someone is willing to own it.
For more, read interface design principles.
5. Knowledge of psychology and cognitive science (UX skills)
Knowing how attention, memory, and cognitive load actually work beats memorizing UX laws. A flow that respects cognitive load survives reality. A flow that ignores it gets shortened in production by an engineer trying to make it fit on a phone.
The concepts that actually help in practice: working memory limits (about four chunks at a time, not seven, despite the cliché), recognition versus recall (always show options instead of asking the user to remember them), Hick's law (decision time grows with the number of options, but grouping into categories can cut it back), Fitt's law (target size and distance matter for any clickable element). These are not academic. They show up in every design review where someone says "this feels confusing" without being able to say why.
Most designers learn these poorly because the field cargo-cults them. People know the name "Hick's law" but cannot tell you when it applies and when it does not. Read the original sources when you can. Don Norman's The Design of Everyday Things, Steve Krug's Don't Make Me Think, and Susan Weinschenk's 100 Things Every Designer Needs to Know About People are the originals, not the second-hand summaries that float around Twitter.
6. Agility and continuous learning
The tools that mattered in 2022 are not the tools that matter in 2025. If your stack is not getting refreshed every six months, it is going stale. This is about reading and trying things in real projects, not collecting certificates from courses you never finish.
The sources I trust: Nielsen Norman Group for research-backed UX, Smashing Magazine for craft, The Pragmatic Engineer newsletter for the engineering side of how products get built, Amy Hoy for the business-and-design intersection. Avoid anything where the headline is "X tips for Y." That is exactly the article that made you read this list of ten in the first place.
Time-box the learning. One hour a week is enough if you read carefully. Five hours a week gets you ahead of most of the field. The trap is the designer who reads forty newsletters and never tries any of it. Pick two ideas a month, apply them on a real project, throw out the ones that do not help.
7. Ethical awareness and social responsibility
Design choices have consequences. Color contrast, plain language, the patterns you choose to use or refuse. WCAG conformance is the baseline.
The interesting work happens beyond the baseline: catching dark patterns before product asks for them, naming exclusions in research samples, pushing back on flows that exploit attention. The specific tools that help: axe DevTools and WAVE for automated accessibility checks, the W3C Authoring Tool Accessibility Guidelines for what manual review should cover, Privacy by Design as a framework for data flows. These are not optional in 2025 in any market with regulation, which is most of them now.
The harder skill is knowing what to refuse. Misleading default checkboxes. Forced subscription flows. Manipulative urgency timers. Auto-renewing trials with hidden cancel buttons. A designer who builds these is responsible for them. "It was the PM's idea" is not a defense in the EU. It will not be a defense anywhere within five years.
8. Strategic thinking and complex problem solving
Tactical design solves a screen. Strategic design decides which screens to build at all. The designers I see growing into senior roles are the ones who learn to push back on the brief, not the ones who execute it cleanly. A clear problem statement saves more design hours than any tool ever has.
The technique I use most: ask "what is the user actually trying to do?" five times in a row. The first answer is the feature request. The fifth is what the product is for. The gap between the two is where the strategic decisions live. If the team says "users want a notification settings page," the fifth-why answer might be "users do not trust us to email them only when it matters." Those are very different problems with very different design solutions.
Strategic thinking is also accepting that you will sometimes be wrong about which problem to solve, and getting faster at finding out. Write down the assumption, define what evidence would change your mind, then go look for that evidence. This is harder than it sounds. Most teams write down nothing and then argue about who was right after the fact.
9. Interdisciplinary collaboration
Design is not a solo activity. The output depends on the engineer who builds it, the PM who scoped it, and the researcher who tested it. Knowing enough about each role to ask useful questions is more valuable than being the best designer in the room.
That looks like listening to people with more context than you, translating constraints into design decisions instead of fighting them, writing things down because async is the default in most teams now, and owning the unglamorous parts nobody else will. The best solutions emerge at the intersection of these perspectives, deliberately, never by accident.
The unsexy part: most cross-team work is communication. A clear two-paragraph design doc beats a beautiful Figma file in 80% of cases. Engineers want to know the constraints, the edge cases, and what the data model looks like. Marketers want to know the launch story. PMs want the trade-offs spelled out. The customer support team wants to know what new tickets to expect. None of them want to scrub through frames hunting for the answer.
10. Adaptability to new technologies
AR, voice, agents, whatever is next. You do not need to chase every new technology, but you do need to recognize when something crosses into mainstream. The designers who got comfortable with mobile in 2010 were the ones who shipped breakout apps in 2012.
The pragmatic rule: pick one new technology a year and build something real with it. Not a tutorial. A small project that has to actually work. Some years the choice is obvious. AI agents in 2024 were impossible to ignore. Other years you have to bet, and you will sometimes bet wrong. The cost of betting wrong is a few weekends. The cost of betting on nothing is your skills aging out.
What to ignore: anything where the demo is the entire product. Crypto and web3 had this problem for years. Some AI tools have it now. If a tool is impressive in a thirty-second video and disappointing in a real workflow, skip. The real signal is whether teams ship products with it three years later, not whether the launch goes viral on Twitter.
If you only pick up two from this list this year, make it AI prototyping and product management literacy. Everything else builds on those two.
