Home
Custom Application Access & Settings
ROLE
Product designer
HYPOTHESIS
Group-based app settings, plus clear org-level defaults for apps, are needed to make onboarding/offboarding in Electric more functional and competitive.GOALS
- For Admins: Invest time once to define org and group standards, then trust these apply to every onboarding and offboarding
- For New Employees: Arrive on day one with complete access to resources and standard applications
- For Electric: Get closer to feature parity with competitors
TOOLS
Figma, Claude AI, Pendo
TIMELINE
October 2025 - January 2026
Background
The Context
- Employees in different departments/groups require different sets of permissions and applications.
- Admins want consistency without manual setup
- Electric is evolving toward repeatable, template-based on/offboarding
Our Admin Users
Technical Tod
IT Manager - frustrated - wants more functionality
Non-technical NatHR manager - anxious - wants Electric to be the IT expert
Given Solution vs. Current Reality
‘
PROPOSED SOLUTION ( OLD PRODUCT)
The initial request was to recreate this legacy settings page in our new product. It was a monolithic approach that worked in the old system but didn't align with our new product's architecture.
EXISTING STATE (NEW PRODUCT)
Our new product intentionally separates these concepts across dedicated sections. We already had org-wide application settings, but adoption was low. This raised key questions: Was it hard to find, or did admins need more granular, group-specific controls?
EXPLORATION
I like to start projects in Figjam so I can get ideas across quickly.
Typically I work with my PM and use AI-assisted exploration to map out flows
Mapping the Mental Model
Where should an admin tell us what applications should every employee have?
I thought of 3 directionsCompany settings pageGroups page > Default groupApplication Details
The goal at this stage was to explore the space broadly and make an informed decision.
I’ll walk through each option, the tradeoffs we discussed, and why we ultimately landed where we did.
Direction 1: Company-level settings
Pros:
Clear mental model: "company defaults live in company settings"
Familiar pattern from old product
Easy to discover and update
Cons:
Settings become divorced from the group/application context where they're applied
Creates two mental models: company defaults vs. group-specific app settings
Direction 2: Default group
Learning from a previously failed concept
The default group lived on our groups page. The purpose of it was to tell our platform what applications should everyone in an organization get.
This feature was poorly adopted and we ended up removing it due to confusion from customers. So instead of dismissing it outright, I wanted to understand why.
Why did it fail?
Invisible and unexplained in the UI
No visual hierarchy or inheritance
Inconsistent naming across the product
No onboarding or setup moment
How could we make it work?
Clear naming
Explicit first-time setup flow
Visual hierarchy on the Groups page
Revamped default group creation experience
Direction 2: Default Group Form Ideas
At this stage, I didn’t want to jump straight into high-fidelity design or risk overdesigning. Instead, I focused on getting ideas across quickly so my PM and I could evaluate direction before committing to scope.
I used Claude to quickly sketch out a possible default group setup flow
Pros:
Settings live where they're applied (contextual) Cons:
Requires significant UX/FE work to show hierarchy clearlyDecision
We decided ultimately that the cost was too high, this would require significant UX and frontend work to properly communicate hierarchy and inheritance. Given our timeline, that tradeoff mattered.
Direction 3: The Winner!Application-level settings
This page already existed and already supported some org-level configuration — even though the UX wasn’t great yet — which made it a really practical place to build on rather than starting from scratch.
Pros:
Builds on an existing mental model (app-first thinking)
Keeps org-wide and group settings close to where they’re applied
Lower engineering risk by extending existing patterns Tradeoffs:
Less holistic view of all access rules at once
Requires careful UI to communicate conflicts and overrides
Feedback & Buy In
So this looks like a lot of touchpoints, that's because they were. We wanted to involve the right people, not trying to get approval but to reduce any risks or surprises down the road.
Wireframe and Prototyping
Once we had alignment internally, I moved into prototyping and testing with customers.
Due to scheduling challenges, we ended up compressing what was originally planned as two weeks of validation into about two days.
Group based settings prototype
Who we tested with:
User 1: Technical Tod
Role: IT Manager
User 2: Non-technical NatRole: HR Manager
Post Testing: IA
Before: Group Settings tabBefore: Access tab
After: Combined Settings & Access tabsUpdated design
We had too many tabs. Non-technical Nat (User 2) especially struggled to understand how everything connected. The information architecture just wasn't working.
Our Technical Tod (User 1) told us something that really reframed our thinking: 'Settings feel like a sub-category of access.' We'd been forcing people to think about these as separate things when they're naturally connected.
What we updated:
- Unified company-wide settings, group settings, and access into one tab
- Moved URLs under Management
- Separated the users table into its own tab
- Updated the toggle in the access section to radio buttons because toggles should be used for immediate actions
Post Testing: Content
Non-Technical Nat (User 2) said, “I don't want to override my company-wide settings. I'm very nervous to change all this.” They rated their confidence at 1 out of 5 because they were genuinely scared of breaking something.
Content updates
- Updated language: “Configure Override” → “Edit Settings”
- Updated “Company-wide Settings” and “Group Settings” to “Default Settings” and “Custom Settings”
- For access, we used more plain language terms: Updated “Company-wide Access” to “Everyone in the organization” and “Employee groups” to “Limited access”
Before: Scary language After: Safer language
Handoff & Future
Sneak peek on how I like to handoff work
Post Testing Collaboration
After testing, we had to work quickly to make the internal deadline.
Here’s a look at our expedited timeline
PM = Product Manager
Des = me
Eng = Engineer
Delivery & Impact
What We Shipped
A new custom settings experience that consolidated controls into one location for our 4 top applications (Google, Microsoft, Slack and Zoom)Status
Feature shipped to production one week before my departure in January 2026Measuring Success
While I didn't see post-launch metrics, we designed success around:
- Adoption of custom settings
- Reduced manual configuration time during employee onboarding/offboarding
Key Takeaways
Simplicity requires iteration
Research can be unglamorous - the no shows, the rescheduling, but it’s worth it if resources allow.
Testing led to a design both user types could navigate successfully.
Collaboration isn't about getting approval
We involved the right people early, not to seek permission but to surface risks and build shared understanding.
Some reviews were quick "heads up" check-ins; others uncovered critical technical constraints that shaped our direction.
This approach meant when we needed to move fast later, everyone already knew the context.
Documentation case study