October 08, 2026
The UI UX design process has four steps. Find out who the site is for and what they need to do (discover). Decide which pages exist and what goes on each one (structure). Design the screens people will see (design). Hand over files a developer can build from without guessing (handover). Everything else in a design project is detail inside those four.
Rather than describe the steps in the abstract, this article follows one real project through all of them: the website for Asia Pacific Ceramic, a tile exporter whose site runs in seven languages from one codebase, including a fully mirrored right to left Arabic edition, with an e-catalogue, packing details and a coverage calculator for importers. The screens are in the case study on our portfolio.
Design is where the money you spend on a website is either saved or wasted. A screen that is redesigned after it has been built costs three times what it cost to design. That is the reason the steps run in this order.
UX is what the visitor is trying to do and whether the site lets them do it in the fewest steps. UI is what they see and touch while they do it.
Here is the difference on this project. An importer looking at a tile wants to know the size, the finish, how many pieces come in a box, how many boxes fit a pallet and a container, and how many square metres a given order covers. The UX decision was to put the packing details and a coverage calculator on the product page itself, next to the specification, rather than in a PDF the buyer has to download and open. The UI decisions were what the calculator looks like: which fields it asks for, the size of the tap targets on a phone, how the result reads, what the download button says.
You can get one right and the other wrong. A beautiful site that buries the calculator three clicks deep has good UI and bad UX. A calculator on the right page that is hard to read on a phone is the reverse. The design process exists to get both right, in that order, because a wrong structure cannot be rescued by a good screen.
The four steps, with what each one produces:
1. Discover: a short written brief that says who the site is for, what they need to do, what the business needs from it, and what already exists.
2. Structure: a sitemap and wireframes, which are grey box layouts of every page type with real content and no colour.
3. Design: visual routes, then a design system, then every screen at desktop and phone size, then a clickable prototype.
4. Handover: the Figma files, the design system and the prototype, delivered so the site can be built by us or by anyone.
At Asket Studio a project begins with a conversation, then the brief, then a fixed quote with a timeline, and nothing starts until the client has both. A focused 5 to 10 page site is usually 2 to 4 weeks of design. A mobile app or larger product is 6 to 10 weeks. The same people who write the brief design the screens and build them, which is why the steps below read as one job rather than a relay.
Discovery is a conversation with the people who answer the enquiries, followed by a brief we write and the client corrects.
For Asia Pacific Ceramic the questions were about the buyer, not the tiles. Who sends an enquiry: an importer, a distributor, an architect, a project buyer? What do they need to know before they can decide? Which of those questions are asked by email today that the site could answer instead? Which countries and which languages? What does a buyer in one market expect that a buyer in another does not? What is on the current site and in the catalogue that must survive?
The answers set the whole project. Buyers needed specifications and packing details more than mood photography. They needed them in their own language, which is where seven editions came from, including Arabic, which reads right to left and changes the layout of every page. They needed the catalogue as something they could browse on a phone, not only a PDF, so the e-catalogue became a page type. And they needed to work out coverage and container quantities, so the calculator went into the brief.
The brief itself is short. One or two pages that say what the site is for, who uses it, what pages and features it needs, what content exists, and what success looks like in plain words. Both sides sign off on it, and it becomes the reference for every later decision.
Structure is a sitemap first, then wireframes.
The sitemap is a list of every page and how they connect: home, the product families and each product, the e-catalogue, packing and export information, about, contact, and each of these in seven languages under a clear URL pattern. Deciding the URL pattern here, rather than in development, is what lets one codebase serve every edition. Article 14 goes into that side of the build.
Wireframes are grey boxes with real content. No colour, no photography, no type choices: just what goes where and in what order. The Asia Pacific Ceramic product page wireframe placed the specification, packing details, coverage calculator and downloads in a fixed order on both desktop and phone, and the home page wireframe had one job: get a buyer from any country to the right product family in a single tap.
The client reviews the wireframes before any visual work starts. This is the cheapest moment in the project to move something, and the arguments happen here on purpose. Is the calculator above or below the specification? Does the language switcher belong in the header or the footer? Once these are settled in grey, the visual design does not reopen them.
Design begins with visual routes: two directions for the home page and one product page, each a complete answer to how the site should feel, so the client is choosing between real options rather than reacting to one. The chosen route becomes the design system: type, colour, spacing, buttons, form fields, cards, tables and the calculator, each defined once as a component and reused on every page.
Then every screen is designed at desktop and phone size, from the design system. Because the components are shared, a change to a button or a table updates everywhere, which is the only practical way to keep seven language editions consistent.
Arabic added a step of its own. A right to left edition is not text alignment. The reading order of the whole page flips: the logo moves to the right, menus open the other way, icons that imply direction are mirrored, the calculator's fields and result reverse, and numbers and units have to be handled so they still read correctly. The design system was built so that each component had a mirrored version, and the Arabic screens were designed as their own set rather than assumed from the English ones.
The step ends with a clickable prototype in Figma, so the client can tap through the site on a phone before a line of code exists.
At the end of design the client receives the Figma files, the design system and the prototype, in their own name. They can take those to any developer. When we build the site, the same people carry on into development, so the intent of every screen survives the build. That is also how the responsive build, the three phone image on every web case study, matches the prototype rather than approximating it.
At the end of development the handover widens: source code, hosting set up in the client's name, every credential, training for whoever will update the site, and documentation. Ongoing work is agreed separately.
For a focused 5 to 10 page site, 2 to 4 weeks of design, then a similar stretch of development. A designed 10 page site takes 3 to 5 weeks to build and test. A mobile app or a larger product is 6 to 10 weeks of design.
What stretches it is rarely the design work. Content arriving late stretches every step, because wireframes with placeholder text are guesses. Each additional language adds review time for the client's own people in that market. Each extra unique page type adds a wireframe, a screen at two sizes and a set of components. Revision rounds beyond the ones agreed add days. The brief and the fixed quote exist to catch all of these before they become surprises.
Yes, but on a small site it is a short step. Discovery is one conversation and structure is a few wireframes. Skipping it is how a five page site ends up with the phone number on the wrong page.
Whoever answers your enquiries, for an hour. The content you already have: catalogue, photos, specifications, the questions customers ask. The list of things the site must do. Decisions in writing, from one person.
Yes. The Figma files, design system and prototype are yours at handover, and they are built so any competent developer can work from them.
The four steps are the same. The differences are in scale and in what happens at each step: more screens and states, prototypes that are tested in the hand, and platform conventions for iOS and Android that the design system has to follow. It usually takes 6 to 10 weeks of design.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.