What Does a Product Designer Do? A Lead Designer's Honest Answer

So, what does a product designer do? A product designer decides what a digital product should be and how it should work, then makes sure that decision reaches real users in a form they understand. The job covers research, problem framing, flows, prototypes, visual design, testing and close work with engineers until the thing ships. Screens are the output people see. The actual work is choosing which problem to solve and proving the choice was right.

I have done this job for more than 12 years, most recently as Lead Product Designer and Design Engineer on ViewStats, the creator platform built by the team behind MrBeast. This page is the answer I wish someone had given me early: what the role really involves, how it differs from UX and UI work, what a normal week looks like, and how AI is changing it right now.

What does a product designer do, in one sentence and in practice

The one sentence: a product designer owns the gap between what the business wants and what users actually do.

In practice that gap shows up as very concrete questions. Why do people sign up and then never come back? Why does the sales team have to demo the product for every customer? Why is the pricing page getting traffic but no upgrades? A UI designer gets handed a screen to make. A product designer gets handed a question like these, and is expected to come back with an answer, a design that tests it, and a number that says whether it worked.

That last part matters. When I joined ViewStats, a lot of creators were signing up but never connecting their YouTube channel, which is the step that makes the product useful. Nobody asked me for "a new onboarding screen." The problem was activation. Funnel analysis and research showed that creators did not understand what they would gain by connecting. So the work became value communication: onboarding moments, empty states and contextual prompts that showed the payoff before asking for access. Channel connection went from 13% to more than 65%. You can read the full breakdown in the ViewStats creator tools case study.

That is what the job is. A problem, a hypothesis, a design, a result. The screens were the easy part.

The core responsibilities of a product designer

Every company slices the role a little differently, but the responsibilities below show up almost everywhere. If a job description leaves most of them out, it is probably a UI or visual design role with a product title on it.

Understand the user and the problem

Research is not a phase you finish. It is a habit. At ViewStats the inputs were creator interviews, onboarding analytics, Discord community feedback, support requests and internal workshops. The single most useful insight came from listening, not from a dashboard: creators were not asking for more charts. They wanted confidence about one question, "What should I make next?"

Sometimes research is easy. At Greenely, a Swedish energy app used by more than 200,000 households, users were reachable through a Facebook group of over 2,000 members, and some would literally knock on the office door to complain or ask for features. Sometimes it is hard. At Accern, a no-code NLP and AI platform for financial organizations, the users were large finance enterprises with very little time for testing, so research had to run through the customer success team. Part of the job is finding a way to learn from users no matter which situation you are in.

Frame the problem before designing anything

Most bad products are not badly drawn. They solve the wrong problem. A product designer turns messy input into a clear statement of what is broken and for whom. At Accern that meant naming an uncomfortable fact: 95% of users never used the product on their own. The customer success team built use cases for them. Jargon like taxonomy, NLP and data store confused people, and the product was split into two separate tools. Until that was written down plainly, every new feature would have made things worse.

Design flows, not just screens

Users do not experience screens. They experience sequences: arrive, understand, try, succeed or quit. Flows, storyboards and wireframes are where a product designer decides the order of things, what to ask for and when, and what happens when something goes wrong. Empty states and error states get as much attention as the happy path, because that is where people decide whether to stay.

Prototype and test quickly

A prototype is a question you can hold. The faster you can put one in front of a user or a stakeholder, the cheaper your mistakes become. These days my prototypes are often real code, which I explain further down.

Make it usable and beautiful

Visual design still matters. Typography, spacing, hierarchy, motion and tone decide whether a product feels trustworthy. I care a lot about interfaces that feel alive: physics, sound, small surprises. But visual polish on top of a wrong flow is decoration.

Build and maintain the design system

Once a product grows past a few screens, consistency becomes a design problem of its own. At ViewStats I worked on a design system covering web, mobile, marketing and the Chrome extension: typography, color, navigation, data visualization, dashboard components, tables, forms, empty states, variables and tokens. At Bitgrit, where I was the only designer, a UI kit grew into the design system as the product grew.

Work with engineering until it ships

The design is not done when the Figma file looks right. It is done when the shipped version matches the intent and the metric moves. A product designer reviews builds, answers edge cases, cuts scope when needed and follows the numbers after launch.

Measure the outcome

Results are part of the work. At Accern the redesign led to a published +200% in retention, with users checking the platform two to three times a week and navigating without customer success help, and 82% fewer support tasks. Those are product numbers, and a product designer should be able to talk about them as comfortably as about fonts.

Product designer vs UX designer vs UI designer vs design engineer

The titles overlap and companies use them loosely. Here is how I separate them when I hire or get hired.

Role	Main question they answer	Typical output	Measured by
UI designer	How should this look and feel?	High-fidelity screens, visual language, components	Quality and consistency of the interface
UX designer	Can people use this to reach their goal?	Research, flows, wireframes, usability tests	Task success, usability findings
Product designer	What should we build, and does it work for users and the business?	Problem framing, end-to-end flows, prototypes, final UI, design system	Product metrics: activation, retention, conversion, support load
Design engineer	How do we get the intended experience into production, fast?	Working prototypes, production components, motion, pull requests	Speed and fidelity of what ships

A good UX designer and a good product designer can look identical on a given day. The difference is scope and accountability. The Nielsen Norman Group definition of user experience is broad and useful here: UX covers every interaction a person has with a company and its products. Product design is the part of that responsibility attached to one product and its outcomes.

The design engineer row is the one changing fastest. I will come back to it.

What a product designer's week actually looks like

People imagine a product designer sitting in Figma all day. On a good week, Figma is maybe a third of the time. Here is a realistic shape of a week on a product team, based on how my work has run across startups and scale-ups.

Discovery time. Reading support tickets, scanning community channels, watching session data, joining a user call. At ViewStats a lot of signal lived in a Discord community of more than 17,000 creators. That kind of channel is gold if you actually read it.

Decision time. Working sessions with a product manager and an engineer to agree on what problem this cycle is about, what success looks like and what we are not doing. A lot of my value is said out loud in these meetings, not drawn.

Making time. Flows, wireframes, prototypes, high-fidelity screens, motion. This is the part everybody sees.

Review time. Design critiques, stakeholder reviews and, more and more, code reviews. A product designer who checks the build catches half the experience bugs before users do.

Learning time. Looking at what shipped last cycle and whether it moved the number. If it did not, that is information, not failure.

The ratio changes with the company. As the only designer at a 30-person company like Bitgrit, I did everything from interviews to the UI kit. As the first design hire at Accern, post-seed through Series A and B, a lot of the job was building the habit of design inside the company, including designing the Series B pitch deck that raised over $40M. Design does not stop at the product boundary.

The skills a product designer needs

If I had to rank them, this is the order I would put them in. Notice that visual craft is not at the top. It is essential, but it is the easiest to see and the easiest to fake.

Problem framing. Saying clearly what is wrong, for whom, and how you will know it is fixed.
Research and listening. Interviews, surveys, analytics, and the humility to change your mind.
Interaction design. Flows, states, hierarchy, the order of decisions a user has to make.
Visual and motion craft. Type, color, layout, animation, sound. The layer that earns trust.
Systems thinking. Components, tokens and patterns that scale beyond one screen.
Communication. Writing, presenting and negotiating with engineers, founders and sales.
Product and business sense. Knowing which metric matters and why.
Technical fluency. At minimum, knowing what is expensive to build. Increasingly, building it yourself.

Writing deserves a special mention. At Accern, a big part of the redesign was removing jargon. Words like taxonomy and data store meant something to the engineers and nothing to the analysts using the product. Changing the language was a design decision with real impact on whether people could use the platform alone.

Real examples of product design decisions

Definitions only go so far. Here are four decisions from my own work that show the job better than any list of skills.

Show value first, ask for trust second

The ViewStats activation problem was a permission problem. Asking a creator to connect a YouTube channel is asking for trust. The original flow asked before it showed anything. The redesign flipped it: show what the product will tell you, then ask for the connection. That principle, "show value first, ask for trust second," now shapes how I design any permission, connection or sign-up screen.

Meet users where they already are

Creators live inside YouTube. Instead of asking them to switch tabs to a dashboard, we brought insights inside YouTube through a Chrome extension. It grew to more than 200,000 users and became a major acquisition and retention channel. The design decision was not about pixels. It was about location.

Design trust into AI features

The AI thumbnail and title tools at ViewStats went from concept to launch in roughly two weeks. The biggest challenge was not the interface. It was designing trust. After launch, the tools drew public criticism about the impact on artists and thumbnail designers, and the conversation reached mainstream press, including BBC coverage of the ViewStats AI thumbnail backlash. My view has not changed: AI tools already existed everywhere, and the job is to design tools that help creators move faster while keeping humans at the center of the creative process. The lesson for any product designer is that product decisions never exist in isolation.

Design free and premium so neither feels broken

On ViewStats mobile, the challenge was balancing free and Pro. Premium had to be visible enough to show its value without making free users feel locked out. Paywalls are a product design problem, because they sit right on the line between the business goal and the user's goal.

How AI is changing what a product designer does

This is the part of the role moving fastest, and I am in the middle of it.

At ViewStats my role expanded from Lead Product Designer to design engineer. I worked directly in the codebase with Cursor, Claude Code, React, TypeScript and GitHub. I designed, prototyped, built React components, opened pull requests and reviewed implementation. Iteration cycles got dramatically shorter, because the distance between "I think this should feel like X" and "here it is, running" dropped to almost nothing.

Outside client work, I have built 17 playable AI experiments, each a working build rather than a mockup, mostly with Figma, Claude and the Figma MCP, plus SwiftUI, Metal shaders, WebGL, three.js, physics engines, Rive, AI video and ElevenLabs for sound. They are all on my AI design experiments page. Building them taught me where AI actually helps and where it does not.

Here is my honest read. AI replaces a lot of production work: first-draft layouts, boilerplate code, variations, placeholder assets. It does not replace judgment. It cannot tell you that creators want confidence instead of more charts, or that 95% of your users never touch the product alone. Those insights come from listening to people and deciding what matters. If anything, AI makes that judgment more valuable, because the cost of building the wrong thing quickly has never been lower.

What this means for the role: the product designers who thrive will be the ones who can go further down the stack. Not every designer needs to become an engineer. But a designer who can prototype in code, test with real data and open a pull request will shorten every loop on the team.

How to become a product designer

There is no single path. I am from Morocco and have built a career working remotely with teams around the world, so I am a fair example that the path does not require a specific city or school. What it does require:

Real problems in your portfolio. Hiring managers want to see the problem, your reasoning, what you tried, what failed and what changed. Pretty shots without context do not get interviews.
Proof of shipped work. Even a small app or a side project that real people use beats a dozen concepts.
Comfort with numbers. Learn to read a funnel. It changes how you design.
Some technical depth. With AI coding tools, there is less excuse than ever not to build your own prototypes.
Reps talking to users. Every interview makes you better at the next one.

If you are hiring rather than becoming one, my guide on how to hire a product designer in Casablanca covers the roles, red flags and interview questions, and most of it applies anywhere.

When you need a product designer, and when you do not

Not every team needs one yet. If you have a clear spec, a stable product and mostly need screens built, a strong UI designer may be the better fit. If you are in a narrow technical niche where the main users are the engineers building it, you may get further with good defaults and a design system.

You need a product designer when the problem itself is unclear. When signups do not turn into active users. When support load is growing faster than customers. When two products need to become one path. When you are adding AI and are not sure people will trust it. Those are the situations where design changes the outcome, not just the look.

FAQ: what product designers do

What does a product designer do day to day?

A mix of discovery (reading feedback, talking to users, reviewing data), decision meetings with product and engineering, making flows and prototypes, reviewing what was built and checking whether the last release moved the metric it was meant to move.

Is a product designer the same as a UX designer?

They overlap heavily. A UX designer focuses on whether people can use the product to reach their goal. A product designer carries that plus accountability for product outcomes, business goals and often the visual layer and design system too.

Do product designers need to code?

Not strictly, but it helps more every year. Knowing what is expensive to build makes your designs better. Being able to prototype in code or open a pull request, as I did at ViewStats, makes the whole team faster.

Will AI replace product designers?

AI is replacing production tasks, not the judgment about what to build and why. The designers at risk are the ones whose whole job is producing screens from a spec. The ones who frame problems, talk to users and own outcomes are getting more leverage, not less.

What does a product designer do in tech companies versus agencies?

In a product company you live with one product for months or years and are measured on its metrics. In an agency you move across clients faster, which builds range, but you rarely see the long-term results of your decisions. Both teach different things.

Go deeper

This is the main guide in a series on the product designer role. More focused posts on skills, career paths, portfolios and AI tools will be linked here as they go live. In the meantime, the best way to see what a product designer does is to look at the work: start with my product design work, the Accern no-code AI platform case study or the Greenely energy app case study.

If you are a founder trying to decide what kind of designer your product needs right now, I am happy to talk it through. You can work with me as your product designer or just send me the problem you are stuck on.