UI and UX design that reaches production
Five tools and one method sit in this cluster, and none of them is what you buy. The decision that costs money is whether you adopt somebody else's component library, a ready-made set of buttons and forms, or own a design system yourself. What you buy is an interface an engineer can build that survives real data, real latency and a keyboard.
01Capabilities
Four jobs, and the tool is the smallest decision in each
Design here is not a phase that hands a file to a build team and leaves. It sits inside an engagement that ends in production, which changes what we are on the hook for.
Interfaces for dense, operational software
Dispatch boards, back-office consoles, clinical and admin screens, used all day by trained people rather than judged in three seconds by a stranger. The work is information density, keyboard efficiency and error prevention, in logistics and healthcare alike.
Design systems and component libraries
The shared components, their naming and composition rules, and the accessibility requirements underneath them, implemented in code as well as drawn. That is design system work; a page in a design file labelled Design System is a library, not a system.
UX reviews of products that already exist
Plenty of what we are asked to look at is live and disappointing somebody. A structured pass against Nielsen's ten usability rules turns a vague complaint into a located, severity-rated list in days. That is where a UX audit starts.
Handoff an engineer can build from without guessing
Empty, loading, error and overflow states, spacing rules, breakpoint behaviour, focus order, and which of two similar components is correct. Recorded in Figma, then proved in the browser. If an engineer has to invent a decision to finish a screen, the specification failed.
02Stack
Six pages here, and only two of them are a decision you make
One row per page in this cluster. Two describe a choice you have to take. The other four are tools we work in, and we would rather say so than dress them up as options. Every row is a single link.
| Tool or method | What that means in practice |
|---|---|
| Material UI | Adopt itThe ready-made buttons, forms and tables we reach for on internal and back-office products built in React.Material UIOr book a meeting |
| Nielsen's ten heuristics | Review firstTen usability rules, applied as a structured pass over the running product. It locates the problem before anyone redraws it.Heuristic reviewOr book a meeting |
| Figma | Our tool, not your choiceWhere we settle flows, states and layout while changing them is still cheap. How we work, not something you buy.Figma handoffOr book a meeting |
| Storybook | Above one teamA catalogue of the components as built. It earns its upkeep once several apps or teams consume the same ones.StorybookOr book a meeting |
| Adobe tools | Asset work onlyIllustration, motion and image production inside a brand that already exists. If you need the brand itself created, that is a different practice.Adobe toolsOr book a meeting |
| Midjourney | Never as evidenceGood for exploring a direction and for editorial illustration. Wrong anywhere a reader could fairly take the picture as proof.Generated imageryOr book a meeting |
03Fit
The decision is adopt or own, not which tool
Nearly every question in this cluster is one question wearing different clothes: is your interface part of what you sell, or is it a cost of operating the business? The answer decides whether you build a design system, adopt somebody else's components, or leave the interface alone and fix something upstream of it instead.
| Your situation | What we recommend |
|---|---|
| Internal or back-office tool, used all day by trained staff, with no designer on the team | AdoptTake somebody else's components rather than build your own. On React that is usually Material UI. The weeks you save belong in the data model and the workflows, where this kind of product is won or lost. |
| Consumer or brand-led product where the interface is part of your credibility | Own itA bespoke design system. Theming somebody else's design language hard enough to look like you costs more than owning your components from the start. |
| The product is live, people complain, and nobody can say precisely where | Review firstNot a redesign. A heuristic review first, then a UX audit that groups the findings into the few causes underneath them. Redesigning before you know the cause is how you pay twice. |
| One app, one small team, a dozen components | No catalogueSkip it. Storybook earns its upkeep when several apps or teams consume the same components. Below that, one internal route that renders everything gets you most of the value. |
| You need a full brand identity, naming and print material | A brand studioWe work inside a brand that exists and produce what a product needs, including asset production in the Adobe tools. An identity programme is cheaper to place now than in month two. |
| You need imagery a reader could reasonably take as evidence of a real thing | Photograph itGenerated imagery from Midjourney is good for exploration and editorial illustration, and wrong for real inventory, real property, or anything clinical. |
Scope
unicrew runs four design services, deliberately different sizes. Product design builds the interface. UX consulting and audit reads one that already exists. Design systems covers the shared components and the colour, spacing and type values under them. Design sprints test a direction before anyone commits a quarter to it. What we own across all four is the part after the file. Accessibility is checked on the built page, because what a keyboard and a screen reader do with a screen does not exist inside a design file. Layout is checked with real content, because the words in a mockup are always the flattering length. When the design and the running product disagree, we say which one is wrong and fix it rather than maintain two drifting descriptions of one interface. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK.
04Delivery
How design ownership works when the same partner builds it
The reason to keep design and engineering inside one engagement is that nobody gets to hand a problem across a boundary and call it solved. Four steps, and the order carries most of the value.
- Read the product before drawing anythingWalk the flows that carry the money, with real data and on a real device, against the ten usability rules. On an inherited product that takes days, and it often changes the brief. Sometimes the UX audit is the whole engagement.
- Settle the interface while it is still cheap to changeFlows, states and layout decided in Figma, with the unhappy path written down instead of discovered in a ticket: empty, loading, error, permission denied, four hundred rows. Dense products such as warehouse management systems live or die on those states.
- Prove it in the browser, not in the fileReal content, real latency, real error responses, keyboard only, then a screen reader. Nothing is settled until it has been built and used. Where more than one team consumes the components, the catalogue moves into Storybook and the design file stops being the source of truth.
- Name who owns the driftComponents marked canonical or deprecated, the catalogue rebuilt on every change so a broken component fails like a broken test, and one named person accountable for the gap between what is drawn and what ships. Drift is not a tooling problem, it is an unowned one.
05Case studies
The two design engagements we can point at
Two published studies name a member of this cluster in their own technology list. One carries a figure and one does not.
See all case studies
Food productionUX Audit for a Catering ApplicationBy addressing user feedback, improving key functionalities, and implementing targeted design changes, the application is poised to meet its business objectives and provide a superior user experience.
LogisticsApp Store for warehouse managementOur client Bitergo offers a collection of business apps to optimize warehouse management, scalable from start-ups to 4PL companies. Given the business drivers, the client decided to upgrade the front-end of all their applications to the latest version of Angular.Rapid increaseOf test accounts ordered by potential customers after the site launched
There is one expensive decision on this page and it is not a tool. Either you adopt somebody else's component library and live inside its opinions, or you own a design system and pay for the versioning, the owner and the breaking-change policy that come with it. What I see fail is the middle: adopting a library and then overriding it into your own brand, which buys the cost of both and the benefit of neither.
Andrii BurdaSenior Engineering Manager, unicrew06Questions
Questions that come up when the tool is not the decision
You can bring our designers onto your team, and engagements do start that way. What does not happen is a handover of people with the result left as your problem. A design lead outside the delivery team reviews what ships, and front-end work goes through the same QA practice as our own projects. Extending your team is managed teams; owning the outcome is product design.
Ask who looks at your interface, and for how long. Your own staff, all day, in a tool they know: adopt a library. Prospects deciding in ten seconds whether you are credible: the interface is part of what you sell, and a design system of your own earns its cost. The expensive answer is the middle, a brand-led product on a heavily themed library, where you pay for somebody else's constraints and for custom work at once.
In the specification far more often than in the tool. A file records the happy path at a flattering content length. Production has empty states, four-hundred-row lists, failed requests and somebody tabbing through with a keyboard. If those were never written down, every engineer resolved them differently and all of them were guessing. The fix is a better handoff plus one catalogue of the components as built: Figma and Storybook are the two halves of that contract.
Not as a practice, and we would rather say so before you buy anything. Our design work is product design: interfaces, design systems and the assets those need, with asset production in the Adobe tools. We work inside an existing brand book, including translating print-first material into web colour, spacing and type values. A full identity programme wants a brand studio.
A scoping call with the people who would do the work. If a product already exists we ask for access beforehand, because an hour spent using it beats three spent hearing it described. What comes back is written: what we would review, what we would design, and what we would leave alone. Work usually starts two to four weeks after we agree scope.
Services we deliver in UI / UX
All servicesDeciding between adopting components and owning a design system?
Tell us what the product is and who uses it for how long. You will get a straight call on adopt versus build, what we would review before designing anything, and what we would own to get it into production.