Case Study

UX Case Study

Booking Rules at Scale

This project focused on making complex booking policies understandable at scale. By aligning the UI with how admins reason about policy — who, what, and under which rules — I created a system that supports bulk rules, clear overrides, and predictable outcomes.

The design emphasizes transparency, composability, and scalability, turning complex permission logic into a clear, maintainable system that grows with the organization.

UX Case Study

Booking Rules at Scale

This project focused on making complex booking policies understandable at scale. By aligning the UI with how admins reason about policy — who, what, and under which rules — I created a system that supports bulk rules, clear overrides, and predictable outcomes.

The design emphasizes transparency, composability, and scalability, turning complex permission logic into a clear, maintainable system that grows with the organization.

UX Case Study

Booking Rules at Scale

This project focused on making complex booking policies understandable at scale. By aligning the UI with how admins reason about policy — who, what, and under which rules — I created a system that supports bulk rules, clear overrides, and predictable outcomes.

The design emphasizes transparency, composability, and scalability, turning complex permission logic into a clear, maintainable system that grows with the organization.

Role & Context

Role & Context

Role & Context

Role: Sn. Product Designer

Product Area: Enterprise Workplace & Space Management

Primary Users: Workplace Admins, Facilities, IT

Scope: Global organizations with complex locations and hybrid work policies

Problem

Problem

Problem

As organizations scale, booking policies become increasingly complex:

Different rules per location

Different permissions per team or role
Frequent exceptions for individuals
Need for bulk changes without breaking existing policies

Existing systems failed because:

Rules were tightly coupled to single locations or users
Exceptions required duplication
Admins couldn’t predict which rules applied when multiple overlapped

This led to:

Inconsistent employee experience
Meeting rooms and workspaces are often booked incorrectly or underused.
Managing these spaces requires significant administrative work and increases the risk of mistakes.

Goal

Goal

Goal

As organizations scale, booking policies become increasingly complex:

Different rules per location
Different permissions per team or role
Frequent exceptions for individuals
Need for bulk changes without breaking existing policies

Core Insight

Core Insight

Core Insight

Admins think in terms of policy scope, not configuration steps:

Who → can book what → under which rules

Admins think in terms of policy scope, not configuration steps:

Who → can book what → under which rules

Admins think in terms of policy scope, not configuration steps:

Who → can book what → under which rules

The UI needed to reflect this mental model exactly, or the system would feel unpredictable.

Solution Overview

Solution Overview

Solution Overview

The solution is built around three explicit, always-visible components:

Spaces – where the rule applies
People – to whom the rule applies
Rules – what constraints are enforced

Each booking rule is a self-contained policy object that combines all three.

Entry Point: Booking Rules List

Entry Point: Booking Rules List

Entry Point: Booking Rules List

Why This Matters

Admins begin by reviewing an overview before jumping straight into creating something new.

Filters help narrow down results by:
- Location
- Org unit
- Space type

The “New rule” option appears in context, rather than as a separate feature.

FAANG principle:

Focus on helping users understand the information before asking them to take action.

FAANG principle:

Focus on helping users understand the information before asking them to take action.

FAANG principle:

Focus on helping users understand the information before asking them to take action.

Rule Creation Pattern: Side Panel

Rule Creation Pattern: Side Panel

Rule Creation Pattern: Side Panel

Why a Side Panel?

Keeps the context from the list clear

Enables rapid iteration across multiple rules
Helps prevent confusion that often happens with full-page forms

Admins can always see:

Selected spaces

Selected people
Active rules

Step 1: Selecting Spaces (Where)

Step 1: Selecting Spaces (Where)

Step 1: Selecting Spaces (Where)

Design Decisions

Hierarchical location tree (All locations → Floor)

Bulk selection at any level (campus, building, floor)
Visual indicators for:
- Space type (Desk, Bench, Meeting room)
- Ownership (Me / We)
- Org unit

Why this works:

Mirrors how facilities teams think
Reduces selection errors
Makes bulk rules intentional and visible

Step 2: Selecting People (Who)

Step 2: Selecting People (Who)

Step 2: Selecting People (Who)

Key Capabilities

Select:
- All people on a floor
- Individual users
- Mixed selections

Role visibility (Basic vs Privileged)
Live counts (“80 of 80 people”)

Key UX safeguard:

Admins can quickly see the scope and impact.

Step 3: Defining Rules (What)

Step 3: Defining Rules (What)

Step 3: Defining Rules (What)

Rule Design

Rules are:

Atomic (one concern per rule)
Composable
Independently removable

Examples:

Advanced booking window
Required check-in
Maximum booking duration

FAANG rationale:

Avoid compound logic → reduce cognitive and maintenance cost.

FAANG rationale:

Avoid compound logic → reduce cognitive and maintenance cost.

FAANG rationale:

Avoid compound logic → reduce cognitive and maintenance cost.

Bulk Rules vs Individual Overrides

Bulk Rules vs Individual Overrides

Bulk Rules vs Individual Overrides

Bulk Policy Example

All people on Floor 01 can book desks up to 2 weeks in advance.

Applied once
Affects dozens of users
Easy to audit and change

Individual Override Example

A specific user has required check-in disabled.

No duplication

No global rule breakage
Clear visual distinction

Rule Precedence (Predictability)

Rule Precedence (Predictability)

Rule Precedence (Predictability)

To eliminate ambiguity, rules follow a strict hierarchy:

Individual user rules

Group rules
Location-level rules

This is reinforced by:

UI ordering
Scope labels
Explicit selection context

Admins never need to “test and see” what happens.

Error Prevention & Safety Nets

Error Prevention & Safety Nets

Error Prevention & Safety Nets

Bulk Policy Example

Explicit impact counts

Clear remove actions for:
- Spaces
- People
- Rules

Cancel vs Save separation
No destructive defaults

Design philosophy:

Admin mistakes should be hard to make and easy to undo.

Design philosophy:

Admin mistakes should be hard to make and easy to undo.

Design philosophy:

Admin mistakes should be hard to make and easy to undo.

Impact

Impact

Impact

Admin Efficiency

Setting up new locations now takes less time

Fewer duplicated rules

There is now less work for support teams

Employee Experience

Predictable booking behavior

Fewer denied or conflicting bookings

System Scalability

Helps the organization grow and adapt to changes in structure

You can add new rule types without redesigning the system.

What I’d Improve Next

What I’d Improve Next

What I’d Improve Next

help

Simulate rule conflicts to see what will happen before you save changes.
Visualize how rules are inherited in the system.
Track all changes with an audit log and change history.
Analyze how effective your rules are with built-in analytics.

Process

Testimonials

Process

Testimonials

Process

Testimonials