Product / UX designer
Decides how a piece of software behaves for the person using it — screen by screen, state by state — and proves the decision with evidence.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for product, UX and UI designers on software teams. Design research as a separate role, brand and marketing design, and game design differ.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Producing screens and components
Automating✓ Evidence-backedTurning a decided flow into high-fidelity mockups, states, variants and hand-off specs.
Design tools now generate screens from a prompt and a design system, and code-generation tools skip the mockup entirely by producing a working interface. The pixel-production hours that filled a junior designer's week are the clearest casualty on a product team.
Defining the right problem
Still human-led≈ Platform inferenceWorking out what users are actually trying to do, where the current product fails them, and what is worth fixing first.
This rests on observing real people using real software and on organisational judgement about what the business can and will change. It is the input to everything downstream, and generating polished screens for the wrong problem is now cheaper and therefore more common — which raises the value of getting the problem right.
Research and usability testing
Being augmented≈ Platform inferenceWatching users struggle, running interviews, reading the analytics, and turning what you saw into a decision.
Transcription, synthesis of interview notes and analysis of session recordings are much faster with assistance, and synthetic 'users' are being marketed as a substitute. The substitute is weak where it matters: it cannot reproduce the surprise of a real person doing something no one anticipated, which is the finding research exists to produce.
Getting the team to agree
Still human-led≈ Platform inferencePersuading engineering that the extra state is worth building and product that the shortcut will cost users, in the same week.
Design decisions in software are negotiated, not decreed. The designer's leverage comes from evidence and from credibility built over previous decisions, both of which are personal. Tools produce more options to argue about; they do not settle the argument.
Designing for non-deterministic products
New task≈ Platform inferenceShaping products whose output varies — conversational interfaces, agents, generated content — where the old screen-by-screen craft does not apply.
A large share of new software has a model in the loop, and designing how it fails, how it explains itself and how the user stays in control is an unsolved craft. Teams are hiring designers specifically for it, and the skill is scarce because almost no one has done it for long.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
● 1 verified event for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.
Near the floor in 2022 and rising quickly, but the rise is almost entirely in production — screens, variants, prototypes. It decelerates from 2025 because the scarce thing moved upstream to deciding which problem is worth solving, and generating polished screens for the wrong problem got cheaper, not more valuable.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
One design-tool vendor's generative feature (GPT-4o and Amazon Titan on hand-built component design systems), limited beta. A vendor rollback, not a customer deployment; the feature returned within three months as First Draft.
Failure, rollback, regulation or cost is suppressing adoption. Can lower an assessment or widen its uncertainty.
Figma — blog retrospective ↗What this means for you#
A portfolio of polished screens is worth much less than it was, because polished screens are now cheap. What gets you hired is evidence of decisions: a problem you defined, the research you did, what you chose and why, and what happened. Build that with one real product — a side project with real users counts — and learn the non-deterministic interface problems early, because the field is short of people who have.
If your value was production quality and speed, expect that to be compressed; if it was problem definition, research and alignment, it is holding and the generative-product problems are new demand in your favour. The uncomfortable shift is that fewer production designers means each senior designer covers more ground with tools, so fluency with them becomes a baseline rather than a differentiator.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Lead with research and decisions, not screens
The scarce work is knowing what to build. Designers who can show the evidence trail behind a decision are the ones teams keep when production gets cheap.
Requires access to users and to the roadmap conversation, which junior roles often lack.
Take your best recent piece of work and rewrite the case study to lead with the problem and the evidence, with the screens last. If there is nothing to write before the screens, that is the gap.
Specialise in model-in-the-loop products
It is the fastest-growing category of software and its design problems are unsolved. Scarcity favours anyone who has shipped one.
You need a team building such a product, and tolerance for designing things whose behaviour you cannot fully specify.
Pick one conversational or agentic product you use and document three ways it fails the user and what you would change. That document is a portfolio piece nobody else has.
Product management
Designers who already own problem definition and alignment are doing much of the product manager's job. The move formalises it and usually pays better.
You inherit prioritisation, metrics and stakeholder management, and you lose most of the craft.
Sit in on one roadmap prioritisation meeting. If you found yourself with opinions on the trade-offs rather than the interface, take the path seriously.
Common questions#
You need to be fluent enough to direct and correct what the tools produce, which is less than a production specialist needed and more than nothing. The skill that has appreciated is everything upstream of the tool: knowing what problem to solve, what evidence supports a choice, and how to get a team to build it. Learn the tools quickly, then spend your effort on the judgement — that order is the reverse of how design education usually runs.
Studying towards this?
These majors lead here. Their pages break down which of their competencies transfer and what graduates typically lack.
Method and sources#
- Assessment date
- 2026-09-10
- Basis of the task judgements
- 1 evidence-backed · 4 platform inference · 0 not enough evidence
- Verified events
- 1