VMTech
Discuss a project →
← All capabilities
PRODUCT & GROWTH · 04

UX Design

The user did not “fail to figure it out”. They reached a step where the next move was unclear and left. Our job is to find that step before it ships.

Discuss a project
HOW WE WORK

How we find the step where people drop

Not “redesign it”, but locate the exact place the journey breaks and test the fix before development.

research.vmtech.rs
Journey: checkout
LIVE
ready to build
We look at the data drop-off: step 3
We talk to people 5 interviews
We map the journey 7 steps
A prototype clickable
Testing with people task completed
Into development ready to build
HOW WE WORK
  1. We look at the dataAnalytics shows which screen ends the journey and how many people reach it
  2. We talk to peopleA handful of short interviews with users and with the people who answer their questions
  3. We map the journeyThe path is broken into steps: what the person knows, must decide and is missing
  4. A prototypeA clickable mockup takes days rather than a month of development
  5. Testing with peopleWe give a task and watch where the person stalls — silently, without hints
  6. Into developmentWhat goes to the team is a tested decision, not a guess
A FAMILIAR PICTURE

Why “make it look nice” solves nothing

Design without research

  • Screens follow the client's taste, and the argument is about button colour, not the journey
  • A form asks for data that is not needed yet at that step — so people abandon it
  • Support answers the same question daily, and it never makes it back into the interface
  • The mistake surfaces after release, and the fix now costs development, not a mockup
  • The phone view is checked last — and that is where most people arrive

Design from the journey

  • Decisions are discussed in terms of the user's task, not personal taste
  • The form asks exactly what is needed now; the rest comes later or by itself
  • Frequent support questions turn into hints and interface changes
  • Mistakes are found on the prototype, where a fix costs hours
  • The journey is designed from the phone, and desktop gains room — not the other way round
SCOPE OF WORK

What the UX work covers

Task and audience review

Who uses the product, in what situation, and which decision they make at each step.

Audit of the current interface

We walk the journeys ourselves and mark, from analytics, where the path breaks.

Interviews

Short conversations with users and with the people who take their calls and messages.

Journey map

The main paths from entry to goal, with the points that need data, decisions or help.

Prototypes

Clickable mockups of the key screens — the logic is visible before any code is written.

User testing

A task, observation and a short report: where they stopped, what they misread, what we change.

Interface copy

Labels, hints and error messages that explain what to do next.

Handover to development

Screen states, form behaviour, empty and error states — so nothing is guessed in code.

HOW WE VERIFY

The tools that produce facts instead of opinions

Journey analyticsWhere the journey ends and how many people get that far
Session recordingsYou see how a person hunts for what they need and where they stall
PrototypingClickable mockups for testing the logic before code exists
Moderated testsA task and observation — the most honest source of what is unclear
AccessibilityContrast, target sizes, keyboard operation and a sensible focus order
Comparing variantsWhen logic cannot settle an argument, the variant is checked on traffic

We do not promise a specific conversion lift: that depends on the product, the price and demand. We are responsible for decisions being made on facts and for contested points being tested before development.

QUESTIONS

What people usually ask

What is the difference between UX and UI?

UX answers “what happens and in what order”, UI answers “how it looks”. You can draw a beautiful screen for a journey nobody needs, and equally ruin a good journey with unreadable typography. They are two different jobs, and we separate them deliberately.

Do we need research if the product already works?

Then it is cheaper: you have analytics, real users and a support team that knows the sore spots by heart. Often data review plus five interviews is enough to find the step where a noticeable share of people is lost.

How many people do you need for a test?

To find problems in a journey, five to eight people from your audience is usually enough: most serious obstacles show up with the first few. Comparing two variants by numbers is a different exercise — that needs traffic, not interviews.

Can you just draw the screens without research?

You can, and sometimes it is justified — when the journey is standard and the market has already worked it out. But if the product is unusual, screens without a journey get rebuilt after launch, when mistakes cost more. We say plainly when research is unnecessary — that is part of the job too.

What do we get at the end?

A journey map, prototypes of the key screens, a testing report with concrete observations and a description of states for development. All in a form both a developer and a business person can read — no slides for the sake of slides.

Related capabilities

UI Design How it looks WEB development Where the journey comes alive Digital marketing Who arrives on the page Online store The most sensitive journey

Let’s apply this capability to your project

We define the challenge, dependencies and a realistic delivery plan.

Discuss a project