UX training for developers and product owners with no design background

On-Off Group

October 2026

UX training for developers and product owners works best when it teaches three things: how to watch a real user try your build, how to make a rough version good enough to test, and how to record a before number so you can tell if the change helped.

This is for engineering and product teams who own a customer-facing flow and have no designer sitting with them. Onboarding, claims, a top-up screen, an internal tool branch staff use all day.

Most UX training for developers is a set of principles. What actually gets used later is smaller than that: watch a customer use your flow, cut out steps, fix the worst one, then check whether the number moved.

Below is what we teach engineering and product people, and how to tell on the Monday after whether any of it stuck.

The problem shows up as an argument nobody can settle

The product owner wants the ID upload on step two. A developer says the API will time out and it should go last. Someone in compliance wants an extra consent screen. The meeting ends and the decision goes to whoever was most senior in the room.

None of those people have watched a customer do it. So nobody in the room can settle it.

That is what UX training gives people who are not designers: a way to settle the argument. A way to settle the disagreement with evidence you can get in the same week. Five people, real phones, the actual build, screens recorded. You watch two of them and the argument is over, because everyone saw the same person give up at the same place.

Once a team has done it a few times, it becomes part of checking the flow.

Teach watching before you teach anything else

The first skill is sitting quietly while someone struggles. It sounds easy and it is the hardest part for developers, because you built the thing and you know where the button is.

Rules that work: give them a task, not instructions. Say nothing for the first minute. When they ask "is this right?", ask what they expected to happen. Do not defend the build.

A product owner can run this. So can a back-end developer. You need a script, and someone sitting next to you to stop you helping.

We cover what a full programme includes and which roles benefit in What UX training covers and who in a bank should take it. The short version for a small team: one day of practice with real users beats a week of theory, and the practice has to be on your own product, not a case study.

Rough and unfinished are fine, clicking through screenshots is not

Product owners get stuck waiting for the build to be presentable. So the test slips a sprint, then another.

A test version needs one thing: the user has to be able to do the task without you narrating. Placeholder copy is fine. Hardcoded data is fine. One happy path with everything else greyed out is fine. Clicking through a picture of a screen while you read out what would happen is not. People are polite when you are walking them through screenshots. They tell you the truth when they are trying to finish a task.

This is where a little Figma helps, mostly so developers can open the file, see what changed and make a small edit without waiting for someone. That takes a few hours to learn. If nobody on the team has ever opened it, How to learn Figma from scratch with no design background is the level you need.

Work in short cycles, with the customer in the middle

The reason to bother is speed. On a series of five-day design sprints with a large insurer, web journeys that used to take six months or more were designed and tested with customers in two weeks and live in four. Twenty-six weeks down to four. The client measured completion rates on the new flows up 80 percent, and the old drop-off points went away.

No special method got that result. The decisions were made in the room, with customers watching the thing within days instead of reviewing a document in a month.

A product team can work this way without running a formal design sprint. Build the thinnest version, test it, fix the worst step, test again. If that cycle sounds unfamiliar, the structure behind it is set out in What is design thinking and what a team does in the room.

Write down the before number or you will never prove it

Most teams have no baseline. Someone asks whether the redesign worked and the honest answer is a shrug.

Pick one number before you touch anything. Completion rate on the flow. Turnaround time from submission to approval. Number of calls to the branch about that one screen. Count it for a week. Write it in the ticket.

It does not have to be clever. A count of how many people got stuck out of ten is a number. Small honest numbers hold up better in a review than a big vague claim about improved experience.

Then count the same number after. That is the difference between an opinion about the flow and something your boss can read.

Decide now who owns it after the project

Training fades when the person who cared moves teams. Name someone who runs the test sessions, keeps the recordings and reports the number every month. Put it in their objectives, not in a wiki page. More on the handover problem in UX agency or in-house team: how to keep the skill after the project.

What to do this week

Pick one flow you already argue about, and write down one number for it today.
Book five real users on video doing that flow on the current build.
Watch the first two sessions with the developers who wrote the code, not a summary afterwards.
Fix the single worst step, ship it, and count the same number again in two weeks.
Put one person's name against running the next round.

Questions people ask

Do developers need to learn Figma?
Enough to open a file, read the layers and change a component without breaking it. Product owners rarely need more than that. Anyone drawing screens from scratch needs more practice than a course can give.

How many users do you need to test with?
Five people using the real flow on video will show you most of the problems in a single step. The first two usually find the same thing, which is a good sign you are looking at something real.

How long before the training shows up in the work?
Look at the first real task after the room empties, usually the next sprint. If nobody has run a test session or changed a screen because of one, the training did not land.

Should we hire an agency or train the team?
Both work, but the skill only stays if someone in-house owns it. Agree who runs the test sessions after the project ends before the project starts.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with ux training.