What do Product Designers do? (Digital / UX)
An honest look at the day-to-day work: research, sketching, critique, handoff and the parts of the job nobody puts in a job advert. Use it to picture the role before you commit to it.
Watch on YouTube (opens in a new tab)Third-party video. It is loaded from YouTube and is not hosted by the academy.
By the end of this lesson you can
- Describe the main activities in a product designer's week.
- Name the artefacts designers produce and what each one is for.
- Identify the skills beyond tools that make designers effective.
The idea
Beginners often imagine designers spending all day pushing pixels in a design tool. In practice, tool time is maybe a third to a half of the week. The rest is understanding problems, talking with people, reviewing work and making decisions.
A realistic week
Here is a fictional but typical week for a designer on a small product team building a clinic appointment app:
- Monday: team planning. The designer hears that many patients abandon booking on the "choose a time" screen. They agree to investigate this week.
- Tuesday: looks at analytics with the product manager, reads support tickets, and calls two patients the clinic has permission to contact. Notices that people cannot see which doctor is available on which day.
- Wednesday: sketches four different approaches on paper, then builds two of them as quick wireframes. Shares them with an engineer to check what the booking system can actually return.
- Thursday: design critique with other designers in the morning. Turns the stronger idea into a clickable prototype and tests it with three people in the afternoon.
- Friday: updates the design based on the tests, writes notes on states and edge cases, and walks the engineer through it. Also reviews a teammate's work and fixes two bugs in the design system.
The artefacts designers make
Every artefact exists to answer a question or support a decision. Choose the lightest one that does the job.
- Research notes and summaries: what did we learn?
- Problem statements: what exactly are we solving and for whom?
- User flows and sitemaps: what are the steps and where do things live?
- Sketches and wireframes: what could the structure be?
- Prototypes: how would it feel to use, and does it work for real people?
- High-fidelity designs and specifications: exactly what should be built?
- Design system components and documentation: how do we stay consistent and fast?
Why it matters in real projects
If you know what the job really involves, you can practise the right things. Many beginners spend months on tool tricks and visual polish, then struggle in interviews because they cannot explain how they would find a problem, choose between options or work with an engineer. Those conversations are a large part of the job, and they are learnable.
A realistic example
Two junior designers present the same booking-screen redesign in an interview.
The first shows six polished screens and says, "I made it cleaner and more modern."
The second shows three screens and says, "Booking data showed most drop-offs on the time picker. In two short calls, patients said they did not know which doctor they would get. I tried four layouts, tested two, and grouped times by doctor with their next available day. In a small test, all three participants booked without help, compared with one of three before. Next I would check the completion rate after launch."
The second designer is describing the actual job. Their screens may even be less polished; they are still the stronger candidate.
Step by step
Find a real process to learn from
Read two or three published case studies from designers or public design teams, for example GOV.UK design blog posts. Focus on what they did, not what the final screens look like.
List the activities
Write down every activity mentioned: interviews, workshops, sketching, testing, meetings. Note who they worked with.
List the artefacts
Write down every artefact shown or mentioned and the question it answered.
Rate your current confidence
Score yourself from 1 to 5 on each activity. This becomes the starting point of your learning plan in the last lesson of this stage.
Common mistakes
Mistake Treating high-fidelity screens as the only real output.
Instead Value the decision, not the artefact. A sketch that settles a debate in ten minutes is excellent work.
Mistake Designing alone and revealing finished work at the end.
Instead Share early and often, especially with engineers. Late surprises cost the most.
Mistake Ignoring what happens after launch.
Instead Ask how success will be measured and check it. That habit separates product designers from screen designers.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 45 min
Map a designer's week
Using two published design case studies or team blog posts, reconstruct what the designers did.
Steps
- Pick two detailed public case studies or design team blog posts.
- List every activity, collaborator and artefact mentioned.
- Draw a simple timeline of the project from problem to launch.
- Rate your confidence from 1 to 5 for each activity.
Deliverable
A timeline per case study and one combined table of activities with your confidence ratings.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Designers spend much of their time understanding problems, collaborating and testing, not only using tools.
- Every artefact should answer a question or support a decision.
- Explaining your reasoning is a core professional skill.
- Good designers care about what happens after launch.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
- GOV.UK Design Notes (opens in a new tab)Government Digital Service
Real posts from designers about their process, decisions and mistakes.
- Design in government: the Service Manual (opens in a new tab)GOV.UK Service Manual
Your notes
Marking complete updates your course and roadmap progress.