Duova LLC Duova LLC Digital product studio
A hand placing a small matte object onto a dark felt tabletop, the rest of the scene still

Process, from brief to launch

How Duova LLC takes a project to launch

The workflow below is what we actually run, not a sales diagram. It applies whether you have hired us for a full product build or just the UX/UI design half.

A designer's hands arranging blank paper cards on a dark felt surface
Structure before surface Low fidelity first

Discovery before anything gets designed

We start with what you are trying to change, not what you want built. Who uses this, what do they do today instead, and what does success look like in twelve months. For Singapore clients this usually includes a look at local competitors and at what customers expect from a business like yours.

Discovery output is a written scope: deliverables, assumptions, what we need from you, and a timeline. If the scope does not survive that conversation, better to find out now than in month three. That document becomes the reference we come back to whenever a later decision pulls in two directions.

What you get back

  • Deliverables The pages, screens or systems we will hand over, named one by one.
  • Assumptions What we are taking as given, so nobody argues about it later.
  • What we need from you Content, access and decisions, with an owner and a date for each.
  • Timeline Phases in order, with the review points where you are needed.

Information architecture and content structure

Before wireframes, we map the structure. What pages exist, how they relate, what a visitor needs at each step, and where the conversion points sit. This is where most website problems actually live, and it is cheap to fix here.

For e-commerce projects this covers category hierarchy, product attributes and the path from listing to checkout. For apps it covers the navigation model and a full screen inventory.

A wall of blank paper cards arranged in columns and rows, photographed at an angle

For a website

Page list, navigation, the job of each page, and the points where you want someone to act.

For an app

Navigation model, screen inventory, and what happens when a screen has nothing to show yet.

Wireframes: low fidelity on purpose

Wireframes are grey boxes and real copy. No visual design, no brand decisions. The point is to argue about structure and priority while changes cost nothing.

We keep them low fidelity deliberately. Clients who see a polished mockup at this stage comment on the shade of blue instead of whether the form has too many fields. Grey boxes keep the conversation on the questions that still matter: is this the right order, is anything missing, and does the page ask for more than it gives back.

A hand gesturing over a dark felt table with blank paper cards nearby

Prototypes and usability testing

Once the structure holds, we build a clickable prototype and put it in front of real users. Five to eight people per round is usually enough to surface the flow problems worth fixing. Findings get logged with severity, not as opinions.

For Singapore clients we can run sessions remotely or in person. Remote is faster; in person catches things people do not say out loud. Either way you get the recordings and a short written summary of what broke and what we changed because of it.

Design system, then build and front-end development

Visual design happens after the structure is agreed. Development runs against the approved design system and prototype, so the two stages do not fight each other.

Design system

Type scale, spacing, colour roles, component states, form behaviour and error handling, written as a working system rather than a style guide PDF nobody opens.

Why it matters as you grow

A design system is what keeps the twentieth screen consistent with the first, and it is what your developers will reference long after we are gone.

Build and staging

Staging links go live early so you can click through progress instead of waiting for a reveal. Weekly written updates, plus a call when there is a decision to make.

CMS and admin setup

The parts your team will use daily get built here too. If the admin is painful, the site rots after launch regardless of how good the front end looks.

Web development, e-commerce builds, mobile applications and UX/UI design all run through this same sequence. The difference is what gets drawn in each phase, not the order of the work.

A quiet desk with a closed laptop and coiled cable under a single pool of lamplight

Handover, documentation and launch

Launch is a checklist, not a moment. Domain, DNS, analytics, redirects, form delivery, email routing, backup schedule. We document what was built and how to change it.

Handover includes the design files, component documentation and a walkthrough with whoever will maintain the site. If that is an external team, we will run the session with them directly rather than through you.

On the launch checklist

  • Domain and DNS pointed and verified
  • Redirects carried over from the old site
  • Form delivery and email routing tested end to end
  • Analytics running and backup schedule set

After launch

We are not a maintenance contract business, but we do not vanish. Bug fixes in the weeks after launch are included. Beyond that, most clients come back for a second phase or a retainer when priorities shift, and we pick up from the same documentation we left behind.

Questions clients ask before we start

Short answers to the things that usually come up in the first conversation.

Do we have to run every phase?

No. Some clients arrive with a structure and a prototype already agreed, and we start at the design system. Others need discovery and information architecture only, then hand the output to their own team. We will say so in the scope rather than sell the full sequence by default.

How much of our time does this take?

You are needed most at discovery, at the wireframe review and at the prototype findings session. Between those, most of the work is ours. Weekly written updates mean you can follow progress without a standing meeting every week.

What happens if the scope changes mid-project?

Scope changes are normal. We write them down, say what they move and what they push, and you decide before we build them. Nothing gets added quietly, and nothing gets removed quietly either.

Can you work with our existing developers?

Often, yes. On design-only projects we document components and states so an internal or external team can build against them, and we join their standups during the build phase if that helps the handover land.

Bring us the problem, we will write the plan

Tell us what you are trying to change and who it is for. We will come back with a scope you can read in ten minutes: what gets built, what we need from you, and when each part lands. Duova LLC (Webu) works with Singapore-based SMEs and enterprises across web development, e-commerce, mobile applications and UX/UI design.

Studio details

Address 40 Zhuli Shartava St, Tbilisi, Georgia
Hours Monday to Friday, 9:00 AM – 6:00 PM