Timeline
2 design sprints, 1 month
My Role
Product Designer (Intern)
Team
Abhishek (PD),
Chitra (PM),
Prajwal (Engineering)
Context
About Zluri
Zluri is a B2B SaaS Management & Identity Governance platform used by IT and Security teams at companies like Monday.com, Grab and Zepto to manage applications, streamline access, and automate reviews.
The Users
The Existing State
Teams relied on two modules daily:
SMP (app management, access provisioning) - had a static default dashboard
IGA (compliance monitoring, risk tracking) - had no overview at all
When Zluri launched customizable BI dashboards, users could finally build personalized views of their data. But there was no way to control which dashboard became their landing page.
Existing SMP Landing View
Existing IGA Landing View
The Problem
For IT admins managing 500+ apps or Security teams tracking compliance gaps, the first screen they see determines whether they can act immediately or waste time hunting for insights.
More importantly, critical issues can be missed when the landing page doesn't surface what's urgent.
The Challenge
Design a flow that lets users and admins set any dashboard as their overview for themselves or their entire organization without breaking access for others.
The Solution
We designed a clear, safe, and flexible flow that allows users to set any eligible dashboard as their SMP or IGA overview for themselves or for the entire organization. The modal-based approach helps users understand the impact, supports guardrails, and keeps high-stakes decisions intentional.
Set As Overview Flow
My Role
I owned the design execution working alongside Abhishek (Associate PD), Chitra (PM) and Prajwal (Engineering).
What I owned
Permission system logic that defined what's technically possible
End-to-end flow design across 3 major iterations
Edge case identification and resolution
Stakeholder presentations to CTO, PMs, and engineering
How I worked
Abhishek acted as my design partner, pushing me to ask "What happens if the owner deletes this?" or "How does this scale to 50 dashboards?" This taught me to anticipate problems before they reached engineering.
The Foundation : Mapping The System
Before designing any UI, I hit a wall. When discussing dashboard actions with the team, we kept asking:
"Can someone set a private dashboard org-wide?"
"What if it's a draft?"
"What happens when ownership changes?"
We were confused about the rules.
So Abhisekh and I stopped and mapped every possible dashboard state:
The Variables
Ownership: Owner / Non-owner / Standard
Visibility: Private / Shared with Org
Status: Draft / Published
Action Permission Matrix
Key rules this revealed
Only published dashboards can be overviews
Private dashboards = personal overviews only
Non-owners can't set org-wide overviews
Draft dashboards can't be set at all
This matrix became our source of truth. It prevented us from designing technically impossible flows and helped engineering understand the logic immediately.
Designing The Flow
With the logic mapped, I moved into designing the experience. The core question: How do we make a high-impact action feel clear, safe, and impossible to misunderstand?
Entry Point : Where Users Find It
After reviewing how users interact with dashboards, we placed "Set As Overview" in the dashboard action menu
Set As Overview in action menu
This made it discoverable without cluttering the primary UI, and followed the established pattern for dashboard actions like Edit, Duplicate, and Delete.
The Pattern : Choosing the Right Approach
I explored two interaction patterns for how users would make their selection:
Popover (Rejected)
A dropdown that appears inline when clicking "Set As Overview," showing platform and scope options within the existing page context.
Inline Popup on click
Why it didn't work
For an action where an admin sets what 50+ people see every morning, a popover felt too lightweight. It competes with the background, feels easy to dismiss, and doesn't signal the gravity of an org-wide decision.
B. Modal (What we went with)
A focused overlay that opens when clicking "Set As Overview," blocking the background and demanding full attention for the selection.
Component View
Full Screen View
Why it worked
Demands focus - The overlay blocks everything else, signaling "this decision matters"
Room for clarity - Space to show all platform/scope combinations, impact messaging, and context
Intentional friction - The extra step of opening a modal creates appropriate friction for org-wide changes
Scalable - Easy to add future options like scheduling or notifications without redesigning
When presenting both to the CTO and engineering, the feedback was immediate: "This action affects too many people to feel lightweight."
Impact Preview: Showing What Changes
Setting an overview can replace existing defaults, personal or org-wide. Before confirming, users need to know exactly what will change.
The Challenge
With platform (SMP/IGA/Both) × scope (Myself/Org/Both), we had 15+ possible combinations. We needed a systematic way to document the correct message for each scenario.
The Syntax System
Syntax for impact copy
This syntax helped us document all 15+ combinations systematically, ensuring consistent messaging across every platform/scope combination and making engineering handoff clear.
Success Confirmation
Once users confirm their selection, we provide immediate and persistent feedback:
Immediate Feedback
A toast message instantly confirms that the dashboard was successfully set as the SMP/IGA overview.
Toast message on confirmation
Persistent State Indicator
An "Overview" badge appears beside the dashboard name, showing where it's currently set (SMP, IGA, or Both).
Overview badge as per platform
Error Handling
Even after defining the main flow, several real-world scenarios broke the logic. These came from reviewing the permission matrix, testing flows, and discussing with PMs and developers.
Here’s how we resolved them.
Owner tries to change scope of overview
Scenario
An owner sets a dashboard as the org-wide overview, then tries to make it “Myself” (private).
Problem
Downgrading visibility would break the org’s access.
Solution
We restrict visibility downgrade when a dashboard is in use as an org overview.
If needed, the owner can first unset the overview, then change visibility.
After user confirms overview
User loses access to personal overview
Scenario
A non-owner sets someone else’s dashboard as their personal overview. Later, the owner makes it private or deletes it.
Problem
The user loses access to their personal overview.
Solution
We apply automatic fallback (Personal → Organization → Zluri default) so users are never without a dashboard.
An informative banner explains the change without disrupting workflow.
If needed, users can set a new personal overview through the Analytics section.
Personal overview is removed
The Impact
While this wasn't shipped during my internship, here's how I'd validate success:
User Signals
Overview setup rate - % of users setting at least one personal overview
Time-to-insight - Reduction in time from login → actionable data
Dashboard engagement - Increase in daily active users on BI dashboards
Business Signals
Org-wide adoption - % of companies with custom overviews set
BI-heavy account retention - Improved renewal rates for teams using overviews
Product stickiness - If teams rely on custom overviews daily, Zluri becomes infrastructure not just another tool
Why It Matters
In enterprise SaaS, customization drives stickiness. If teams rely on custom overviews daily, Zluri becomes harder to replace during renewals.
My Learnings
Start with Structure, Not Screens
The permission matrix felt like extra work, I wanted to jump into UI. But mapping the system's rules first prevented us from designing technically impossible flows.
Match Fidelity to Your Audience
Engineers couldn't engage with low-fi wireframes. Figma Make changed that—in one CTO meeting, we tried 3 button placements in 10 minutes and shipped the final design before the call ended.
Edge Cases Aren't Edge Cases at Scale
At 500+ apps with 50+ team members, the "2% scenario" happens multiple times daily. In enterprise design, edge cases ARE the design.
Good UX is Good DX
The syntax system helped us document all 15+ combinations systematically, making the engineering handoff clear and unambiguous.
Design is Collaborative
Abhishek's questions stress-tested designs. Prajwal's constraints shaped better solutions. The CTO's live feedback compressed weeks into minutes.