A settings migration inside Cisco Webex Control Hub. I owned the design across two product teams, from research through to the validated final flows.
The brief, in plain terms
Slido is the live-polling and Q&A tool you have probably seen in a meeting. Cisco bought it and folded it into Webex, but it still had its own separate admin settings page. So any IT team using both had to bounce between two different places to manage one set of tools.
What I did
I designed how Slido's settings moved into Control Hub, the single place Cisco wanted admins to manage everything. Rather than copying the old layout across, I restructured it around how admins actually think, and worked across two product teams to get that restructure approved.
2 → 1
Admin portals unified in Control Hub
4 tabs
Settings IA, deliberately restructured
Multi-level
Scoped admin access model
Role
UX Designer Webex Team · Cisco
Type
Professional Work Settings Integration
Timeline
January 2025 – April 2025
If you're skimmingThree decisions that shaped this project
The brief
Migrate Slido org settings into Control Hub as-is. One tab, direct port, low research lift.
Decisions I made
Argued against a direct port and re-derived the IA from admin mental models
Pushed for SAML SSO visibility inside the Slido tab despite cross-team pushback
Widened scope to pull in billing, domain claim and scattered Control Hub config
What shipped
Four-tab structure replacing two fragmented surfaces
Multi-level admin access with scoped permissions, and onboarding walkthrough for new Control Hub users
Impact
6
Admins tested across two user archetypes
4 mo
Ideation to validated final designs
1
Unified tab replacing two fragmented surfaces
4
New features added beyond core migration scope
Business driver
Slido had been part of Cisco for years, running as a separate product. The top-down strategic call was to consolidate: Control Hub becomes the single admin surface for the Webex suite, Slido becomes a consumer-facing app. IT admins had been managing settings across two separate platforms with no clear relationship between them, increasing the risk of missed settings and admin frustration at scale.
↓ FrictionSingle platform for all Slido admin config
↑ AdoptionEasier onboarding for new Control Hub admins
Before
Org settings managed in the Slido admin portal
User management separately in Control Hub
Context-switching between two platforms
No unified admin role model across both tools
→
After
All Slido settings in one tab within Control Hub
Multi-level admin access with scoped permissions
Onboarding walkthrough for new users
Settings deliberately restructured per tab context
My role, precisely
What I owned
Information architecture and the four-tab structure, built from existing Slido org settings as reference but substantially restructured
Research plan and synthesis across two user groups
Enforce/override permission model
Multi-level admin access proposal
Design through to validated final flows
What the team owned
Slido PM: scope commitment and stakeholder sign-off with the Slido team
Slido engineering: built the feature, monitored closely by Control Hub dev
Meetings, Vidcast, Webex App: involved at key integration points
Sign-off: restructuring the settings taxonomy required approval from Slido PM and Slido stakeholders
The Problem
If you ran both Slido and Webex, managing them felt like keeping two sets of keys for one house. Some settings lived in one place, the rest in another, and nothing told you how the two related.
Organisations using Slido alongside Webex faced a fragmented admin experience. Settings lived in two separate places: org-level and admin configuration in the Slido admin portal, and user management in Control Hub. Admins had to context-switch between platforms to complete basic configuration tasks, with no clear relationship between the two systems.
The goal was to migrate Slido's organisation-level settings into Control Hub, bringing everything under one roof and to do it in a way that felt native rather than bolted on.
"Admins should not have to remember which platform holds which setting."
Design principle
⊞
Org-level settings and configuration
◎
Admin roles and access permissions
↯
SSO, billing and domain configuration
⌁
Onboarding and migration guidance
Information Architecture
While the hierarchy on both sides appears simple at each level, settings within each tab have been deliberately reorganised to best suit their context, migrating from a fragmented portal into a unified, purposeful structure.
Navigating the brief
Making the case to the triad
Sign-off sat with the Slido PM and stakeholders, not just my immediate team
Every structural decision had to be argued across two product teams
The Slido team owned the portal we were replacing
Made the case: Control Hub admins reason by context, not by Slido's feature taxonomy
Working outside the immediate product area
Meetings, Vidcast, Webex App and Control Hub dev all involved at integration points
SAML SSO placement required negotiating with Control Hub's broader platform architecture
Billing and domain claim pulled in ownership from other surfaces
The design couldn't stay inside one team's lane
Sign-off sat across two product teams and several adjacent surfaces, so every structural decision had to be argued, not just designed.
The fork
Path not taken
Direct port: lift Slido's existing settings groupings into a Control Hub tab as-is. Faster to ship, less research, lower risk to the Slido team's mental model.
→
Path chosen
Re-derive the IA from admin mental models. Control Hub admins reason by context: where am I configuring this, for whom? Not by Slido's feature taxonomy. Staged restructuring, highest-priority settings first.
Beyond the structural IA decision, one specific placement call drew the sharpest cross-team disagreement.
The sharpest disagreement
SAML SSO already exists in Control Hub. Surfacing it inside the Slido tab meant it appeared in two places. Stakeholders pushed back: two surfaces for the same setting causes confusion.
→
The argument that won
Slido participants aren't always internal users. A company running Slido for external audiences needs participant sign-on SSO to live where they configure Slido, not buried in broader Control Hub security settings.
Research
Group A
Existing Control Hub + Slido users
IT administrators already managing Webex in Control Hub who also use Slido, familiar with both products but navigating them separately.
3 participants
Group B
Standalone Slido users
Admins managing Slido independently without a Webex/Control Hub setup, being introduced to the integrated experience for the first time.
3 participants
Research Goals
01
Discoverability
Can admins find specific Slido settings within the new tab structure without explanation?
02
Labels and groupings
Do the terminology and categorisation reflect how admins think, not how the backend is structured?
03
Enforce / override pattern
Do admins understand the permission model without needing formal explanation?
04
Task completion
Can admins complete common config tasks without confusion or dead ends?
05
Transition comprehension
Do admins understand they are moving from the Slido portal to Control Hub?
Key Findings
Finding 01
Structure validated
Validated
Users responded positively to the tab-based division and hierarchy. In direct comparison to older designs, the new structure was clearer and easier to navigate.
Finding 02
Admin access concerns
Concern
Control Hub users worried that granting full Slido admin access could unintentionally affect other Webex settings. SSO login behaviour also surfaced as unclear.
Finding 03
Learning curve anxiety
Concern
Standalone Slido users were interested in the integration but worried about the learning curve. They needed reassurance that the migration would be guided, not abrupt.
"If a Slido admin has full access in Control Hub, will that affect our other Webex settings too?"
Research participant, Group A
Research to design pivots
Finding 02
Control Hub users worried that granting Slido admin access could unintentionally affect other Webex settings. SSO login behaviour was also flagged as unclear.
→
Design response
Tiered permission levels scoping Slido admin access specifically to Slido settings. SAML SSO visibility surfaced inside the Slido tab with explicit scope labelling. Won the stakeholder argument: external Slido participants need their own SSO path.
Finding 03
Standalone Slido users were interested in the integration but worried about losing familiarity with a portal they had used for years.
→
Design response
Guided onboarding walkthrough for users new to Control Hub, reducing learning curve anxiety without disrupting the existing Control Hub admin experience.
Design Exploration
Early explorations mapped Slido's settings taxonomy to Control Hub's tab conventions. Each tab was explored independently to ensure settings felt native to their context rather than directly ported from the Slido portal.
ExplorationsExploration: General settings, Allowed Slido app access and sidebar configuration
1 / 4
Design Response
◎
Solution 01
Multi-level admin access
Tiered permissions scoping Slido admins to Slido settings only, no impact on broader Webex controls.
⊞
Scope growth
Unified Slido tab
Pulled billing, domain claim and SAML SSO from across Control Hub into one tab. A unified surface had to actually be unified.
→
Solution 03
Onboarding walkthrough
Guided introduction for standalone Slido users new to Control Hub, addressing the learning curve anxiety from research.
✓
Solution 04
Redesigned settings flows
Full validated flows: tab structure, enforce/override patterns, and role-based access all integrated and tested.
Final Designs
High-fidelity screens showing the four-tab structure: General, Features, Privacy, and Present mode. Settings within each tab were restructured to match the context in which admins configure them.
Final DesignsGeneral: General settings: Slido app access and sidebar configuration
1 / 4
The verdict
Original brief
Direct migration
Port Slido settings into Control Hub as-is
What shipped
Restructured IA
Four tabs built from admin mental models, not Slido's taxonomy
We walked into research with a first draft already built, based on our own read of how admins group settings. Testing it is what got us to the four tabs we shipped, so the draft earned its keep. But I'd change the order next time. If I'd run a round of unmoderated sessions first, just watching admins move through Slido and Control Hub on their own with nothing to react to, we'd have had their mental model before drawing anything. We landed on the right structure. I'd just rather get there by watching than by correcting.
That is the summary. The full case study covers the research, the design decisions and the final screens in detail.
Unlocked. The full case study continues below.
Password protected. Available on request via email or LinkedIn.
