Digital Product Design
What we've learned so far
Design is the cheapest part of building a product and the most expensive to skip. Skipping it does not remove the work, it relocates it to other departments and the experience gets decided by whoever plans the business or writes the code, through the lens of their own personal experience or whatever framework is in front of them. That produces products shaped subjectively rather than by what the end user came to do. Design is also the first deliverable that shows what a product will feel like months before anything runs, so engineers estimate against it instead of guessing, and stakeholders argue about the product in front of them rather than the one each of them imagined.
It is not optional because the experience is the product to everyone outside the company. Customers do not see the architecture, the framework or the sprint that went badly. They see whether they can do the thing they came for, whether they trust what they are looking at, and whether they come back. Activation, conversion, support volume and churn all sit downstream of that. A weak experience does not fail loudly. It underperforms quietly, at a rate nobody attributes to design, for as long as the product exists.
AI has made production accessible to everyone, and we treat that as progress. Design systems, state permutations and variant generation are work we are pleased to have automated. The consequence is that output no longer distinguishes anyone, because your team has the same tools we do. AI generation produces plausible answers, and plausible is not the same as correct for your business and your constraints. Knowing which of twenty good options is right requires the numbers, the support queue and the person who owns the revenue. Knowing whether that decision survives implementation requires having built things and being accountable when they break. That judgement is the part you are paying for.
What this can involve
Accessibility Remediation
Design Iteration Cycles
Onboarding Flow Design
Developer Handoff and Documentation
Design System Consulting
Concept Definition
Product Discovery
Product Audit
Mobile-first Responsive Design
Usability Testing Services
Design Sprints
MVP Prototyping
Prototyping Services
UX Writing and Microcopy
Form Design
Micro-interaction Design
UX Audit
Heuristic Evaluation
Card Sorting and Tree Testing
User Flow Design
Information Architecture Services
Service Blueprint Design
Customer Journey Mapping
Data Visualisation Design
How we work
The business, market and the brief
The numbers, the support queue and the person who owns the revenue. A brief tells us what someone decided to ask for. Those three tell us what the product is actually failing to do.
Agree on the decision being made
Redesign onboarding to lift activation is a brief. Better UX is not. Everything that follows gets measured against whatever we agree here, including our own work.
Design the difficult parts first
Empty, loading, error and permission states, the screen with real data in it, the flow that only applies to one customer type. The clean case is easy and it is not where products fail.
Put it in front of people and iterate
Prototypes tested with users who match yours, and revised. This is where twenty plausible options become one correct one, which is the part AI does not do for you.
Hand over so it survives engineering
Specs, components and the reasoning behind the decisions, with developers involved before anything is final rather than after. A design that cannot be built as drawn was never finished.
Where this isn't the right fit
If the decision is already made and what you need is production, use the tools you already have. Generating screens is cheap now and we would be an expensive way to buy it. What we sell is the judgement about which option is right for your business, and that only has value where the answer is genuinely open.
If nobody can give us access to the data, the support queue or the person accountable for revenue, we will design against assumptions and so could anyone. If you need a marketing website rather than a product, that is a different service and a smaller budget. And if the real constraint is that engineering cannot ship what is already designed, the problem is upstream of us.
