I've been a working as a Product Designer for a little over a decade now, and I can honestly say the last two years have really changed the way I work more than the previous eight combined. When I set out to write this piece, I thought it would be a quick. Then I started listing everything that's different, and the list kept growing.
So here's my attempt at an honest opinion. It isn't a any kind of prediction. It's what my week actually looks like, what I've kept, what I've dropped, and where I use AI tools like Claude along the way.
The job moved upstream
There’s been a tectonic shift in UX and Product Design. Only two years ago, a large share of my time went to execution like building screens, naming layers, exporting assets, redlining specs for developers. Figma did make improvements to it’s product over time to make these things easier, but the manual way I perform those tasks hasn't disappeared. Now with AI these things they take a fraction of the time.
What's left is the part I always wanted to spend more time on. Figuring out what problem we're solving. Deciding what not to build. Sitting in a room (or on a call) with a frustrated customer and understanding why a flow that looked perfect in our review falls apart in real life.
That upstream shift has changed what teams expect from designers. Nobody is impressed that I can produce a nice mockup anymore. The value is in the judgement of which mockup, for whom, and why. I think a lot of designers are still adjusting to that, and I'm one of them.
Research
Research is where I first saw real automation from AI, and also where I've had to be the most careful. After a round of user interviews, I used to spend two or three days synthesizing notes into highlights and themes. Now I paste transcripts into Claude and ask it to pull out all the pain points, then I check every claim against the source. When I ask for themes, I always ask for the exact moments in the transcript that support each one, so I can go and read them myself. Sometimes the theme holds up. Sometimes it's a neat summary of something that only one participant said, and I would have missed that if I'd just accepted the output.
My rule is simple, AI can help me organize what people said, but it can't tell me what they really mean. Meaning comes from being in the conversation, noticing the pause before someone answers, and following up on the thing they almost said. I still run every interview myself, and I still take my own notes even if they’re messy.
I also use these tools for planning. Before a research round, I'll describe the product and the audience and ask Claude to evaluate my interview guide. It's good at spotting leading questions and it flags them immediately which is a great time saver.
For storing and sharing findings, I still rely on spreadsheets and tools like FigmJam. AI hasn't replaced that yet, it's just made the work of easier.
Prototyping
If research got faster, prototyping got a complete overhaul. I still start most projects in Figma and exploring is how I think. I don't see that changing. But once I have a direction, I now often build a prototype in code instead of linking static frames together. Using Claude's artifacts feature, I can describe an interaction in plain language, like "a card that expands to show more options" and get something clickable within a few minutes or even seconds.
This matters more than it sounds. A static prototype hides problems. When a stakeholder clicks through a linked set of frames, they follow the path I built for them. When they use a working prototype, they do the unexpected things, and that's where I learn something. Real data, real states, real edge cases like an empty state or a label that's really long. Those used to show up in development, when changing course was expensive. Now they show up in the first phase.
I'm not a developer, and I want to be clear about that. The code that comes out of these sessions is for learning, not for shipping. I hand the prototype link to engineering as a conversation starter, not as production work. The engineers I work with have been generous about this, partly because it means fewer meetings.
The other thing fast prototyping does is show me how often I rebuild the same pieces. The same card, the same button, the same bottom sheet, each one slightly different from the last. That repetition is what pushed me toward the project I'm proudest of this past year.
Design systems (one of my goals this year)
Over the summer of 2026 I built a design system to support iOS and Android products. Anyone who has done this knows the hard part isn't the components. It's the thousands of small decisions underneath them, and the work of keeping two platforms feeling like one product.
Before building anything, I needed to know how big the inconsistency problem really was. I went through our live screens and listed every button style, corner radius, and text size I could find, then asked Claude to group them. Seeing it all in one table did more to win over stakeholders than any slide deck would have.
Token naming was next, and naming is where design systems tend to stall. I described my structure (primitive values, then semantic tokens, then component tokens) and asked Claude to find where it would break down. We have a web product with it’s own design system so I had to find a way to align with it. I made every call, but having something to argue with early on was useful.
The trickiest part was iOS versus Android. Apple's guidelines and Material Design make different assumptions about navigation, touch targets, and even how basic controls behave, and I didn't want one strict set of components that ignored that. I had Claude compare how each platform handles patterns like bottom sheets, date pickers, and keyboards, then used that to write guidance on where our components should match and where they should diverge.
Documentation is the part I used to put off until someone asked for it. Now I write the rough version with the criteria I need and ask Claude to write it. When to use a component, when not to, accessibility needs, and the states. I edit heavily, because generated documentation is usually generic by default.
Copywriting
Once the components exist, the next thing I notice is the words inside them. A change I didn't see coming is how much of my time goes to writing. Interface copy, error messages, labels, onboarding flows, empty states. All of it shapes how a product feels, and in 2026 I think content design is simply part of the job for every designer, whether or not your title says so.
I use Claude as a sounding board for this. I'll write a first draft of an error message myself, then ask for five alternatives in different tones and pick the ones I like. I rarely use a suggestion as is. What I get is a wider set of options than I'd produce alone.
Since I work in Canada, I also have to think about bilingual products. Plenty of the work I do needs to function in both English and French, and the province of Quebec has its own expectations around language. AI tools help me draft and compare translations.
Design reviews
When I need a quick review or when I'm stuck on a layout, I'll upload a screenshot and ask Claude what's working and what isn't from an accessibility and clarity standpoint. It catches things like low contrast, tiny tap targets, and inconsistent spacing quickly.
It isn't a replacement for a real design review with my team. People bring context, taste, and history with the product that no tool has. But it's a useful first pass, and it saves my teammates from having to point out that my secondary buttons are barely readable.
What AI still can't do
I want to spend a bit of time here, because I think the conversation about AI in design tends to skip it. AI doesn't know your users. It knows patterns about users in general, which is useful but also dangerous, because "most apps do it this way" is the quickest path to an average product. When I lean on AI suggestions too early, my work starts to look like everything else so I use it sparingly.
AI also doesn't carry accountability. If a flow confuses people or a feature excludes a group of users, that's on the team, and ultimately on me.
And it doesn't have taste, at least not yet in a way I trust. It can produce ten reasonable options. Choosing the right one still depends on understanding the brand, the moment, and the people on the other side of the screen.
My workflow
For anyone curious about the practical side, here's a typical framework for me now:
I write the problem statement by hand, usually on a whiteboard first. Then I stress test it with Claude, asking where the assumptions are weak.
For research I run the interviews myself. Sometimes getting participants to help is challenging, so I get creative. I use AI to help prepare guides and to cluster notes afterward, and I verify everything against the source.
Explorations are done in Figma, mostly alone or with a teammate. Sometimes FigJam for workshops with stakeholders.
For the prototypes, I build them with Claude for the interactions that matter, tested with real people as early as possible.
When a pattern keeps repeating, it goes into the design system, with AI helping me audit for inconsistencies and draft the documentation.
For copywriting, I draft, then use AI for alternatives and a quick accessibility check.
The handoff includes conversation with engineering, supported by the prototype, the Figma file, and a written rationale. I write the rationale myself, because it's how I find out whether I really understand my own decision.
Where I think this goes
I have no idea what product design will look like a couple years from now. Anyone who claims to is guessing. What I do believe is that the gap between having an idea and testing it with a real person is shrinking, and that's good for users.
The risk is that speed becomes the goal. Faster isn't the same as better, and a team that ships ten mediocre experiments in the time it used to take to ship one thoughtful one hasn't actually improved.
For now, I'm optimistic, a little tired, and still enjoying the work more than I expected to at this stage. If you're a designer feeling uncertain, I'd say that's reasonable. Keep making things, keep talking to the people who use them, and keep learning.
