Product design by people who also have to build and run it
Product design is the set of decisions about what a product does and how it works. Five ways to buy them: validate an idea, design a whole product, draw the screens, diagnose a live one, or systematise the parts.
01Work
What has to be true for a design to survive the build
Four things, and they are the same four whether our designers draw it or yours already have.
Drawn against the real data
Real record counts, real latency, the account with more rows than the table was drawn for. A screen designed against six tidy rows of sample data gets redrawn in the first sprint, usually by whoever is implementing it.
Accessibility as decisions, not a later score
Contrast, focus order, target sizes and what each control announces are decisions somebody makes, either while the screen is still a drawing or after an audit has named them. On financial-services work they tend to arrive as a procurement question, with a date attached.
The direction can stay yours
Not all of this work starts on a blank canvas. It starts in somebody else's file: a style guide and UX concept from the client's own designer, or a component set that already exists and has to be mapped onto a legacy screen without losing what that screen did. We add the implementation and the cases nobody drew.
Validated before it is expensive to change
A design sprint puts a prototype in front of real users and ends in a decision. The alternative is finding out after the build, when the sunk cost is already in the room and arguing on its own behalf.
02Services
Five services, arranged by how much you already know
The five differ by how much is already settled when you arrive, not by size and not by budget. One row per service page, and the middle column is the deciding one: find the situation you are actually in, then read across.
| Service | What you are actually buying |
|---|---|
| Design sprint | The idea is unprovenThe unit of work is a decision. A fixed window, a prototype in front of real users, and a call on whether to build at the end of it.Design sprintOr book a meeting |
| Product design and development | From an idea to a productOne accountable engagement from discovery to a running product. Most of the argument is sequencing: what ships first, and what the first release leaves out. A salon booking platform we built end to end runs 200-300 bookings per vendor a month.Product design and developmentOr book a meeting |
| UX/UI design | The what is settledInterface design where the product decision is already made and the question is how it should work and look. A European climate-tech CTO on the result: customers "love the UI and speed".UX/UI designOr book a meeting |
| UX audit and consulting | It is live and leakingA diagnosis of where users give up, and a prioritised plan. What you buy is a finding rather than a redesign, which is why it is the first purchase to consider when something exists and underperforms.UX audit and consultingOr book a meeting |
| Design systems | Several teams, one brandComponents, tokens and rules that several teams can build from without redrawing the same button. More than 15 warehouse-management applications reused many of the same modules and components, so we built the universal set in Storybook and integrated it into each app's new grid.Design systemsOr book a meeting |
03Fit
What each design request actually needs
The right-hand column is our call on each: the service that fixes the cause, whichever practice it sits in.
| Your situation | What we recommend |
|---|---|
| Conversion is dropping and the design is blamed | Diagnose firstThe design is the visible part, so it takes the blame. A UX audit names the step people actually leave on, so the fix goes exactly there. |
| The interface is fine and the pages take six seconds | Speed firstNo visual change survives that. Speed is the interface at that point, and it is an engineering fix, so the budget goes to the cause first. |
| Two people internally disagree about what the product is for | Settle it firstDesign surfaces the disagreement; a design sprint or business analysis settles it before anybody draws, so the product is designed once. |
| One product, one team, and someone has proposed a design system | Start with a libraryA design system is a coordination tool, and it pays off once there are teams to coordinate. For one product, build the component library it needs, and formalise it into a design system when the second team arrives. |
| Accessibility has become a procurement or legal requirement | Design it inContrast, focus order, target sizes and what each control announces get decided either at design time or by whoever is reading the audit. On four corporate websites for a financial-services group, accessibility implementation sat inside our build scope, and the client reports the accessibility scores are top-notch and user engagement higher. |
| Designs keep arriving that the engineers cannot build as drawn | One teamFeasibility arrives late when design and engineering are two separate purchases. Buying them as one engagement settles it while the screen is still a drawing, because the people who draw it and the people who build it are one team. |
How we work
unicrew is 100+ senior in-house engineers across six countries, working under ISO 27001:2022 and ISO 9001:2015, both audited by Quay Audit UK. ISTQB-certified QA sits inside every sprint, on every engagement. There is no minimum engagement period. Three ways to be billed: time and materials, billed hourly and quoted per project; fixed price, quoted per project against the outcome; or team extension, billed monthly per team member. Most engagements start within two to four weeks.
04Handoff
What a design handoff has to contain, whoever drew it
Four artifacts, and the list does not change direction: this is what we hand your engineers, and what we ask for when the design is already yours.
- Every state, including the ugly onesEmpty, loading, partial, denied, too long, and failed. Mockups show the happy path; products spend most of their time outside it, and an unspecified state is where a design quietly stops matching the build. We need the states your data actually produces, including the ones nobody enjoys demoing.You getState coverage per screen
- Tokens and components, not measurementsNamed decisions rather than pixel values, so an engineer meeting a case nobody drew can infer the answer instead of inventing one. That is what a design system is, and why it outlives the project it was drawn for. If you already have one, we extend it rather than start a second.You getA token and component set
- The accessibility decisions written downContrast, focus order, target sizes and what each control announces, decided per component and recorded where an engineer will find them. An audit later asks for the same decisions, in a document with a date on it. Tell us which standard you are being held to, and by whom.You getAccessibility notes per component
- The reasoning, so it can be argued withWhy this pattern and not the obvious one. A handoff without reasoning gets overruled by the first stakeholder with a strong preference, and nobody in the room can say what the alternative gives up. Where one of your preferences is really a constraint, say so and it stops being a debate.You getRationale alongside the design
A good design handoff covers more than the happy path. It specifies the empty state, the error and what happens when a name is forty characters long. Because we also build what we design, we settle those states before engineering starts.
Yaroslav HavrylivSenior Engineering Manager, unicrew05Proof
Interfaces we built, some to our designs and some to theirs
- FintechFour corporate websites for a financial-services group, with accessibility inside the build scopeunicrew handled the technical build of four corporate websites for a German financial-services group, with accessibility implementation, responsive layout and technical QA inside the scope.
- HospitalityA salon booking platform doing 200-300 bookings per vendor a month (Lookgood)unicrew built Lookgood's salon booking platform from start to finish, with real-time availability, SMS reminders, and scheduling that respects shared equipment.200-300Bookings per vendor each month
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
06Clients
Five clients on interfaces we built, and no two bought the same thing
All four websites have successfully passed internal reviews and are online. The accessibility scores are top-notch, and the user engagement is higher. They’ve delivered on time, been flexible when we needed adjustments, and made the entire collaboration feel smooth and supportive.
We’ve seen enhanced customer satisfaction thanks to unicrew’s work. Our customers love the UI and speed of the application. We’ve received positive feedback, and there are no errors in the system. unicrew meets their deadlines and stays on budget.
Our website’s overall functionality has been improved both in frontend possibilities and user experience as well as backend aspects of website management and financial monitoring. These are not easily qualitfiable but there has been a net gain in available staff hours for alternative projects as a result of improved website abilities reducing workload.
The goal was to replace legacy UI elements with new UI components. The new UI components already existed, key challenge was to map the existing implementations to the new ones while not losing functionality. They were super responsive and did exactly as we agreed upon. The colleague they send to us was an extremely good fit to the problem that we have described.
After launching the site we saw a rapid increase of test accounts ordered by potential customers. Now the site provides a steady source of sales leads.
07Questions
What teams ask before commissioning design
Five, and they are different purchases rather than different sizes of one. A design sprint buys a decision. Product design and development buys a running product. UX/UI design buys the interface itself, once the product decision is settled. A UX audit buys a finding about something already live. Design systems buys the components and rules several teams build from.
The half that has to survive engineering, usually. On four corporate websites for a financial-services group, the client's own team produced the UX concepts and our scope was the build: front-end and back-end, accessibility implementation, responsive layout, content integration, analytics setup and technical QA. We also extend a design system somebody else started, or put designers alongside yours under team extension. What we ask for is that whoever owns the brand decisions is reachable, because the expensive delays in design work are approval delays rather than drawing ones.
Usually that is the better purchase. A UX audit starts from the live product and ends in a ranked list: what to change, in what order, and why that one first. Any redesign that follows then starts from what the audit found, so it is aimed at the number you were worried about.
As a set of decisions with names on them: contrast, focus order, target sizes and what each control announces. They belong in the handoff next to the states and the tokens, and they leave as accessibility notes per component. Where a formal conformance level against a named standard is needed, we build and document to that standard, so you can make the conformance statement about your own sites with the evidence behind it; tell us early which standard you are being held to and by whom.
Three models, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project. Fixed price is quoted per project against the outcome, which needs a scope firm enough to fix. Team extension is billed monthly per team member, which is the one that suits a designer working alongside your own people. There is no minimum engagement period. On timing, most engagements start within two to four weeks.
What teams usually pair this with
All servicesTell us what is already settled
Send the Figma file, the URL, or the paragraph you would write to explain the idea. A designer and an engineer read it together and tell you which of the five this actually is, and where to start.