Service
SaaS Product Design
Scalable design systems for complex software products.
Complex software is not hard to use because it is complex. It is hard to use because every screen presents everything it knows, and the person opening it had one question.
I design SaaS products around the workflows that actually run the business: what a person came to do, in what order, and what they are allowed to see.
Who this is for
You have a product with real users and real complexity multiple roles, permissions, data-heavy screens and the interface has not kept pace with what it now does. Or you are building the first version and want the structure right before it hardens.
Who this isn't for
If you need a marketing site for a SaaS product, that is web design and cheaper. If you want screens drawn to an existing spec with the thinking already done, you will get better value from an implementation designer than from this.
How the work runs
Discovery first: the roles, what each is trying to accomplish, and where the current product makes them stop. Then architecture navigation, permissions, and what belongs one level down settled in low fidelity while it is still cheap to change.
Interface design follows, built on a component system rather than page by page, so the tenth screen costs less than the first. You get a prototype that can be tested with real users before anyone writes production code.
What this looked like on LaundryHub POS
A point-of-sale for a laundry counter, serving four roles: owner, manager, counter staff, and platform admin. The hard problem was never the screens. It was that the owner needed to see revenue, the counter staff must never see it, and a locked tab had to explain itself rather than simply disappear because an app that looks different on every phone reads as broken.
The reports screen was rebuilt four times. Each rebuild came from the same finding: the owner's real question was not "what did I earn" but "do I believe this number".
What you leave with
A documented Figma system with tokens and components. Flows and an architecture that account for roles and permissions. An interactive prototype. Dev-ready specs your engineers can build from without guessing. And the reasoning written down, so the next decision does not restart the argument.
My Process
Discovery & Research
We start by mapping user roles, complex business logic, and core success metrics for your platform.
UX Architecture
Defining high-level flows, site maps, and wireframes to ensure the product logic is bulletproof.
Interface Design
Crafting high-fidelity, data-dense interfaces that prioritize legibility and user efficiency.
Handoff & Specs
Delivering a production-ready design system with comprehensive documentation for your engineers.
Case Studies
Related Projects
Working on a SaaS product?
Tell me what it does and where users stall. If the problem is smaller than a full engagement, I'll say so.
FAQ
Frequently asked questions
How long does a SaaS design engagement take?
Six to twelve weeks for a first release, depending on how many roles the product serves. LaundryHub carried four roles with different permissions, and most of the schedule went on the permission model rather than the screens.
Do you work on existing products or only new ones?
Both, and existing products are often the better investment. I start by mapping how the product is actually used and where people stall, so the work targets the flows costing you money rather than the screens that look dated.
What does a design system mean here, concretely?
Tokens for type, spacing, colour, radius and elevation, then components built from them, documented so a developer picks a name rather than a number. The point is that the tenth screen is cheaper than the first, not that it looks tidy.
Can you design for complex, data-heavy screens?
That is the interesting part. Reports, dashboards and permission-filtered views are where most SaaS interfaces fail, because they present everything at once. The work is deciding what the person opening this screen is actually asking.
Do you build it as well?
No. You get a documented Figma system, a prototype and specs your engineers can build from. I work alongside your development team rather than replacing them, and I stay available while it is being built.
We have no in-house designer. Is that a problem?
No. On several projects I have been the only designer, working directly with the founder. If there is no design function, the research and the product strategy are part of the engagement rather than assumed.
Next Service