Service — SaaS product design for software that has outgrown its first designer.
SaaS product design is the structural work that keeps a software product coherent as it scales, information architecture, multi-role permissions, complex flows, design systems, and data-dense UI shaped by judgment, not by templates. Not screen-by-screen UI. Not marketing-site polish. The kind of decisions that engineers will live with for the next three years.
Lumixel Studio is a senior-led SaaS product design studio for fintech, healthcare, cybersecurity, and B2B software companies. We work with founders, heads of product, and engineering leads at the moment a product's scope outgrows one designer, usually post-PMF, mid Series A through Series C, when the pace of decisions is starting to outrun the team's design bandwidth.
Lumixel Studio is a senior-led SaaS product design studio designing complex software for fintech, healthcare, cybersecurity, and B2B SaaS companies, in 6-week fixed-fee sprints from $10K to $50K+, with the senior who pitches leading every week.
01 / 15
What SaaS product design actually means.
The term gets thrown around. Most agencies use it to mean “UI design for a web app.” That definition leaves out the parts that actually decide whether the product holds together at scale.
For us, SaaS product design covers six things, in order of what breaks first when they're missing:
- Information architecture. The way the product's objects, screens, and flows are organised. When IA is wrong, every later decision compounds the problem.
- Multi-role permissions and access modelling. Most real SaaS has more than one kind of user, admin, end user, viewer, customer, internal ops. Designing those surfaces and the rules between them is not a UI problem, it's a logic problem.
- Complex flows. Onboarding, KYC, multi-step configuration, approval chains, error and recovery states. The flows that have ten edge cases and only one happy path.
- Design systems and component foundations. Tokens, primitives, patterns, and the rules for combining them. The system that lets your team ship the next ten features without it looking like ten different products.
- Data-dense UI. Tables, charts, dashboards, filters, drill-downs. The interfaces where ten extra pixels of padding can make or break daily usability.
- Cross-surface coherence. When the same product lives on web, mobile, and an admin console, the decisions have to hang together. One brand, three surfaces, no Frankenstein.
If a SaaS product design engagement doesn't cover those six, it's a UI engagement wearing a different name.
02 / 15
When to hire a SaaS product design studio.
There are three moments where bringing in senior product design pays for itself many times over:
- Post-PMF scope explosion. The product works. Customers are asking for more. The roadmap has doubled. The founding designer (often the founder) can no longer hold the whole system in their head. This is the classic “scope outgrows one designer” moment Lumixel is built around.
- The second product surface. A web-only SaaS adding mobile. A consumer app adding an admin console. An internal tool becoming customer-facing. The surface count doubling is when most products lose coherence, and exactly when the design system work becomes load-bearing.
- A real redesign, not a reskin. The first version was shipped fast and accumulated debt. Two prior redesigns failed because they touched the surface without fixing the architecture. The next attempt has to be structural.
If you're pre-product-market-fit, hire a generalist designer (or a founder who can design). You don't need an outside studio yet. If you're scaling fast and the next year of your roadmap depends on getting the structure right, that's the right time to talk.
03 / 15
How a Lumixel SaaS product design engagement works.
We run 6-week sprints. The shape is fixed; the depth scales with how complex the product is.
Week 1 is structural. Flows, IA, permissions, system foundation. This is the architecture phase, the work that decides whether Weeks 2–5 can move at speed or get stuck in rework. Week 1 ends with a real go/no-go boundary: either side can pause cleanly if alignment isn't there.
Weeks 2–5 are execution. High-fidelity screens, states, edge cases, motion, and component primitives, with a Friday demo every week. Feedback lands continuously, not at the end. The senior who pitched is in your standups, leading the work, there is no junior handoff.
Week 6 is handoff. Engineering-ready Figma, decision log, design principles document, and walkthroughs with your engineering team. Not a redesign, a clean handover of work that's already been validated week-by-week.
For larger products, sprints stack. A Pro engagement typically runs two stacked sprints (12 weeks) covering web plus mobile plus admin. Past $50K, work moves to a custom retainer with a continuing senior lead.
04 / 15
What you actually get on Friday of Week 6.
Concrete deliverables, not slides:
- Engineering-ready Figma. Component-based, tokens wired through, variants for every state. The kind your engineers can build from without a half-hour clarification call per screen.
- Component foundations or a full design system, depending on scope. Primitives, patterns, and the rules for combining them. Documented in Figma, not in a separate Notion that no one reads.
- Information architecture and flow maps. Diagrams your PMs and engineers can use to onboard the next hire.
- Decision log. Every trade-off we made, with the reasoning. So three months later, when someone asks “why is it like this, ” the answer isn't lost.
- Design principles. Three to five rules of thumb your team can apply to the next ten features without us in the room.
What you don't get: brand identity, marketing-site design, or production frontend code. Those are different disciplines. We'll point you at people we trust for any of them.
05 / 15
SaaS product design in practice, recent work.
Three engagements that show what the work looks like at different complexity levels:
- Karaz Health , diabetes care platform across Saudi hospitals. Four clinical surfaces (Doctor, Nurse, Educator, Patient) from one component set, rebuilt while the system stayed live. Healthcare SaaS, multi-role, web + mobile.
- FePay , payments product with KYC, multi-role permissions, and compliance surfaces. Fintech SaaS, regulated vertical.
- Benchmark , fintech SaaS where the engagement was as much design system as feature work. Component foundation for a product expecting to ship monthly without losing coherence.
More on the selected work page. Some engagements are under NDA and abstracted in case studies, happy to walk through them on a discovery call.
06 / 15
Inside a 6-week sprint: the day-by-day shape.
The 6-week shape is more specific than “we move fast.” Here is what actually happens, day by day, in a typical engagement:
Week 1, Day 1, Kickoff. Half-day call with your founders, product leads, and engineering leads. We walk through the product live, ask the questions that shape the rest of the engagement, and agree on the scope boundaries.
Week 1, Days 2–3, Information architecture. Map every primary flow, every user role, every state. Surface the IA decisions hiding in the current product. Identify what's structural debt vs. what's working.
Week 1, Day 4, Role model and permissions. Define who sees what, who can do what, and where the system enforces it. Multi-role products live or die on this work.
Week 1, Day 5, Friday demo and go/no-go. Present the structural work back to your team. Either side can pause cleanly if alignment isn't there. Most engagements continue; the go/no-go is real, not theatre.
Weeks 2–5, Execution with weekly Friday demos. High-fidelity screens for every primary flow, every state, every variant. Component primitives. Motion. Friday demos lock the previous week's work and align on the next week's priorities. Feedback lands continuously, not at the end.
Week 6, Days 1–3, Documentation and final polish. Decision log written. Design principles documented. Component library finalised. Last-pass polish on every primary surface.
Week 6, Day 4, Engineering walkthrough. Two-hour session with your engineering team. We walk through the Figma file, the decision log, and the rules for extending the system. Q&A.
Week 6, Day 5, Handoff and project close. Final files delivered. Loom recording of the engineering walkthrough sent to your team for reference. Engagement closes; we remain available for clarification questions for 30 days post-handoff.
07 / 15
Hiring in-house vs an agency vs a freelancer.
Most teams considering SaaS product design have a few paths. Each has trade-offs. The honest comparison:
- In-house senior designer. Best long-term, they carry the design context, own the system, and grow with the product. Trade-off: three to six months to hire (longer in tight talent markets like London or the Bay Area), $150K to $250K+ fully-loaded annual cost, plus ramp time before they ship anything. Right call when you have the runway and the role.
- Senior freelancer. Cheap on hourly rate, fast to start. Trade-off: capacity-limited (one person, ~30 hours per week), rarely senior enough for structural work, no continuity if they take another contract mid-sprint, and you pay for every clarification call. Right call for focused smaller projects, not for structural decisions.
- Bay Area or London product design agency. Senior judgment, robust process, polished output. Trade-off: $80K to $150K+ per equivalent engagement, with a partner who pitches and juniors who deliver after Week 2. Sales cycles run four to eight weeks before kickoff. Right call for enterprise budgets and long-term partnerships.
- Offshore agency. Lower rates ($30K to $60K typical), some good senior designers in the mix. Trade-off: time-zone gaps, communication overhead, junior-heavy delivery teams, design language often doesn't match the product's position. Right call when budget is the binding constraint.
- Lumixel. Senior judgment at startup-friendly rates ($10K to $50K fixed-fee per sprint), no junior handoff ever, 6-week time-boxed engagements that actually finish, and the senior who pitches is the senior in your standups. Trade-off: small studio capacity, so booking windows can extend several weeks for popular months. Right call for the post-PMF moment when you need senior structural design without the hiring lead time.
The honest framing: no path is always right. Choose based on the constraint you actually have, time, budget, or risk tolerance for a hire not working out.
08 / 15
Patterns we use for different SaaS verticals.
SaaS product design has shared structural challenges (IA, permissions, system thinking), but the patterns that work vary by vertical. Where the same patterns appear across our case studies:
- Fintech SaaS. Trust-building moments designed deliberately (the pause between “Send” and confirmation). KYC flows designed for drop-off recovery, not just happy path. Multi-role permissions with compliance teams as a first-class user. Audit and forensic trails as designed product surfaces. See fintech UX design.
- Healthcare SaaS. Multi-stakeholder design where clinician density and patient clarity coexist in the same product. Click-count obsession on clinical surfaces. Consent as a moment in the flow, not as a popup. Offline-first logic for hospital WiFi reality. See healthcare UX design.
- Cybersecurity SaaS. Triage workflows designed for analyst fatigue at the eighth hour of a shift. Investigation context preserved across drill-down. Audit and forensic trail as a first-class surface. Role-aware density rules. See cybersecurity dashboard design.
- B2B SaaS. The buyer-vs-user split treated intentionally. Admin and procurement surfaces (SSO, SCIM, audit logs) designed at the same polish bar as customer-facing surfaces. Multi-tenant and multi-role logic designed in Week 1, not retrofitted later. See B2B SaaS design.
Cross-vertical patterns: every Lumixel engagement covers IA, permissions, state coverage, and design system foundations. The vertical-specific patterns layer on top of that base.
09 / 15
SaaS product design anti-patterns we see.
Specific failure modes that show up repeatedly in SaaS products, usually after a quick first design or a junior-heavy redesign:
- The surface relaunch. A redesign that touches colours, type, and component skin but leaves the IA and role model unchanged. Three months later, the product has the same structural problems with new visuals.
- The wireframe-driven feature factory. Engineering ships from sketchy wireframes; states get figured out in code; edge cases get filed as bugs. The product slowly accumulates a long tail of partially-designed flows that nobody can explain in totality.
- The design system nobody uses. 200-page Notion doc, beautiful Figma library, full token system, and the engineering team still rebuilds components on every feature because the system doesn't cover the cases they hit. The system was built for designers, not for the people who actually ship the product.
- Mobile-as-port. The mobile app is a shrunken-down web layout. Platform conventions ignored. Native behaviours (biometric auth, haptics, system back) absent. Users tolerate it; competitors win on mobile.
- Consent and disclosure theatre. Every screen has a popup. Users banner-blind through them. When the one that matters appears, nobody reads it. Compliance is satisfied; users are not protected.
- The feature-parity trap. Every customer request becomes a setting, a toggle, or a configuration option. Settings sprawl across nine pages with no hierarchy. The product slowly becomes harder to use for new customers and impossible to onboard for the next sales prospect.
- Admin-as-afterthought. Customer-facing surfaces get all the design love; admin surfaces are functional but ugly and inconsistent. Then enterprise procurement reviews, and the admin experience becomes a deal-blocker.
Most of our engagements start with a product showing two or three of these. The structural rebuild fixes the underlying causes rather than treating the symptoms.
10 / 15
Karaz Health: rebuilding a live clinical platform.
Karaz Health was a diabetes care platform live across multiple Saudi hospitals for three years before we got involved. The product had grown piecemeal: no shared design system, three clinical roles sharing screens designed for one, accumulating workflow debt, and an investor deadline to add a patient mobile app that the existing architecture couldn't absorb.
Two prior redesigns had failed because they treated the surface without fixing the architecture. We approached the third attempt as a structural rebuild while the system stayed live for daily clinical operations.
Week 1 surfaced four required surfaces (Doctor, Nurse, Educator, Patient) from one component set, with strict role-aware permissions. Weeks 2–5 designed every surface with shared primitives and patient-clarity vs clinician-density treatments. Week 6 handed off to engineering with a phased rollout plan that kept the live system stable.
Outcome: one platform for diabetes care, four roles, web plus mobile, designed in a way that absorbed the patient mobile addition without restructuring. Three-clicks-or-fewer for the primary clinician task, down from eight. See the full Karaz Health case study.
11 / 15
FePay: shipping fintech onboarding without losing users.
FePay was a payments product with a KYC drop-off rate above 50%, typical for fintech, ruinous for unit economics. The team had tried two iterations of the existing flow without meaningful improvement, and the regulator's compliance requirements made any redesign slow and high-risk.
Week 1 audited the existing KYC flow against compliance constraints, then mapped the rejection-and-retry paths users actually encounter (document not at hand, photo unclear, name mismatch, jurisdiction mismatch). Weeks 2–5 designed for the drop-off recovery path as first-class, not as edge-case-afterthoughts.
Multi-role permissions, compliance officer surfaces, and the audit trail were designed in parallel. Cross-platform consistency between web and native mobile was held by a shared design system with role-aware variants.
Outcome: KYC completion rate moved meaningfully, compliance review approved every screen, and the design system held up through the next three feature releases without component rebuilds. See the full FePay case study.
12 / 15
Working alongside your in-house design team.
Most of our engagements include working alongside an in-house designer or a small design team. The sprint shape is built to make this productive, not awkward:
- Week 1 includes them as co-authors. Your in-house designer is in every working session. Decisions get made together; they own the context when we leave.
- Weeks 2–5 split work intentionally. We take the structural and system work; your designer takes feature-level execution they want to own. Friday demos cover both.
- Week 6 handoff is to them as much as to engineering. They walk away with the decision log, the design principles, and the rules for extending the system, so they can keep shipping at the same bar after we leave.
We've been the senior on engagements where a Series A solo designer leveled up two tiers during the sprint. We've also been the third designer on a team of seven, handling structural work the in-house team didn't have capacity for. Both work.
13 / 15
What we don't do.
A short list, because honesty about scope saves both of us time:
- Brand identity. Logo design, brand guidelines, marketing visual identity. Different discipline. We'll point you at people we trust.
- Marketing site design. Landing pages, brochureware, conversion-focused web pages. Different problem from product design.
- Frontend or full-stack development. We don't ship code. We partner with engineering teams; happy to make introductions if you need one.
- Dedicated user research projects. Light-touch research in support of design decisions yes, but standalone research engagements are a different discipline. Specialist firms exist.
- Animation, illustration, 3D. Component-level motion design yes, but elaborate brand animations or custom illustration are not in scope.
- White-label or ghostwriting work for agencies. We work directly with product teams, not as a delivery shop behind another agency.
If a project genuinely needs twelve weeks of discovery or a six-month commitment, we're not the right team , be honest with yourself about that before booking.
14 / 15
Pre-engagement readiness, what we need from you.
The fastest engagements start with the right material in hand on Day 1. Before kickoff we ask for:
- Access to the current product , real or demo accounts, ideally with realistic data so we can see the empty state and the stress state.
- Existing Figma files, design system, or brand assets , whatever exists. We'll extend rather than tear down where the existing work is usable.
- Recent customer research, analytics, support tickets, or churn analysis , anything that tells us where users actually struggle.
- A clear primary stakeholder , usually the head of product or the founder. Someone empowered to make decisions in the Friday demo.
- The engineering lead in the room for Week 1 , because the IA, role model, and system decisions are joint design-engineering decisions.
What we don't need: a detailed brief, a wireframe, or a list of feature requirements. The shape of the sprint is to discover that work together in Week 1.
15 / 15
Pricing for SaaS product design.
Fixed-fee sprints. No coyness, no hourly billing creep, no surprise scope changes:
- Lite, $10K–$15K. Single platform, single user role. 6-week sprint. Senior present every week. Component foundations, engineering-ready Figma.
- Standard, $15K–$30K. Multi-platform OR multi-role. Cross-surface design system. State, edge case, and motion coverage. Decision log and design principles.
- Pro, $30K–$50K+. Multi-platform AND multi-role (web + mobile + admin). Full design system. Compliance and access modelling for regulated verticals like fintech and healthcare. Mobile-first scope with native HIG/Material patterns.
Above $50K moves to a custom retainer. Pricing depends on three things: how many platforms (web, mobile, admin), how many user roles or modules, and the vertical complexity, regulated industries take longer.
Full pricing is on the homepage. Or skip ahead and book a discovery call.
FAQ — Common questions about SaaS Product Design.
Related — Keep reading.
Talk to us — Have a project that needs this?
Book a 30-minute discovery call. Free. No slides, no sales.
Book a discovery call