Discovery
We read the product before we form opinions about it. A login, a walkthrough, the tickets and the analytics.
Products
Software that stops needing a demo
SaaS platforms, dashboards and internal tools, designed so the value is visible without a walkthrough.
Product strategy
What the product should be, ranked against what it can be this year, and research to prove it.
Interface design
Production-quality UI with every state designed, including empty, loading, error, partial and permission denied. The states nobody screenshots.
Systems and handover
A component library with tokens, documentation, usage rules and versioning, handed over in a form your engineers adopt.
The process
Six stages. A date we hold.
Research
Interviews with the daily users and with whoever signed the invoice, plus a pass through your own support calls.
Architecture
The information model, navigation, object relationships, permissions and states. The layer that decides whether it all lasts.
Prototypes
Clickable, testable, and in front of real users before anyone writes production code. Freelogo alone needed thirty-eight of them.
Interface
Production-quality UI across the flows that matter, every state included. Your own engineers review the work with us weekly.
Handover
The component library, tokens, documentation, usage rules and versioning, plus a written rationale for every structural decision we made.
Where to next
By sector
Most of our product work is for software that is hard to explain. There is a page for SaaS and technical products, one for compliance and regulated software, one for hosting and infrastructure, and one for AI product design. If yours is none of those, the work is usually the same shape.
Our work
Judge us on this
FAQs
Questions we get
A full engagement, from discovery through research, architecture, prototypes, interface and design system, is a twelve-week project priced as a fixed scope. A design system on its own is closer to five weeks. We give you the number at proposal stage, before you commit to anything.
UX is the structure: what the product does, in what order, for whom. UI is what each screen looks like. Agencies that sell them separately usually do one badly. We do the architecture first, every state and every flow, and only then the visual layer, so engineers get something they can extend rather than a set of pictures.
Yes, and it is most of our product work. TSRGD, SolusVM and the hosting control panels we design are all live products with real users. We rebuild the architecture underneath the screens so the team can ship the new version in stages rather than switching everything off for a relaunch.
That’s the normal experience, because most handovers are a Figma link and a phone number. Ours is a documented library with tokens named against your code, every state specified, and time booked in during your build.
Yes, and it’s usually the best version of this. We define who owns what in week one, in writing, because that’s what slips.
Then buy part of it. Plenty of engagements are a design system on its own, or just architecture and prototypes alone.
Research with real users, an information architecture, prototypes tested before code, production-ready UI for every state, and a documented design system with tokens and governance rules. Front-end development if you want us to build it. One named senior designer throughout.
Twelve weeks for a full engagement: discovery, research, architecture, prototypes, interface and system. A design system on its own is closer to five weeks. You get the date at proposal stage, before you commit to anything at all, and we hold to it.
We’ve designed control panels, server virtualisation, hosting infrastructure and statutory compliance tools. cPanel, Plesk, WHMCS, CloudLinux, HostPapa, Servebolt, SolusVM. If your product needs a glossary before a designer is any use, that’s our normal starting position.
A component library with tokens, documentation, usage rules and a version history, so a new screen is assembled rather than drawn. You need one when your engineers start inventing components.
Related reading
Worth reading before you call
Nobody uses AI they cannot check
Almost right is the expensive kind of wrong. It moves the work from doing the task to checking whether the machine did it, and most products have not designed that part at all.
AI disclosure is a design problem
Since 2 August 2026 the EU AI Act requires you to tell people when they are dealing with a machine. Most teams will answer that with a footer, which is the one place nobody looks.
Case studies are how buyers find you
Most case studies are written as a record of what the supplier did. Buyers are scanning for a situation that looks like their own, and most case studies never describe one.
