UI UX Experience: How Interface Design Actually Works

Two words people use interchangeably, and shouldn't

User experience is the sum of everything a person goes through with your product: how they arrive, what they are trying to do, how many steps stand between them and it, and how they feel when something goes wrong. It exists whether or not anyone designed it.

User interface is the layer they touch: layout, type, colour, spacing, states, motion. It is what most people picture when they say design, and it is roughly the last third of the work.

The distinction matters commercially. If checkout abandonment is high because the form asks for a passport number nobody expects, changing the button colour will not help. Diagnosing which layer the problem lives in is most of the value a designer provides.

What shapes the experience beyond the screen

Speed is a design property. A screen that is elegant and takes four seconds to appear on a mid-range phone over mobile data is, in practice, a bad screen. Weight of images, number of fonts, and how much has to load before anything is visible are all design decisions with real consequences.

So is copy. Labels, error messages, empty states and confirmation text carry more of the experience than most visual work does, and they are the part most often left as placeholder text until launch.

And so is what happens after the tap. If a form submits successfully but nobody replies for three days, the user's experience of the product is that it does not work. Design that stops at the screen edge is incomplete.

The process we follow, step by step

Research first. Who uses this, what are they trying to finish, on what device, and what do they currently do instead. This can be a week of conversations and analytics review rather than a formal study, but skipping it means designing for an imaginary person.

Then structure: the map of screens and the paths between them. This is where most real problems get solved, and it is cheap to change at this stage and expensive later.

Then prototype, in grey boxes, so decisions get argued about on flow rather than on colour. Then interface: the visual system, components, states, responsive behaviour. Then handover to development, with specifications tight enough that the built version resembles the designed one.

Designing for a mobile, bilingual audience

In Uzbekistan the majority of sessions come from phones, often on modest hardware. Designing on a large monitor and checking mobile at the end reliably produces layouts that fall apart where the traffic actually is. We work the other way round.

Bilingual interfaces have a physical problem: the same label is a different length in Uzbek and in Russian. Buttons sized to fit one language break in the other, navigation wraps, and tables overflow. Components have to be built with that flex from the start rather than patched after translation.

There is also a habits question. A large share of the audience lives inside Instagram and Telegram, and their expectations for how an interface should behave are set there. Fighting those conventions costs you attention you did not have to spend.

Mistakes that cost more than they look like they should

Designing every screen and no states. The empty version, the loading version, the error version, and the too-much-data version are where products actually break, and they are routinely left undrawn.

Treating the design as a picture rather than a system. Twenty screens with slightly different button styles will be built as twenty different buttons, and every future change becomes twenty edits.

Redesigning by taste. If nobody can say what the current interface does badly, a redesign is a coin toss that may lose you conversions you never measured in the first place.

Deliverables and who owns them

A finished project normally includes the screen designs, a component library, responsive behaviour for the sizes that matter, and specifications the development team can build from without guessing.

We hand over the source files. They are yours, and you should be able to take them to another team without negotiating for access. An agency that keeps your files is protecting itself, not you.

Where we also build the product, design and development stay in one place, which removes the usual round of arguments about what was intended versus what shipped.

Cost, timeline, and what changes them

Design and branding at Jar Agency are priced per project, because a five-screen landing page and a multi-role application have almost nothing in common except the word design.

The variables are the number of unique screens, how many states each needs, whether a design system already exists, whether two languages are in scope, and how much research the project genuinely requires.

Timeline follows the same logic. We scope after seeing the product and understanding who uses it, and we would rather give one honest estimate than a fast number we quietly revise later.

How we work at Jar Agency

We are a full-cycle digital agency in Tashkent. Design sits alongside web and app development, video production, and marketing, so an interface can go from concept to built product without being handed between companies.

Our work includes LoadMe, an application for carriers with 7,946 app users, where interface decisions had to hold up for drivers using the product on the road; MSC in B2B medical equipment; Leader Audit in professional services; and Yoldosh in logistics.

If you are not sure whether you need a redesign or a smaller set of fixes, start with a conversation about what is actually going wrong. Sometimes the answer is three screens, not thirty.

Как это выглядело у клиентов

Частые вопросы