How do you become a UX designer?

In short

A UX designer makes sure people can get their task done with a product without effort. First comes the question of who wants to do what and why. Then come screens and flows that get that task done in as few steps as possible.

Don Norman and Jakob Nielsen define user experience as all aspects of the end user’s interaction with a company, its services and its products. For them, the first requirement of a good experience is to meet the customer’s exact needs without fuss or bother. That is what a UX designer works on every day.

In job ads, the role is called “UX designer” or “UI/UX designer”; some companies say product designer. The interface (UI) is the visible face of the work. UX also covers the decisions behind it: which step is needed, and which one leaves the flow?

What does a UX designer do?

A working day often consists more of conversations than of work at the screen. With product management it’s about goals, with engineering about technical limits. Then there are conversations with users and watching how they use the product.

A typical week looks roughly like this:

Task	Output
User interview	Notes and a list of recurring problems.
Drawing a flow	A step-by-step flow and rough screen sketches.
Prototype	A clickable, testable draft.
Usability test	A list of the places where users get stuck.
Team meeting	A decision on priorities and an approved design.
Handoff to engineering	Screens with measurements, states and error cases.

An example

Imagine that in a city water utility’s app, many users abandon paying their water bill. The UX designer first finds out in the analytics at which step. Let’s say it’s the account number field.

Next come conversations with a few users. They don’t know where the number is on the bill. The prototype gets a hint below the field: “It’s at the top left of your bill.” It’s tested again and, if it works, handed to engineering.

This cycle resembles NN/g’s design thinking framework. Sarah Gibbons describes it in six steps: empathize, define, ideate, prototype, test and implement. Gibbons considers the last step, actually putting the solution into practice, the most important.

Team size changes the work

In my experience, research, interface and copy sit with different people in large teams. In a small startup, one person does everything. The “UI/UX designer” role in job ads usually means exactly that.

Either way, the core stays the same. Design makes the users’ problem visible to the team and defends the solution with evidence.

What skills do you need?

I group what you need as a UI/UX designer into five areas. You don’t have to master them all equally well. But none of them should be completely foreign to you.

1. Research

Research means finding out what users do and why. Susan Farrell’s cheat sheet at NN/g arranges research methods by phase. It lists methods such as field studies, card sorting, interviews, surveys and analytics.

You don’t need to know them all at the start. If you can do only one activity and want to improve an existing system, Farrell recommends qualitative think-aloud usability testing. I also advise beginners to learn this method first.

According to Jakob Nielsen, a first study with five participants finds 85% of the usability problems. Nielsen advises spreading the budget across many small tests instead of one big study. So you don’t need a big budget for your first test.

2. Interaction design

Interaction design decides the steps users take to complete a task. Which screen comes first, and what do users see when there’s an error? You work this out first with a rough wireframe, then with a clickable prototype.

The foundation of this skill is Nielsen’s 10 usability heuristics. Add to that information architecture, which describes how menus and content are grouped. What behaviour users expect from a screen is explained by the mental model.

3. Visual design

Visual design sets the reading order of the elements. What is seen first is decided by size, spacing and colour. A grid and a consistent type scale do most of this work.

Colour decisions also touch accessibility. The W3C’s WCAG documents explain how to make web content more accessible to people with disabilities. Version 2.2 of the standard was published on October 5, 2023.

Criterion 1.4.3 Contrast (Minimum), for example, belongs to level AA and requires a contrast ratio of at least 4.5:1 for text. You can check your colour pairs with the contrast checker.

As a tool, I recommend starting with Figma. Google’s UX certificate teaches Figma too.

4. Interface copy

Button labels, error messages and copy for empty screens are part of the design. An error that says “Something went wrong” doesn’t tell users what to do. “The account number has 8 digits” does.

In the case Jared Spool described in 2009, a large ecommerce site removed the “Register” button between the cart and checkout. In its place came a “Continue” button and a message saying you don’t need an account to make a purchase. According to Spool, the number of customers purchasing went up by 45%.

The details are on the page about the $300 million button. My lesson from it: a button’s label and its place in the flow are a design decision, just as important as the screen’s colours.

5. Coding basics

A UX designer doesn’t have to be a developer. But if you know the basics of HTML and CSS, you can see in advance how what you draw behaves in the browser. A long name or a small screen is no longer a surprise.

My own experience with this is in the “My note” section below.

Skill	Where to start	How to show it
Research	A short user interview.	Interview notes and insights.
Interaction	Drawing a flow on paper.	Wireframe and clickable prototype.
Visual	Redrawing a screen with a grid.	Before and after screens.
Copy	Rewriting an error message.	Old and new text side by side.
Code	Building a form with HTML and CSS.	A link to a working page.

A step-by-step roadmap

When people ask me how to become a UI/UX designer, they get this order. Each step uses the result of the previous one. At the end, you have work you can show.

1. Learn the basic concepts. Start with user-centred design, usability and the 10 heuristics. This is the language you’ll later use to justify every design decision.

2. Pick a tool and draw screens. In Figma, copy a screen from an app you use as accurately as you can. The only goal of this step is to get to know the tool.

3. Do a small piece of research. Talk with two or three people about how they get a task done. For example, have them tell you how they book an appointment at a government office online.

4. Redesign a flow. Choose one of the problems from the conversation and redraw the flow step by step. Pick a publicly available interface and keep your critique fair.

5. Test and redraw. Give the prototype to five people and fix the places where they get stuck. The second version becomes the most valuable part of your portfolio.

6. Learn the basics of HTML and CSS. Build a form you designed. See for yourself how labels, focus and error states look in the browser.

7. Write the case study. Describe the problem, the process and the result on one page. I explain how to structure this page in the portfolio section below.

8. Get closer to real work. That could be a volunteer project, an internship or a small business’s website. Real constraints teach what a made-up project can’t.

Do you need a certificate?

If you’d like to follow a program, the Google UX Design Professional Certificate is one option. According to its official page on Coursera, it’s for beginners and requires no degree or experience. The page gives about 6 months at 10 hours a week.

I see the certificate as a learning plan. When it comes to hiring, the portfolio is what counts most. I explain that below, with the source.

How long does it take?

I can’t give a fixed duration, because it depends on your starting point and the time you have. I measure the duration by the result. As soon as you have a tested and written-up flow, you can apply for the first time.

Working regularly does more than long, infrequent sessions. Finish something small every week, such as an interview or a single screen. As small finished pieces pile up, the portfolio almost builds itself.

Make your own list

In the list below, I have ordered the roadmap’s tasks by skill. Tick what you’ve already done. The next step changes depending on your starting point.

Roadmap checklist

Where are you starting from?

I’m starting from zero. I have no background in design or code.I’m a graphic designer. I know the visual side.I’m a developer. I write code and want to move into design.

Which of these have you already done?

• ResearchI have run a user interview and organised my notes.
• InteractionI have drawn a flow step by step as a wireframe. Up next
• VisualI have designed a tidy screen with a grid and a type scale.
• InteractionI have built a clickable prototype.
• CopyI have rewritten an error message and button labels.
• ResearchI have run a usability test with five people.
• CodeI have built a simple form with HTML and CSS.
• PortfolioI have written a case study.

Next step: Draw a flow for paying a bill step by step on paper. On each screen, the user has only one task.

If you’re starting from zero, the first thing you do is draw a flow.

Choose your starting point and tick what you’ve already done. The next step depends on the starting point and appears in the list with an orange border. The order is my suggestion, not an official curriculum.

For graphic designers, I recommend research first, because they already know the visual side. Developers I advise to put code last. They already have that skill. What’s missing is talking to users.

Portfolio

The portfolio is where the hiring person gets to know you first. Rachel Krause’s 2019 portfolio article at NN/g is based on a survey of 204 UX professionals in charge of hiring. My most important takeaway from it: the people hiring want to see the messy process that led to the finished product too.

Krause recommends 3 to 5 detailed case studies and puts quality over quantity. Each case study should include:

• The problem or hypothesis.
• Your role and how you worked with the team.
• How you arrived at the solution.
• How the solution solved the problem.
• Obstacles and discarded ideas.
• The impact on users and the business.
• What you learned.

According to Krause, hiring managers very rarely read a portfolio word for word. So a case study has to make sense when skimmed and be easy to follow. Tell the story with images such as rough sketches, research notes and finished screens.

Krause also points out a common misconception: that a portfolio should show only finished interfaces. For her, early sketches, research materials and ideas that weren’t pursued belong in it too. She also recommends describing constraints openly.

Outline of a case study

Let’s turn the water bill example into a case study. The headings follow Krause’s list; the content is entirely an example.

• Problem: In the water utility’s app, some users abandon paying their bill at the account number step.
• My role: I did the interviews and the flow. I set the field’s validation rules together with the developer on the team.
• Process: I talked to four users. All of them had to look for the number on the bill, and two entered the wrong number.
• Discarded idea: At first I tried reading the number with the camera. In the test, users didn’t have the bill with them, so I dropped the idea.
• Solution: Below the field there is now a hint with a small image showing where the number is on the bill.
• Learned: Don’t propose a solution without asking what users have at hand.

The discarded idea does the most work in this outline. That’s where the reader sees how you think.

My suggestion: draw your first case study from the fourth and fifth steps of the roadmap. When the problem from the conversation and the second version after the test come together, the outline of the story is in place.

Common mistakes

In my experience, these are the mistakes beginners fall into most often.

Starting with the tool. Knowing every Figma feature doesn’t make you a designer. The tool helps when you know what you want to draw. Ten tool names in a portfolio prove nothing.

Showing only pretty screens. A redesign without research and testing is a visual exercise. The hiring person can’t see where your decisions come from.

Mistaking your own taste for a user need. “It looks sleeker” isn’t a reason. Link every change to a user problem or a principle.

Calling it done without a test. You don’t see the problems in your own design because you already know how it works. Even a small test with five people breaks this blindness.

Not talking to engineering. A design that can’t be built never reaches the screen, however good it is. If error cases and empty states aren’t drawn, engineering builds them based on its own guess.

Trying to learn everything at once. If you pursue five skills at once, you make progress in none. Finishing one flow from start to end teaches more than ten half-finished courses.

Avoiding feedback. If you show your first draft to nobody, you magnify the same mistake for weeks. Showing a rough draft early is cheaper than redoing a finished design.

Leaving accessibility for last. If a colour palette with too little contrast is only fixed later, every screen has to be touched again. Think about contrast and keyboard use from the first draft.

My note

I design and code together. The biggest advantage for me: decisions can be tried out quickly. Instead of debating in a sketch whether an interaction is right, I try it in the browser. Five minutes of trying gives a clearer answer than a long meeting.

The second advantage: I see the edges of the design. On a static screen, every name is short and every list is full. In code, long names and empty lists show up immediately.

I’m not saying you should become a full-time developer. Building a simple form with HTML and CSS yourself is enough. Once you’ve touched your design in the browser, your drawing habits change.

If you’re stuck on design or UX decisions in your own product, the UX audit guide shows step by step where to look.