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.
Process, from brief 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.
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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
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.
Short answers to the things that usually come up in the first conversation.
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.
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.
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.
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.
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