Zoom App settings redesign

Make it easier for users to find, understand, and adjust settings without frustration.

Background

Role
Lead content designer, Information architecture and taxonomy lead

Goal
Make it easier for users to find, understand, and adjust settings without frustration.

Stakeholders
Product design, UX research, Engineering, Accessibility

Overview

Zoom's client settings had grown organically over time, leading to inconsistent language, uneven grouping, and a high cognitive burden for users trying to configure their experience. As the platform expanded, settings became harder to scan, learn, and maintain.

This project focused on restructuring the information architecture and standardizing language patterns across settings to create a clearer, more predictable experience for users—and a scalable system for teams building and maintaining settings moving forward.

Impact snapshot
  • Reduced cognitive load by standardizing language and control patterns across settings.
  • Reorganized settings around user intent rather than feature ownership.
  • Established a scalable language model and UX framework to support future settings work.

The challenge

The existing settings experience suffered from several systemic issues that compounded over time, creating both usability challenges for customers and content debt for internal teams.

Interactive diagram
1
2
3
4
5

The approach

My approach focused on treating settings as a system rather than a collection of individual controls. I began with a full audit of existing settings to identify inconsistencies in grouping, language, and component usage, then partnered with PMs on the audit and background, design on the configuration options, and engineering on the weekly shipping and build process—prioritizing clarity, predictability, and long-term scalability.

Sync and async work process

We laid out weekly sync and sprint expectations from the start. About 30% of my time went to this process.

  • Sync: 2 meetings per week (PM in US time; designer in China on UX patterns) + 8–10 hours a week on designing.
  • Async: Design systems and accessibility throughout—documenting in shared docs and Figma, flagging blockers with clear questions, so we didn’t need constant direction.
Audit and inventory

Many usability issues stemmed less from individual settings than from the lack of shared rules. I ran a full component-level audit of the settings surface to capture:

  • Current information architecture and redundant or overlapping categories
  • Repeated behaviors expressed using different language
  • Inconsistent label structures
  • Control-type usage — which components were overused, misused, or misaligned with user intent
  • Current default state for each setting
  • Settings that needed sunsetting or relocation

I collaborated with 8 different PMs to work through these details. Many were happy to have a long-awaited opportunity to improve settings they had wanted to address for years.

Settings audit 1
Information architecture redesign

Legacy settings sections were inconsistently grouped due to rapid platform growth. New groups were based around user mental models, not feature ownership, so users could quickly answer: "Where would I expect this setting to live?"

Key decisions included:

  • Grouping by outcomes (e.g., Audio, Video, Share screen) unless a product needed its own robust settings (e.g., Meetings and webinars, Phone).
  • Ordering settings by frequency of use.
  • Introducing clearer separation between common settings and advanced configuration.
Legacy IA vs Current IA comparison diagram
Content principles that guided the work
Clarity over simplicity

Settings should be clear and tell you what to do—not just short and neat.

User mental models over feature ownership

IA organized around how users think about finding settings, not how teams own features.

Language mirrors system behavior

Content reflects what the system actually does. Labels describe state or outcome, not the action.

Components as content decisions

Toggles, buttons, dropdowns were chosen for what they communicate to users and assistive tech, not just UI.

Component decisions

Component choices were content decisions, created in tandem with language patterns. Each control communicates meaning about behavior, scope, and impact.

  • Specificity: Enough for consistency (usage rules, label patterns) without over-specifying—e.g. when to use toggle vs radio, not exact wording for every setting.
  • Partnership: Accessibility and localization for consistency, scalability, and global readiness.
  • WCAG 2.1: Labels describe state or outcome for screen readers; control semantics match the interaction model; we avoided patterns that increase cognitive load for keyboard and assistive tech users.
  • Control type was selected by user decision model and impact. Related research is documented here.

Toggles — Binary settings with immediate or consistent behavior; labels describe the state, not the action.

Toggles

Radio buttons — When only one option can be selected from a defined set; makes exclusivity clear.

Radio buttons

Dropdowns — For choices that affect defaults, formatting, or routing; reduces visual clutter when more than 3 options.

Dropdowns

Buttons — For explicit actions (reset, manage, open); not used for stateful settings.

Buttons

Advanced sections — Less frequently used settings were grouped into Advanced sections to reduce complexity and cognitive load.

Advanced sections
Zoom settings (older)
Zoom settings (new)

Drag the slider to compare before and after

Standardizing language patterns

Labels mixed actions, states, and outcomes—forcing users to reinterpret meaning line by line. I defined a settings language model with clear rules and applied it across the product.

Language rules
  • Labels describe state or outcome, not the action
  • Consistent sentence structure across similar settings
  • Avoid ambiguous verbs like "Enable" or "Allow" when behavior isn't explicit
  • Helper text only when clarification is required
Constraints

PM approval for larger name changes; we couldn't change settings that lived in connected UI without approval. We prioritized high-impact, low-dependency changes and batched multi-surface renames for upfront alignment.

Standardizing language patterns
Example: Zoom Updates

Instead of "Automatically keep my Zoom up to date" (action), we used "Update Zoom Workplace automatically" with helper text. Replaced checkbox + dropdown with toggle + radio buttons. Radio options now include parentheticals (e.g., "Slow (fewer updates, more stability)") so the outcome is clear before users choose.

Zoom Updates (before): checkbox and dropdown
System updates (after): toggle and radio buttons

Drag the slider to compare before and after

Documenting and shipping the work

Once the settings model and language patterns were finalized, I documented each setting at a shipping-level of detail to ensure clarity and consistency throughout implementation. We wanted to double-document: a spreadsheet mapped past features to their changes (mostly for engineers), and Figma captured the same decisions visually so teams could see behavior patterns as needed. This documentation served as a shared source of truth across design, engineering, and accessibility.

Documenting and shipping the work
2
1
3
4

Key learnings

Settings are one of the most frequently used yet least forgiving areas of a product. When language and structure are inconsistent, users feel uncertain—and uncertainty erodes trust. By standardizing how settings are grouped, documented, and controlled, this work improved user clarity while reducing long-term content debt.

IA redesigns are as much about people as structure

Cross-team alignment was critical.

Accessibility decisions have ripple effects

Standardizing on toggles required a shared content and design pattern across platforms.

Language patterns matter

Even small inconsistencies in label structure slow users down.

An "Advanced" section creates breathing room

Hiding complex, low-use settings gave space to test, learn, and retire without disrupting the everyday experience.

Why this work matters

While this work beta-launched after my tenure, it delivered meaningful value. This project shifted settings content from individual decisions to a documented, reusable system.

Scalable content system

A reusable foundation for future settings work.

Reduced ambiguity

Clearer language and structure across settings.

Accessibility & scanability

Improved support across the product.

Consistent decisions

Designers and PMs can make content decisions without reinventing patterns.

Back to Work
Scroll