SaaS product design for screens that get denser every quarter
Dashboards, admin panels and settings flows designed for the version of your product that has ten more features than it does today — including the empty states, permission cases and error paths that demos always skip.
What you get
- Dashboard, admin panel and data table layouts that stay readable
- Onboarding flows, empty states and error cases covered
- Scalable UI patterns for features added after launch
Designed for real data
A dashboard designed against six tidy rows of sample data falls over the first time a customer loads four thousand. Tables, filters and charts are designed against realistic volume, realistic label lengths and realistic edge cases.
That includes the states nobody screenshots: nothing yet, too much to show at once, one record with a name long enough to break the column.
Onboarding that survives the second session
Most SaaS onboarding is designed for the first five minutes and abandons the user afterwards. The flows here cover getting set up, getting the first useful result, and coming back a week later to a product that still makes sense.
Empty states do real work in that: an empty dashboard is the best teaching surface a product has, and it is usually the least designed screen in the file.
Patterns that scale with the roadmap
Features get added after launch. Rather than designing each screen as a one-off, the work establishes patterns — how a settings page is laid out, how a destructive action is confirmed, how a table filters — so the next feature has an answer to follow.
This is where SaaS design and design system work overlap, and on longer engagements they are usually the same project.
Common questions
Can you redesign our existing SaaS rather than start over?
Yes, and it is usually the better option. A redesign starts by reviewing the screens you already have, so the work targets the parts costing you users rather than rebuilding what already works. It also means you can ship improvements in stages instead of holding everything for one big release.
Do you work with our developers during the build?
Yes. Handoff is not a single moment — questions come up while the build is underway, and I stay available to answer them, review implementations against the design and adjust where the code reveals something the file did not. How much of that time is included is agreed in the scope.
Do you do user research, or design from our requirements?
Both are possible. If you have research, analytics or support tickets, that is the strongest starting point and I will design from it. If you do not, I can run lightweight research — flow mapping, a usability pass on the current product, prototype testing — scoped as part of the project.
Have a project in mind? Let’s talk.
Get in touch