UI/UX and design systems
UI/UX Design and Design Systems
Information architecture, interaction design, visual design, and the component libraries that keep interfaces consistent as a product grows.
Run sheet · UI/UX & design systems
Where the work starts
Information architecture first
Before anything looks like a screen, we work out how content and features are organized and how people move between them. Navigation, page hierarchy, labeling, and search all live here. Get this wrong and no amount of visual polish rescues the product.
For complex applications, information architecture is where most usability problems are actually solved. A dashboard that buries the main task three clicks deep is a structure problem, not a styling one. On most engagements we start by mapping the jobs a person arrives to do, then decide which of them earns a top-level destination and which belongs one level down.
What the structure decides
- Which tasks get a top-level destination
- How navigation labels read to a first-time visitor
- Where search earns its place, and where it does not
- What a signed-in user sees first after login
- How deep a settings or admin area can go
Interaction design
Interaction design covers what happens when someone clicks, submits, drags, or makes a mistake. States matter: loading, empty, error, success. Most frustrating software is frustrating because those states were never designed.
Loading
What the screen shows while data is still arriving, so nobody taps the same button twice.
Empty
The first-run and zero-result screens, with the next useful action offered instead of a blank panel.
Error
Plain messages that say what went wrong and what to do next, placed next to the field or action that caused it.
Success
Confirmation that the job finished, with the receipt, reference, or next step a person actually needs.
We define behavior for forms, tables, filters, and navigation, including the edge cases that come up in real use. It is unglamorous work and it is most of what makes an interface feel solid.
Because the states are written down before build, developers implement the awkward paths on purpose rather than discovering them a week before release.
Visual design and consistency
Visual design comes after the structure holds up. Type, spacing, hierarchy, and component appearance are applied systematically rather than screen by screen, so the product looks like one thing rather than a collection of pages.
Consistency is not decoration. When buttons, form fields, and messages behave the same way everywhere, users stop having to relearn your interface on every page.
Type scale
A fixed set of sizes and weights, so a heading is a heading wherever it appears and body text stays readable at 16px or above.
Spacing scale
One rhythm for gaps and padding, so screens built by different people still sit on the same grid.
Colour roles
Named roles rather than loose swatches, so a state colour is never reused as a brand surface by accident.
Component appearance
Buttons, fields, and messages that look and behave identically in every context they are used.
What a design system contains
A design system is a working library, not a PDF. It contains components with defined behavior, spacing and type scales, form and table patterns, and rules for how components combine. Developers build from it, designers extend it.
The payoff shows up later. Adding a new screen to a product with a design system takes a fraction of the time it takes without one, and the result matches everything already shipped.
A system stays useful when
- Every component documents its states, not only its resting look
- New patterns are added by extending what exists
- Design and code share one source for each component
- Someone owns the library after launch
Testing with real users
Where budget allows, we test designs with people who resemble your actual users. Sessions are task-based: can this person complete the job the product exists for? What confused them, and where did they hesitate?
Testing catches problems that internal reviews miss, particularly around forms, error messages, and navigation labels. Fixing a flow before build is far cheaper than fixing it after launch.
Sessions are run on a build or a clickable prototype, recorded with permission, and written up as a short list of findings ranked by how often each one blocked the task. Where a pattern repeats, we change the component rather than patching the single screen.
Responsive and cross-platform design
Interfaces get used on phones, tablets, and desktops, often by the same person across a single day. We design components with their small-screen behavior defined from the start, rather than compressing a desktop layout after the fact.
This applies to internal tools too. Staff checking a request queue on a phone between meetings is a normal use case, and the design should not punish them for it.
In practice that means defining how each component reflows, what collapses into a menu, which columns drop out of a table, and what stays reachable with one thumb. Those decisions belong in the component library, not in a note for each screen.
Design handover to development
Handover is a process, not a folder of files. We work alongside developers during build, reviewing implementations against the design and resolving the ambiguities that always appear when static screens become working software.
Where teams use shared component libraries, design and code stay in step. Where they do not, drift sets in, and the shipped product slowly stops matching the design that was approved.
How handover actually runs
- Step 1 Components and tokens are handed to the build team with their states defined
- Step 2 We review built screens against the design while they are still cheap to change
- Step 3 Ambiguities are resolved in the shared library so they stop repeating
- Step 4 The library is documented for the team that keeps shipping after us
Questions we get before a UX project starts
Can we start with design before the requirements are fixed?
Usually yes, with a caveat. Information architecture needs to know which jobs the product exists to do, so we start with a short scoping conversation and a written list of user tasks. Screens come after that list is agreed. If the requirements genuinely are not settled, the cheapest first step is a structure review rather than visual design.
How long does a design system take to build?
It depends on how many component families the product actually needs. A focused system covering forms, tables, navigation, and messaging is a different job from a full library for a large application. We scope it against the screens already on the roadmap, so the system is built for work that exists rather than for a hypothetical catalogue.
Do you redesign existing products or only new ones?
Both. On existing products we usually audit the structure and the component inventory first, then fix the patterns that cause the most repeated support questions. A wholesale redesign is sometimes the right answer, but it is rarely the first move, and a structure fix is often cheaper than a new visual layer over a confusing one.
Where does user testing fit if the budget is tight?
Even a handful of sessions on a clickable prototype tends to surface the same issues that internal review misses, especially around forms and navigation labels. If there is no room for testing at all, we say so at scoping rather than promising findings we cannot produce, and we flag the assumptions that are then left unverified.
Structure first, then components, then polish — in that order.
Bring us a product, a prototype, or a backlog of screens that no longer match each other. We will tell you which of the three layers needs attention first.
Start with a scoping conversation
Tell us what the product has to do and who uses it. We will come back with the structure questions that need answers first, and an honest view of what the design system should cover at this stage. No booking form on this page — the conversation starts on our contact page.
Monday to Friday, 9:00 AM – 6:00 PM · Isani-Samgori district, Vazisubani microdistrict IIa, building 23, apartment 52, Tbilisi, Georgia