Interface Design · For marketing teams
An interface system, not a stack of screens.
Brands don't drift in one big decision - they drift one screen at a time, each designed in isolation under deadline. We design interfaces as a system: tokens, components and patterns your brand lives inside, so every future screen ships consistent without anyone having to police it.
Consistent by construction.
What it is
The brand, made buildable.
A brand guideline PDF can't review every screen. The moment interfaces are designed one-off - a landing page here, a campaign microsite there - the drift begins: four button styles, three blues, spacing nobody can name. Every new screen makes the next one harder.
Interface design as we practise it is systems work. We translate the brand into design tokens, build the component library those tokens feed, and design the actual screens from the system - so the hundredth screen is as on-brand as the first, and faster to make.
A system, not screens
Tokens, components and patterns designed once and reused everywhere - so consistency is how the setup works, not a review step that gets skipped.
Accessible by default
Contrast, focus states, touch targets and semantics designed into the components - so every screen assembled from them clears the bar without a retrofit.
Built to be built
Designed with engineers in the room, named the way code is named, and handed over as specs a developer can implement without interpretation.
Who it's for
For brands that look different on every screen.
This is for teams shipping fast enough that the brand can't keep up with itself - where every campaign adds a new variant, the agency and the in-house team draw different buttons, and 'make it match the site' has stopped meaning anything specific. If design review is the bottleneck and drift is winning anyway, the fix isn't more review. It's a system.
- Every new page is designed from scratch, and it shows in the seams.
- Design is the bottleneck: simple pages queue behind a single designer's calendar.
- Developers rebuild the same components repeatedly because nothing is shared.
- Accessibility is a hope, not a property anyone can point to.
How it works
Foundations, system, screens, handover.
Audit
Inventory the drift
Every button, colour and pattern currently in production, catalogued - the honest picture of the drift, and the raw material for the system.
Foundations
Tokens before components
Colour, type, spacing and motion decided once as design tokens - the brand's rules in a form both Figma and code consume.
System
Components and patterns
The component library designed on the tokens, with states, variants and accessibility built in - then the page patterns assembled from it.
Handover
Docs, parity, adoption
Documentation, Figma-to-code parity and working sessions with your team and ours - because a system only counts if people actually build with it.
What you get
A design system your teams actually use.
Design tokens
The brand's decisions - colour, type, spacing, motion - captured once, consumed by design files and code alike.
A component library
Every interface part designed with its states, variants and rules - in Figma, documented, and mirrored in code.
Accessibility as standard
WCAG-conscious contrast, focus and interaction states baked into components, so compliance is inherited rather than audited.
Patterns and templates
The recurring page types - landing, campaign, content - as assembled patterns, so new pages are composition, not invention.
The case for the system
The hard part isn't building the system. It's getting it used.
The economics were never in dispute: design decided once and inherited everywhere beats buying every screen separately, and the longer your roadmap the wider that gap gets. What goes wrong is downstream of the argument - a library nobody reaches for, drifting from the week it lands. So the work is building for the people who have to live in it: tokens they can find, components that cover the cases they actually have, and the patterns written down where the work happens rather than in a deck.
Source: zeroheight, Design Systems Report 2026 (147 practitioners)
Proof
Interfaces for complicated domains.
Interface systems for products where the domain is the hard part - a produce marketplace, an orchard management system, an adviser portal.
Nile.ag
Cohesion for a fast-growing agri marketplace
An embedded UX partner bringing cohesion back to a multi-marketplace agri-trade platform: fewer clicks, decluttered dashboards, and a mobile experience farmers can actually use in the field.
Karsten Group
Orchard planning, off the spreadsheet
Designing the orchard management system for one of South Africa's largest agricultural exporters - agronomist-led spray and fertilisation programmes planned centrally, pushed out to orchard managers, and adapted as the season turns.
Fundhouse
An adviser portal, rebuilt around the model portfolio
A legacy portal that answered most questions with a PDF, replaced with the tools independent financial advisers actually use - model portfolios, interactive charting and client-ready review packs.
In their words
“Touchfoundry delivered state of the art design and front-end development in a jiffy. So good that their babies have traveled the OLX world and since have set a new standard for our brand.”
Joost Wolzak
Head of User Experience at OLX
Common questions
Asked before almost every engagement.
Guidelines describe; a system enforces. Tokens, components and patterns make consistency the default state of every new screen, so the brand holds without a review step that gets skipped under deadline.
Brand drifting screen by screen?
Let's build the system.
Show us the screens you ship most and where the drift hurts. We'll come back with what a system would look like for your brand - tokens, components and the order we'd build them in.