Atlas Components
A manufacturer rebuilds around product-category search intent, with a structured content model instead of a page builder.
Structure built for how buyers search
02 · Design
UX and UI design
Design decides how much of your product people can actually use. It sets what they find, what they understand, what they trust, and where they stop. Those are commercial outcomes, and they are decided before a single line of production code is written.
We design interfaces that are structured to be built: real content, real states, real breakpoints, and a component system that survives contact with a development team.
What usually goes wrong
The common failure is not ugly design. It is design that was never resolved – approved as a set of desktop screenshots showing ideal content, then handed to developers who have to invent the other eighty per cent.
- Screens were signed off with placeholder text and no long-content or empty states.
- Mobile was designed by squeezing the desktop layout rather than being designed at all.
- Every new page needs a new design, because no reusable system was ever defined.
- The build looks different from the design and nobody can say exactly where it diverged.
- Users cannot find things, and the proposed fix is always to add another item to the navigation.
- Accessibility was raised at the end, as a compliance task rather than a design constraint.
What we do
Design as a sequence of decisions, each one resolved before the next depends on it.
UX research
Understanding the people who will use the thing and the tasks they are trying to finish. User interviews, task analysis, review of existing analytics and support tickets, competitor and comparator review, and usability testing of what you have now.
Information architecture
Structure before surface. Content inventory, grouping and labelling, navigation models, URL structure, and the search and browse paths people will actually take. On content-heavy sites this is the single highest-leverage design work available.
User flows and wireframes
Task flows through the product, then low-fidelity layouts that resolve hierarchy, content order and interaction before any visual decision is made. Cheap to change at this stage, expensive later.
Interface design
Visual design across the full responsive range, with real content, every state a component can be in, and typography and colour chosen for contrast and legibility as well as character.
Design systems
Design tokens, a component library with defined variants and states, layout and spacing rules, and usage documentation – so the fiftieth page costs a fraction of the first.
Prototyping
Interactive prototypes for the flows where interaction is the risk: multi-step forms, configurators, checkouts, dashboards. Tested with real people before they are built.
Diagram
How we design
Five working principles that shape every decision.
-
Structure first, surface second Navigation, hierarchy and content order are resolved before colour and type. A beautiful interface over a badly structured one is a more expensive version of the same problem.
-
Design with real content We design against the longest realistic product name, the empty dashboard, the six-line error message and the customer with three hundred orders. Placeholder text hides every layout problem you will actually meet.
-
Mobile is designed, not derived Small screens get their own layout intent, not a proportionally shrunk desktop. On most of the sites we work on, mobile is the majority of traffic and the majority of revenue.
-
Accessibility is a design constraint Contrast ratios, target sizes, focus order and label clarity are decided in design, where they cost nothing, rather than retrofitted in development, where they cost a redesign. We design to WCAG 2.2 AA criteria.
-
Design for the team that will maintain it Every component is defined once with explicit variants and states, and documented so it can be used correctly by someone who was not in the design process.
What you receive
Working files plus the documentation that makes them usable by other people.
- Research findings and prioritised UX issues
- Information architecture and navigation model
- Annotated user flows for the primary tasks
- Wireframes for every unique page template
- Interface designs across mobile, tablet and desktop
- Component library with all variants and interaction states
- Design tokens for colour, type, spacing, radius and elevation
- Interactive prototypes for the high-risk flows
- Accessibility notes: contrast, focus order, target sizes, labels
- Design system documentation and handover
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Design work sits inside that process rather than alongside it.
Common questions
Do you work with our existing brand?
Yes, and that is the usual case. We extend an existing brand into a digital system – type scale, colour applied at accessible contrast, spacing, components – without redrawing your identity. If the brand genuinely cannot carry a digital product, we will say so and scope that separately.
Can you design without also building?
Yes. Design-only engagements are common. We hand over a documented system and stay available during your team's build to answer questions and review implementation.
How do you handle design review and sign-off?
Scheduled reviews at the end of each stage – structure, then wireframes, then interface – with a named decision maker on your side. Approving structure before surface prevents the most expensive category of late change.
What design tools do you work in?
Whatever your team can open, review and inherit. Tool choice is a handover decision, not a craft decision, and we agree it at the start rather than presenting it as fixed.
Related services
Have a product that is hard to use?
Send us the URL and what you think the problem is. We will tell you whether it is a design problem, a structure problem or a measurement problem.
Or email hello@applystudio.com – we reply within one business day.