Web UI/UX Design
A design that cannot be built as drawn is a document, not a decision. We do the drawing and the building in the same room.
- Typical duration
- Six weeks to six months
- Team shape
- A designer and a senior engineer
- Starts with
- What the product has to do
The handover is where interface design usually fails
A finished design covers the states that are easy to draw: the happy path, with plausible data. Engineering then discovers the other forty — empty, loading, partial, denied, too long, too many, offline — and invents them under time pressure, one screen at a time.
So we do not run a design phase that ends in a handover. A designer and a senior engineer work together from the first week, states are specified as part of the design rather than after it, and what is produced is a component set with tokens the codebase reads directly. The test of the work is not how the screens look in a deck. It is whether the tenth screen your team builds without us looks like it belongs.
What usually goes wrong, and what we do instead
The pattern is consistent enough that we now staff against it from week one.
Where interface design comes apart
- Screens designed with ideal data, so real content breaks the layout
- Empty, loading and error states left for engineering to invent
- A design file and a codebase that drift apart within one release
- Accessibility raised at review, when the layout is already fixed
- A component library nobody maintains, so screens get forked instead
How we work instead
- Designed against real content and real edge cases from the start
- Every state specified as part of the component, not after it
- Tokens as one shared source that the design file and code both read
- Contrast, focus and keyboard order decided while it is still cheap
- A component set your team can extend, with rules for when to
What we do
Design work that ends in something buildable rather than something presentable.
Discovery and research
Time with the people who use the product, and with the data about how they actually use it.
Information architecture
Navigation and flows worked out before visual design, because a beautiful wrong structure is still wrong.
Interface design
Screens designed against real content, with every state specified rather than implied.
Design systems
Components and tokens, documented with the rules for extending them, in a form the codebase reads.
Accessibility
Contrast, focus order and keyboard paths decided during design rather than audited afterwards.
Testing with users
Prototypes put in front of real users early, when changing the answer is still cheap.
What you end up with
Stated from your side rather than ours.
Designs that survive contact with engineering
Because an engineer was in the room while they were drawn, the states are specified and the layout has already met real content.
A system rather than a set of screens
Your team builds the next twenty screens without us, and they look like they belong to the same product.
One source of truth for tokens
Design and code read the same values, so a colour or spacing change happens once rather than in two places that drift.
Accessibility built in, not bolted on
Contrast and keyboard paths were constraints during design, so meeting WCAG 2.2 AA is not a remediation project.
How the work runs
The same five stages as every engagement, applied to an interface.
Diagnose
Who uses this, what they are trying to finish, and where the current interface makes that hard.
Decide
Structure, navigation and the component boundaries, agreed before any visual design is done.
Prove
One real flow designed, built and put in front of users, with its empty and error states included.
Deliver
Screens and components produced in slices, each one built alongside the design rather than after it.
Hand over
Your team designs and builds the next screens with us watching, then without us.
What you get
Grouped by what it is for, rather than by when it arrives — this work produces a system, and the parts of a system are not sequential.
Research and structure
What we learned, and the decisions it led to.
- Findings from time spent with real users
- Information architecture and the main flows
- The decisions taken, and what each one gave up
Interface
The screens, with the parts that are not the happy path.
- Designs against real content, at every breakpoint
- Empty, loading, partial, error and permission-denied states
- Prototypes for the flows that were tested
The system
What your team keeps and extends.
- A component set with documented states and rules
- Design tokens in a form both the design file and the code read
- A running Storybook, maintained as the components are built
Evidence
What makes the accessibility claim checkable.
- Contrast results across the palette, measured
- Keyboard and screen-reader paths for the main flows
- A written record of the accessibility decisions and their reasons
The rest of our web work
Most web engagements touch two or three of these. If you are not sure which, the consultation is the way in.
Related work
Engagements where the interface was the part that had to be got right.
CipherCru has been a trusted technology partner for us because they understand that successful software delivery goes far beyond writing code. Amit and his team bring strong engineering judgement, ownership, and transparency to every engagement. Whether we are evaluating an opportunity, designing a solution, or delivering for a client, we can rely on CipherCru to approach it with the same level of responsibility we would expect from our own team.
Questions about design work
The ones we are asked most often before a first conversation.
Can you design it and let our team build it?
We have designers already. What would you do?
Do you work in Figma?
How much user research is included?
What accessibility standard do you design to?
Do we have to redesign everything at once?
Product that works but does not feel like one?
Tell us who uses it and where it gets in their way. We will tell you whether the problem is the screens or the system underneath them.