Interface design for your own dev team
You have your own developers and lack a well thought-out interface. We design the key screens, their states and a map of roles. We hand the output over in a presentation your team uses as the basis for the build.
Školní mapy, a concept for a digital school atlas. The design was made for a pitch and never built; we show it as a study, not as a launched product.
A design you can build from
On our own projects we do both the design and the build, so nothing falls between them. Some clients have their own developers and need only the first part. This service is for them.
What matters is what gets handed over. Key screens come with their states: what happens on a long name, how it breaks on a phone, what an empty list looks like and how a form behaves on error. A single pretty screen leaves those questions for the moment when answering them is most expensive.
The second half of the output is a map of states: who has which permissions, what states a record can be in and what happens when something is missing. Work can be planned from it, and it says what “done” means.
What your team gets
Four things a happy-path screen does not tell you.
Behaviour, not just looks
Transitions, button states, what happens on error and while waiting. A developer does not have to guess what belongs between two screens.
Edge cases named up front
An empty list, a long text, a missing value, a part-paid order. Otherwise these turn up in production.
Fewer meetings
Questions about behaviour have an answer in the handover, so the build does not stall waiting for one.
A brief that survives a year
A map of states still reads a year later, when nobody remembers why it is that way. Someone else’s code reads worse.
Six parts of every project
Scope varies, this is in every engagement.
A conversation about the user’s task
We start from what a person has to get done and how long it should take, not from a list of screens. The difference only shows in production.
A map of states and roles
Roles and permissions, states of a record from creation to archive including the awkward ones, and the places where another system is involved.
Key screens with their states
Loading, empty, error, success. For every screen that has them, not just the happy path.
Typography, colour and spacing as a scale
Not one guess per screen, but a set of values your team can also apply to what we did not design.
Behaviour on narrow screens
What stacks, what collapses, what disappears. Decided by us, not by whoever writes the CSS.
Handover and consultation during the build
We walk your team through the design and stay available for the questions that come up while building.
Interfaces we have designed
ELEN: an app redesign for procurementA new interface design for a procurement management app, on an identity by nkz.studio.
Walio: a loyalty system for businessesA card in the wallet, a terminal for staff and a portal with reporting.
Branuál: a brand manual as a website, not a PDFPages, blocks and an asset library with publishing. Our own product.
Školní mapy: an atlas that opens on the right pageA digital school atlas: layers, measuring and edition comparison instead of twenty separate maps.How the work goes
Every stage has an output we agree on.
First consultation
free · 30 min · online or in BrnoWe go through what the product has to do, who works in it and where your team is now. We say whether design is what you need.
Output: A recommendation on whether you need a design.
Brief and scope
3 to 5 daysWe write down which screens the design covers and what is out of scope. Then we prepare an offer with the agreed scope and price.
Output: A list of screens in scope and a quote.
Map of states
1 to 2 weeksRoles, states and integrations written as text, not in a drawing tool, because text is easier to cut. This stage saves the most.
Output: A written map of roles, states and connections.
Design
2 to 5 weeksOne key screen first. When it fits, the rest follows. Comments are collected as we walk through the presentation and the individual screens together.
Output: Designed screens in a presentation.
Handover
3 to 5 daysWe go through the design with the developers and hand over a presentation with the key screens and their states, the map of roles and states, and an arrangement for consultations during the build.
Output: A presentation with screens, states and the role map.
What it costs
The prices for each scope are indicative lower bounds, excluding VAT. They are not an offer: we price the work once the brief is clear. The calculator does not cover standalone design; we set its scope by the number of roles, screens and states.
One part of a product
One workflow, or one section of an existing application.
- A map of states for that part
- Three to five screens with their states
- A scale for colour, type and spacing
A whole product
An application or portal with several roles and connected processes.
- A map of states and roles
- Key screens for every role
- Interface states and behaviour on phones
What this connects to
When we will talk you out of it
When you want a few nice pictures for an investor deck and behaviour does not matter yet. Anyone working in a drawing tool will do that faster and cheaper.
When you are still looking for developers. Then design and build belong together; something always gets lost between two suppliers. In that case see custom applications.
When the real question is how the brand should look rather than how the product should work. Brand strategy, naming and visual identity are handled by our sister studio nkz.studio.
What people ask before a design
Did not find your answer? Write to us and we will reply within two business days.
What form does the handover take?
As a presentation with the key screens for desktop and mobile, including states such as loading, empty and error. Plus a map of states and roles in text and a scale for colour, type and spacing. We walk your team through it rather than just e-mailing it.
Do we have to use the same technologies as you?
No. The design is a specification of behaviour and appearance, not code to deploy. It can be built in whatever your team already uses.
What if something in the design turns out not to be buildable?
It happens, and it is why consultation during the build is included. We find a solution that keeps the original intent. Without that, teams usually reach for the first variant that is easy to code.
Do you run user testing?
It is not part of the base scope. If you want it, we arrange it separately and say up front what to expect from it at a given number of participants.
How long does it take?
One part of a product three to five weeks, a whole product five to eight. Most of it depends on how quickly the map of states is agreed; drawing the screens is the faster half.
Have developers and no design?
Tell us what you are building and where your team is now. The first consultation is free and takes 30 minutes. We reply within two business days and suggest the next step.