Designing a scalable SaaS platform

During my time at Deloitte Digital, I contributed to the design a multi-tenant SaaS platform that unified audience segmentation, campaign orchestration, and performance analytics. While product specifics remain confidential, this case study shares how I mapped workflows, resolved edge cases, and built a custom design system to support clarity across roles and modules. It’s a behind-the-scenes look at designing for scale, layer by layer, flow by flow.

‍
Role:
UX /UI Designer
Platform:
Marketing SaaS for audience segmentation, campaign orchestration, and performance analytics
Deliverables:
Custom design system
High-fidelity mockups across modules
Charts and dashboard visualizations
Navigation logic and user flows

‍

From MVP to Modular: Designing the foundations of a SaaS platform
When I joined the team at Deloitte, the platform was still in its earliest form: draft screens, scattered ideas, and a bold ambition. It was messy, exciting, and full of possibility. My role was to help turn that ambition into clarity.

Designing for end-to-end workflows
The platform was envisioned as a full-spectrum marketing solution: integrating customer data, enabling smart segmentation, orchestrating multi-channel campaigns, and surfacing performance analytics. It needed to serve marketers, analysts, IT support, and client teams, each with distinct workflows and priorities, within a single, scalable experience. No known platform at the time offered this level of integration. What made it innovative was its ambition to unify fragmented tools into one cohesive system, supported by multi-tenant architecture and role-based access.

My role in shaping the experience
I was part of a small, collaborative design team. While our lead designer focused on stakeholder alignment and strategic framing, I crafted the product experience, designing flows, resolving edge cases, and advocating for user clarity through the work itself. I created the custom design system that unified components across modules and scaled design across the platform. I also prototyped and tested complex interactions, including role-based UI logic and edge-case handling, and collaborated closely with PMs, engineers, and marketers to align design with product goals and technical feasibility.

‍

‍

‍

Mapping the ecosystem
Before designing screens or systems, I started by mapping the ecosystem: how data flowed from external sources into customer profiles, how those profiles powered audience segments, and how segments fed into multi-channel campaigns. Each module had its own logic, but the navigation between them was fragmented. There was no shared mental model yet, just scattered pieces and overlapping intentions.

Understanding user roles and needs
I studied how different roles, marketers, analysts, support teams, interacted with the system. Each role came with its own goals, decision points, and visibility needs. Marketers needed to orchestrate campaigns across channels. Analysts needed to trace data lineage and performance. Support teams needed workspace-level clarity and troubleshooting tools. I mapped these needs to workflows, identifying where friction would surface and where clarity could be designed in.

Navigating technical constraints
The backend was still evolving. Data sources were inconsistent, cloud integration was in progress, and multi-tenant architecture introduced complexity around permissions and visibility. I didn’t treat these as blockers, I treated them as design inputs. I designed flows and components that could flex with backend realities while still supporting user trust and interpretability.

Building cross-team alignment
Designing in this environment meant constant translation between product goals, engineering constraints, and user needs. Our team worked closely with PMs, engineers, and marketers to align on terminology, logic, and decision points. Our early maps became shared references for resolving ambiguity and building clarity across teams.

Mapping the ecosystem wasn’t just about understanding the product, but it was about designing the conditions for clarity to emerge.

‍

‍

Designing for complexity: scale without losing clarity
While we designed specific user flows, we had to build connective tissues for navigation logic, modular pathways, and a design system that could support consistency and layered interactions. Navigation had to align with user expectations to reduce cognitive load and feel intuitive to accomplish tasks effortlessly. In our case, users needed to move between modules (Data, Audiences, Campaigns, Dashboards) without losing context.

I designed navigation logic that reflected real workflows by:
Progressive disclosure for nested flows (multi-layered workflows so that users only see what’s relevant at each step, surfacing complexity gradually, without overwhelming them).
Role-aware visibility to prevent cognitive overload, by tailoring what each user saw based on their access, responsibilities, and decision-making needs.

Making data-heavy interfaces interpretable
Some interfaces, like customer profiles, audience segments, campaign metrics, had dense, layered data. I designed with interpretability and flexibility in mind using visual hierarchy to guide attention, progressive filtering to reduce noise, or inline cues to explain logic without overwhelming the UI. 
Dashboards, for example, were designed as customizable views. Users could add or remove sections, adjust filters, and tailor views to match their role and priorities. This flexibility helped reduce cognitive load while preserving relevance, allowing each user to shape the interface around what they needed to understand and act on.

A design system is always more than a set of reusable components, it’s a shared visual language for users and builders alike. The system I built served exactly that purpose: creating consistency across user flows, modules, and roles, while supporting scale and interpretability.


Designing for scale meant designing for clarity layer by layer, role by role, flow by flow.

‍

Validating clarity through testing and iteration
Designing for complexity meant designing for interpretability but that clarity had to be tested, not assumed. We ran iterative tests across modules, validating flows, edge-case handling, and role-based UI logic. And we tested with real users: marketers, analysts, IT support teams. Each group brought different expectations, workflows, and visibility needs.
In some cases, clients tested the platform using live data, which surfaced nuanced feedback we couldn’t have uncovered in abstract scenarios. These sessions helped refine both the interface and the underlying system logic. We adjusted component behavior, clarified decision points, and improved fallback states based on real-world use.
Testing was embedded throughout our design process, informing decisions from early prototypes to final flows.

‍

‍

‍

Outcome & Reflection: Empowering Users Through Systems Thinking
Designing for SaaS means designing for scale, nuance, and collaboration. This project deepened my ability to navigate complexity, advocate for clarity, and build systems that empower users without overwhelming them.
The final product enabled marketers to orchestrate multi-channel campaigns with clarity, analysts to trace performance with confidence, and support teams to troubleshoot across workspaces with ease.
For me, the project was a masterclass in designing for scale. I learned how to translate backend constraints into intuitive flows, how to design for layered roles without losing coherence, and how to build systems that feel simple.
One of the most effective parts of the process was our collaboration rhythm. Daily standups, design reviews, and ad-hoc working sessions helped us resolve ambiguity in real time. Our lead designer created space for clarity, and the team operated with mutual respect and shared ownership.
This project reaffirmed my belief that meaningful design is co-created, through systems thinking, collaborative rhythm, and deep respect for the user’s experience.

‍