AURA
Aura Business Intelligence
UI/UX design
Interface design for website, app or panel: first flows and clickable prototype, only then graphics.
Analizuję dane publiczne i to, co sam opowiesz. Numeru telefonu w pierwszej wiadomości nie proszę.
„Od przedsiębiorcy dla przedsiębiorców.” CEO Aura
Części jednego systemu
Aura · AI-konsultantRzucę okiem na Wasz lokal — powiedz nazwę. Czeka
UI/UX designWhat AURA does in this area

UI/UX design

Interface design for website, app or panel: first flows and clickable prototype, only then graphics.

  • individuallyScope
  • Websites and brandingArea
  • 6 hours – 2 daysLaunch

Who this is for

Digital products, SaaS and internal business systems.

Problem

Users get lost and don't complete actions. In digital products, SaaS systems and internal panels it's rarely about looks — it's about the screen being created as a list of fields to save to a database, not as a path someone should follow. The team knows shortcuts and doesn't see the problem; new people need training to perform actions repeated ten times a day. Empty states, errors and "nothing here yet" screens usually have no design at all, so they're created in code, quickly.

What we do

We design interface from flows, not from screens: first we determine who should achieve what and in how many steps, and only then we draw.

  • Task flows: user goal, subsequent steps and places where they can be shortened
  • Wireframe before graphics, so layout disputes don't become color disputes
  • Clickable prototype to walk through scenarios before anything goes to code

What's included

Five stages in fixed order; each subsequent one closes decisions from the previous, so nothing returns to the board twice.

  • Flow: user paths and all states, including empty and error
  • Wireframe: screen layout and content hierarchy without graphics
  • UI: grid, typography, colors, components and consistent control states
  • Prototype: clickable version on which you can walk through a real scenario
  • Tests: walking through scenarios with people outside the team and fixes based on results

How long it takes

Implementation takes 6 hours – 2 days. The bottleneck isn't drawing, but decisions on your side: how many roles in the system, what each sees and which features go into the first version. That's why we start with these questions. We plan prototype tests in advance because gathering a few people outside the team can take longer than the design itself — and without them you get opinions, not results.

How much it costs

What decides is the number of screens, the scope of research and whether a clickable prototype is needed or a static design is enough. Redesigning an existing panel we quote after looking at what already works — often it is enough to fix a few screens instead of drawing them all again, and we say so before the start.

What you get

Easier use and higher conversion: fewer abandoned forms and fewer support questions about things that should be visible on screen. Developer gets complete set of screens with states instead of description in email, so they don't fill in missing decisions themselves — and this is the cheapest moment to make them. Onboarding new people no longer requires someone who knows the shortcuts.

When a UX redesign is not worth it

Four situations where we recommend waiting:

  • The site gets very little traffic, so the changes cannot be meaningfully tested anyway — traffic has to come first.
  • The product is about to undergo a complete business model change — designing flows for features that will soon disappear is work headed for the trash.
  • There is no one on your side to implement the finished design in code — a prototype without implementation stays a file.
  • The team is not ready to accept that some existing decisions will turn out wrong — without that, user testing hits a wall.

None of these situations is a permanent verdict — sometimes it just means waiting for the right moment rather than dropping the project altogether.

Formula: what a hard-to-use form costs

Formula: Lost submissions = Number of form starts × Abandonment rate × Average value per submission. The number of starts and the abandonment rate show up in Google Analytics (form-start and form-submit events); the average value per submission is your own number from CRM or sales, not ours.

The same formula works in reverse: cut the abandonment rate by even a few percentage points, and the result immediately shows how many extra submissions that means per month — with no assumptions about design quality involved at all.

What we need from you

Four things without which the work either does not start or stalls at approval:

  • Access to analytics (Google Analytics or similar) with at least a few weeks of traffic history.
  • Access to the panel, CMS or repository, if we are redesigning an existing product rather than a brand-new site.
  • One decision-maker on your side who signs off on flows — spread-out responsibility drags out every stage.
  • A list of technical constraints (framework, component library, if one exists) — the design has to be implementable in what you already have.

The earlier these four points are ready, the less time gets spent clarifying decisions mid-project instead of before it starts.

How to check the effect after a month, without us

Formula: Task completion rate = Number of users who reached the goal / Number of users who started the scenario × 100%. You define the goal and the starting point yourselves (for example, adding a product to the cart and paying for the order) and track it in the analytics tool you already have — no extra software needed.

It is worth comparing this metric before and after launch for the same traffic segment, mobile-only for example — otherwise the difference in the result might come from a shift in traffic sources rather than the design.

What UX/UI does not do

The boundaries we state plainly:

  • It does not write copy or sales offers — we design the structure that finished copy gets placed into.
  • It does not guarantee a specific conversion increase or a timeframe for when it will show.
  • It does not replace implementation — a clickable prototype still has to be coded.
  • It does not cover testing after every subsequent product change once the project is finished — that is a separate order.

We set these boundaries before the start, so neither side assumes something the other never promised.

The typical mistake when ordering a redesign

The most common mistake is ordering a visual refresh instead of fixing the flows. The screen looks more modern, colours and typography change, but the user's path and the drop-off points stay exactly the same — the problem just gets nicer packaging. The consequence is costly: the company pays once for the visual refresh, then a second time for the flow design that should have been done from the start.

The cost of this mistake grows with the size of the product — the more screens the reskin touched, the more of them need redesigning a second time.

Full redesign versus targeted fixes — a comparison

Four routes, each with a different scope and a different outcome:

  • A full redesign starting from flows — fixes the root cause, but demands the most time and decisions from you.
  • A heuristic audit with targeted fixes — faster and cheaper, but does not touch mistakes baked into the product's structure.
  • User testing without any design changes — a cheap source of insight into the problem, but fixes nothing by itself.
  • Changing only the visual layer (a reskin) — improves the look, leaves the same paths and the same drop-offs.

The choice between them depends on whether the evidence points to a cause in the product's structure, or only in the visual layer.

Accessibility and edge states: what's usually missing

The contrast formula from WCAG 2.1 (criterion 1.4.3): Contrast = (L1 + 0.05) / (L2 + 0.05), where L1 and L2 are the relative luminance of the lighter and darker colour; for regular text the result should be at least 4.5:1. This is calculable with free tools built into any browser — it is not a matter of taste.

  • Empty state — what the user sees before adding anything.
  • Error state — what happens when saving fails.
  • Loading state — what's visible before the data appears.
  • No-permission state — what someone sees when they lack access to a given feature.

What you get

  • Flow map and wireframes for the key screens
  • UI design and a system of reusable components
  • Clickable prototype and implementation handoff materials

When the problem lies elsewhere

If your problem sounds different, neighbouring areas of the same system stand right next to it — AURA connects them to each other rather than selling them separately:

  • 3D Animations — 3D objects, scroll animations and interactive scenes on the website — for brands that don't want to look like everyone else.
  • UX and conversion — We look for reasons why visitors don't leave an inquiry and remove them one by one — instead of rebuilding the whole site by feel.
  • Websites and stores — From landing page for one offer to online store with catalog and payments. Website built around one decision, not around a photo gallery.
  • Landing page — One page for one campaign: the same promise as in the ad, one goal, and nothing to distract from it.

Next step

Tell us how this process looks at your company today: how many enquiries come in, who answers them and where they get lost. We will tell you what can be taken off a person, what is not worth touching, and how this area fits into the rest of the system.

Talk to Aura →

marketing@auraglobal-merchants.com · +48 793 536 034

Next step

Let us check whether Aura fits your place

We do not take everyone: first we look at your processes, sales and current systems and tell you honestly whether it makes sense for us to come in. A few questions, about five minutes.

Take the assessment →

Navigation