The verticals are already a filter. The product just doesn’t know it yet.

Calendars has one dataset, two presentations, four configuration domains and two different app shells. The fastest route to a coherent architecture is not to add structure — it is to stop modelling the same idea in three incompatible ways.

The decisive evidence is in your own screenshots. Both Calendar view and Appointment list view carry a “Services” dropdown in the toolbar. That control is a vertical selector. Meanwhile, in Calendar settings, those same verticals appear as top-level tabs (Meetings, Services, Rentals, Connections).

So the product already treats a vertical as a filter in the operational plane and a destination in the configuration plane. The unified-calendar mechanism you are proposing to build largely exists — it is just implemented as a single-select scope switch instead of a multi-select facet. That reframes the work substantially: this is less a new feature than the correction of a modelling error, which materially lowers the risk of shipping it to a surface with 1.5m monthly actives.

What I agree with

• Appointments as the primary workspace, with Calendar and List as view types of one dataset. Correct, and supported by near-universal industry convergence.
• Saved Views should belong to the dataset, not the table. Correct diagnosis. Your proposed model needs one structural fix (below).
• A unified calendar is right, and “All” should be the default.

Where I disagree

• “Meetings” is the wrong name, but renaming the vertical is the wrong fix. The collision is one level down: the word “calendar” currently means four different things. Fix the children, keep the parent.
• Statuses are not platform-wide. They encode an appointment lifecycle (no-show, showed) that is meaningless for other objects. Keep them in Calendars.
• Connections are neither purely platform nor purely calendar. They must be split: account identity is platform, sync behaviour is Calendars.
• Verticals as flat top-level nav items will not scale — not because of nav length, but because each vertical drags a duplicate copy of Staff, Locations and Resources behind it. This is the most expensive latent problem in your proposed tree.
• The vertical should not be the headline filter in the unified calendar. Operators think staff-first and day-first. Type is one facet among several, not the marquee control.

The one structural change I would insist on

FactWe have Pendo instrumentation showing scale (251k accounts, 1.5m MAU), mid-range NPS (~47) with a recent detractor spike, 10+ distinct booking entry points, active mobile usage on iOS and Android, and a live A/B test on feature discoverability.

AssumptionWe have no user interviews and no usability testing for this problem space. Every mental-model claim in this document is reasoned from role incentives, the product’s own telemetry and comparable-product evidence — not from research with users. Section 22 proposes how to close that gap before the expensive phases ship.

What the screenshots actually reveal

Reading the six screens as an architecture rather than as a set of layouts.

The three-tab header is not a hierarchy

The Calendars header presents three peers: Calendar view, Appointment list view, Calendar settings. The first two are presentations of the same records. The third is a portal into a completely different app shell — a Settings left nav with a “← Go Back” escape hatch. One tab bar is doing two incompatible jobs: switching a view, and teleporting between shells. Users cannot form a stable model of “where am I” because the answer changes category depending on which tab they press.

“Calendar” means four things

Four referents, one word, all reachable within three clicks of each other. This is the single largest terminology defect and it compounds every other navigation problem.

The scope selector is hidden in plain sight

In Calendar view the “Services” dropdown sits between Week view and the display-options button — visually grouped with view controls. In List view the same dropdown sits immediately beside the Appointments heading — visually grouped with the page title. Identical function, two different semantic placements, so users learn it twice. And because it is single-select, the product structurally cannot answer “what is happening today across my whole business?”

Configuration outweighs operations 4:2

The product gives four top-level tabs to configuration domains (Meetings, Services, Rentals, Connections) and two to daily work. HypothesisTask frequency is inverted relative to this allocation: seeing today’s schedule and finding, creating or editing an appointment happen many times per day, while creating a service or connecting a calendar happens at setup and occasionally after. Every comparable product we examined (Square, GoDaddy, Acuity, Wix, Time2book) places the operational calendar first and pushes catalogue configuration below it.

Capability asymmetry between the two views

Two different filter entry points, two different vocabularies (“Manage view” vs “Advanced filters”), and a saved-configuration concept that exists on only one side. A user who builds a careful filter in Calendar view cannot carry it to List, and vice versa — despite both querying the same records.

Notable details worth preserving

• “Unified service view” already exists as a toggle in Manage view. The concept of collapsing multiple bookable entities into one lane is established — we should build on this vocabulary rather than inventing new terms.
• Buffer-time visibility as a display toggle is a genuinely domain-specific control with no analogue in generic SaaS. Keep it.
• “New (action required)” rendered as a red-outlined editable dropdown in the list is excellent: status is both the alarm and the control. This should become the model for status everywhere.
• Groups on the calendars list (105 ungrouped of 122) shows real-world scale and a grouping mechanism users are already under-using — a discoverability signal consistent with the live Pendo experiment.

Ranked by severity

P0 = fundamental, blocks a coherent model. P1 = major, causes daily friction or blocks scale. P2 = moderate. P3 = minor.

Five roles, five different questions

AssumptionDerived from role incentives and the personas recorded in our product principles, not from interviews. These are the hypotheses usability testing should target first.

How each role reads the current vocabulary

• “Appointments” — understood consistently by everyone. The safest anchor word in the product.
• “Calendar” — read as the grid by operators, as a bookable configuration by admins. This split is the terminology defect made visible.
• “Meetings” — read as a scheduled conversation with a person. Operators of class-based businesses will not look here for their yoga schedule.
• “Services” — strong and unambiguous. Keep.
• “Rentals” — strong and unambiguous. Keep.
• “Views” — Assumptionnot a concept most SMB operators hold spontaneously. Slack ships an in-product explainer for exactly this reason; we will need one too.

One transaction object, four bookable subtypes

The data model is what makes the unified calendar either coherent or arbitrary. It is coherent.

Grey text is annotation, not structure.

Actions, mapped by frequency

The frequency column is the IA. Everything in rows 1–5 must be reachable without leaving one workspace; everything from row 6 down can afford a click.

The tree as it stands

Red marks a structural defect. Underlined Staff, Resources and Locations inside Services are the duplication risk described in P1.

What the tree tells us

• Depth to a daily task is 1–2. Good, and worth protecting.
• Depth to a configuration task is 4–5, across a shell boundary: Calendars → Calendar settings → Services → Staff. Each hop changes the navigation frame’s meaning.
• Four concepts are interleaved in one panel. Manage view mixes filters, display options and type scope with no visual separation — the clearest single instance of the concept-mixing this project set out to fix.
• The Settings shell hosts a second, contradictory model of verticals. Same nouns, different grammar.

Design evidence, grouped by the decision it informs

Six searches across web, ~50 screens and 4 multi-step flows reviewed visually. Product names link to the source screen on Mobbin. Organised by the question each reference answers, not by product.

A · Navigation & IA

B · Calendar

C · Unified & multi-entity views

D · Saved views

E · Filtering

F · Tables

G · Configuration & settings

H · Create flows

I · Multi-type visual encoding

Only two references in this board differentiate entity types without relying on hue, and both matter disproportionately: HoneyBook’s hatched-vs-solid fill for tentative-vs-confirmed, and Confluence’s per-type icons. Everything else in the board — Amie, Front, Motion, Rise, HoneyBook’s own type dots — encodes with colour alone. HypothesisThis is a genuine gap in the market rather than a solved problem, which means we should not expect to find a pattern to copy and should design the encoding system deliberately (§12).

J · What the board does not support

• No product in this board exposes business verticals as top-level navigation. Square, GoDaddy, Acuity, Wix and Time2book all organise by object class or audience. That is a meaningful absence given how many multi-offering scheduling products were sampled.
• No product ships more than three primary view types over a calendar dataset. ClickUp’s eleven tabs are the visible failure mode.
• Only one product (Wix) splits Calendar and List into nav siblings — and it duplicates its filter panel as a result.

What the evidence converges on

Six conclusions

1. The four-part header grammar is settled. Dataset title → view type → named saved view → filter chips, each with a distinct control shape. Motion, Height, GitHub, Airtable and Todoist all land within a small variation of this. We should adopt it rather than invent.
2. Dirty state is the mechanism that makes saved views usable. Without it, users either fear touching a saved view or accidentally overwrite a shared one. Height’s three-exit contract (Revert / Save as / Save) plus Zapier’s contextual placement is the complete solution.
3. Filter legibility beats filter power. Airtable naming the active filter in the chip is worth more than condition groups. For a system of record, a silently-filtered calendar is a trust failure — the user concludes appointments have vanished.
4. Type belongs in a toolbar pill, not a sidebar. Amie’s count-bearing pill preserves grid width, scales via search, and states its own state. Our existing right-hand Manage view panel should keep the long-tail dimensions and hand the type facet to the toolbar.
5. Two view types, hard cap. Calendar and List. ClickUp demonstrates the failure of unbounded types; nothing in the board suggests a third earns its place for scheduling.
6. Creation resolves type through the bookable, not through a mode switch. Time2book’s grouped picker is better than Square’s explicit type field because it removes a decision while still teaching the taxonomy.

Design principles

Eight principles to govern the redesign. Where they refine the brief’s starting hypothesis, I say so.

Four models, evaluated

Option D emerged from the entity model and is not in the brief. It is the one I recommend.

Option A — Appointments-first, verticals as siblings (the brief’s hypothesis)

Mental model: “My schedule, then the things I offer, then how it all works.”

• Strengths: Correctly separates operations from configuration. Direct access to each vertical. Minimal conceptual leap from today’s Settings tabs, so migration reads as a promotion rather than a restructure.
• Weaknesses: Nav grows linearly with verticals. Critically, it provides no home for shared objects — Staff, Locations and Resources must either live inside each vertical (duplication) or inside Settings (wrong: they are operational catalogue data, edited weekly, not system configuration). This is the flaw that disqualifies it as-is.
• Scalability: Poor past ~5 verticals. Discoverability: Good. Ops efficiency: Good. Config efficiency: Poor — configuring Jane Doe means visiting N verticals. Migration: Low. Verdict: Right instinct, incomplete object model.

Option B — Vertical-first

Mental model: “Pick the part of my business, then work inside it.”

• Strengths: Each vertical is self-contained and independently shippable — genuinely attractive from a delivery and team-ownership perspective. Matches the agency admin’s mental model. Permissions map cleanly onto verticals.
• Weaknesses: Structurally forecloses the unified calendar — the primary business question becomes unanswerable by design. Duplicates Calendar, List, filters and saved views N times. Four of five roles do not think in verticals. Staff duplication is not merely likely but mandatory.
• Scalability: Poor. Discoverability: Poor — “where do I see my day?” has N answers. Ops efficiency: Poor for multi-vertical, fine for single. Config efficiency: Good within a vertical, bad across. Migration: Lowest — it is roughly today’s model. Verdict: Reject. Optimises for the org chart, not the user.

Option C — Hybrid: Appointments + a single catalogue node

Mental model: “My schedule, my offerings, my people, my rules.”

• Strengths: Nav stays at four items regardless of vertical count — handles the 10-vertical case cleanly. Shared objects get a proper home. Conceptually the tidiest tree.
• Weaknesses: Adds a click to every configuration task and introduces an abstraction (“Catalogue”) that no user asked for. Hypothesis“Catalogue” is retail vocabulary that a plumber or a law firm will not adopt; the Mobbin board offers no support for it in a scheduling context (Square’s comparable “Library” is equally opaque). A single-vertical salon now navigates Catalogue → Services instead of Services.
• Scalability: Excellent. Discoverability: Moderate — depends entirely on the parent label landing. Ops efficiency: Good. Config efficiency: Good. Migration: Moderate. Verdict: Structurally strong, linguistically weak.

Option D — Appointments-first with adaptive verticals and extracted shared objects Recommended

Mental model: identical to Option A — which is the point. It preserves the brief’s instinct while fixing its two structural gaps.

Two changes do the work:

1. Verticals render conditionally. A salon sees Appointments / Services / Staff & resources / Settings — four items. An agency sees Appointments / Booking calendars / Staff & resources / Settings. Nobody sees a vertical they do not use. This dissolves Option A’s scalability problem without Option C’s abstraction, because nav length now tracks what the account actually does rather than what the product supports.
2. Shared objects are extracted into one destination that every vertical references.

The + Add booking type row is a deliberate second job: it converts navigation into the discoverability surface our live Pendo experiment says we need. A salon that has never noticed Rentals exists now encounters it in the one place it is guaranteed to look.

• Scalability: Excellent — nav length is a function of account configuration, not product surface area. Discoverability: Excellent, and actively improves it. Ops efficiency: Excellent. Config efficiency: Excellent — shared objects configured once. Migration: Moderate — requires the shared-object extraction, which is the real engineering cost. Future verticals: Adding one is a feature flag plus a catalogue screen, with no impact on Appointments.

The tree, and the naming decisions behind it

Naming decisions

How this maps onto the platform left-nav prototype

The prototype’s product → subproduct → context model fits without strain. Calendars is a product row in the main nav; its flyout contains the eight rows above. Two specific recommendations for the prototype’s own mechanisms:

• Appointments should be dockable. The prototype’s floating dock band holds pinned destinations (Conversations, Contacts, Workflows, Invoices, Dashboard). Appointments is a many-times-daily destination and belongs there for scheduling-led accounts; the verticals belong in the flyout. This uses the prototype’s existing affordance rather than asking it for new capability.
• The flyout must render conditionally too. If nav hides disabled verticals, the flyout must respect the same rule, or the two surfaces disagree about what exists.
• Trade-offThe prototype spends 56px on the account rail plus 272px on the nav — 328px of chrome before content. A staff-column calendar for six staff at a usable column width needs roughly 900px. On a 1280px laptop that is tight but workable with the nav collapsed to 64px; the calendar should auto-collapse the nav on first entry at viewport widths under 1400px, which the prototype already supports as a state.

One workspace, one header grammar

The brief proposes a specific header. It is close to right; I would change two things and add one.

What I changed from the brief’s proposal

1. Two rows, not one. Row 1 is identity and scope — what dataset, which presentation, which saved view, how many results. Row 2 is manipulation — when, what subset, how displayed, create. This matters because row 1 answers “where am I” and row 2 answers “what am I doing”; collapsing them into one line is why the current toolbars read as an undifferentiated pile of chips. Trade-offCosts ~40px of vertical space. On a day grid that is roughly one 30-minute row — acceptable, and recoverable by collapsing row 2 on scroll.
2. “Views ▾” becomes a named chip in row 1, not a dropdown in row 2. The active saved view is identity, not a control. Motion does exactly this and it reads unambiguously: the chip states which lens you are looking through, and clicking it opens the picker.
3. Added a result count. “142 appointments” for the current range and filters, borrowed from Acuity. This is the cheapest possible defence against the trust failure in Principle 06 — an operator who sees an unexpectedly empty week immediately knows whether it is empty or filtered.
4. “Staff” promoted out of Filters. Four of five roles think staff-first. Making it a peer chip rather than a row inside a panel reflects actual usage frequency; it remains available inside Filters as well.
5. “+ New appointment” is a split button. Primary action creates an appointment; the caret offers Block time and Add to waitlist. Acuity promotes blocking to a peer for good reason — operators do it many times daily.

Full component inventory

Yes — but type is not the headline

1. Is a unified calendar good UX?

Yes. Three independent lines of evidence agree. The entity model (§5) shows all verticals produce the identical object, so unification is a query, not a merge. The mental models (§4) show four of five roles have no concept of vertical, so per-vertical scoping imposes a boundary users do not hold. And the product itself already ships a single-select vertical scope in both toolbars — the mechanism exists; we are removing a constraint, not adding a feature.

The strongest argument, though, is negative: cross-vertical conflicts are currently invisible. If Jane is booked for a Service at 2pm and a Meeting at 2:15pm, no current screen can show both. That is not a convenience gap, it is a correctness gap in a system of record — and it gets worse with every vertical added.

2–3. Mental model, and when it breaks

HypothesisThe model users hold is “my business’s time” — a single physical reality of who is busy when. The vertical is invisible in that model, which is why unification feels natural rather than clever.

It breaks in three specific situations, each of which needs a designed answer rather than a warning:

• Different time granularities collide. A 30-minute haircut and a 4-day villa rental cannot share a week grid legibly. Answer: multi-day bookings render in the all-day band at the top, never as tall blocks in the time grid — the same treatment calendars already give all-day events. Rentals therefore read as a horizontal bar spanning days, which is also how the mental model works.
• Different capacity semantics collide. A class holds 12; a room holds 1. Answer: capacity renders as a fraction on the block (8/12), and the block is only visually “full” when capacity is reached — not when one booking exists.
• Volume asymmetry. A business with 400 service appointments and 3 rentals per week will find rentals lost in the noise. Answer: this is the case for saved views, not for splitting the calendar — “Rentals only” is one click, and the type chip states that 3 of 403 are visible.

4. Visual differentiation — the encoding system

The Mobbin board (§7I) shows only two products differentiate types without hue. So this must be designed rather than borrowed. Four channels, in priority order:

Glyphs stand in for lucide icons (users / sparkles / package / truck). Note the rental in the all-day band, capacity as a fraction on the class, travel time on the home service, and that every distinction survives greyscale.

5. Which dimensions should filter

6–8. Default, persistence, saveability

• Should “All” be the default? Yes. For single-vertical accounts — Assumptionthe majority — All and “Services only” are the same set, so All is free. For multi-vertical accounts it is the only way the unified view is ever discovered, and it is the only default that makes cross-vertical conflicts visible. Choosing a single vertical as default would reproduce today’s blind spot.
• Should the selection persist? Yes, but as a personal preference, not as the default. Last-used type selection persists per user per device. Crucially, “Today” and the saved-view chip both reset it — otherwise a user who once filtered to Rentals silently loses appointments forever, which is the single most likely support-ticket generator in this design.
• Should configurations be saveable as Views? Yes — that is precisely what §13 is for. Type selection is one facet stored in a Saved View like any other.

10–11. Scale and permissions

Thousands of appointments. Density is a rendering problem before it is an IA problem. Mitigations, in order: the range window caps the query (a week is a week regardless of total volume); overlapping blocks collapse to +4 more beyond three per slot; Month granularity shows counts per day rather than blocks; the List view is virtualised and paginated. AssumptionThe genuine risk is not the grid but the query — a cross-vertical union across four tables with staff, location and status predicates needs an index review before “All” ships as default. This is the main engineering dependency of this proposal.

Permissions. The unified calendar makes a latent problem urgent: it will surface appointments from verticals a user may not be entitled to see. Rules: filter at the query layer, never in the client. A staff member restricted to their own appointments sees only their column, and the type chip shows only types they can access. Where a slot is occupied by an appointment the viewer cannot see, render an opaque busy block with no detail — availability is not confidential, content is. This preserves correct booking behaviour without leaking data, and matches how Google Calendar handles free/busy.

12. Smaller screens

FactPendo shows active iOS and Android usage, so this is not hypothetical. Below 1024px: granularity locks to Day or Schedule (agenda list); staff columns become a horizontally-swipeable set with a sticky staff header; the two toolbar rows collapse into one row plus a single “Filters” sheet containing type, staff and everything else; the saved-view chip stays visible because it is the cheapest way to reach a useful subset on a small screen. Hover-dependent affordances — the dock lift, the edit-nav reveal, tooltips — all need tap equivalents.

13. Creating from the unified calendar

Click-drag a range, or press New appointment. The panel opens with time pre-filled and a single “What are you booking?” picker whose options are grouped by type — Time2book’s pattern, which I prefer to Square’s explicit type field because it removes a decision while still teaching the taxonomy. Choosing a bookable resolves the type, and the form then reveals only that type’s fields: staff and add-ons for a Service, unit and rate period for a Rental, address and travel for a Field service, host and invitees for a Booking calendar. Detail in §17, Flow 7.

Right model, one structural fix

The brief’s instinct — saved configurations belong to the dataset, not to the table — is correct and well supported. But the proposed model, in which a Saved View simply works in both Calendar and List, has a failure mode that will surface within a week of launch.

The object

One filter set, two display configs, one preference for where to land. Switching views never loses the filter; it swaps the display config.

Left: personal / shared split with result counts and a dismissible explainer (Linear + Slack). Right: types with per-type counts, an “Only this” shortcut for solo-ing a type, and blocked time as an explicit facet rather than a hidden default.

Governance

Seeded views

Every account starts with three shared, protected views so Saved Views is a populated feature rather than an empty mechanism: All appointments (no filters, Calendar/Week), Today (relative range, Calendar/Day, grouped by staff), Needs action (status in pending/unconfirmed, List, sorted by time ascending). The third is deliberately List-preferred — it is the demonstration that view type is a property of the view.

Same query, two renderers

The contract is narrow enough to state precisely, which is what makes it implementable:

URL as the source of truth. /calendars/appointments?view=calendar&range=2026-08-23..29&types=all&staff=jane&savedView=front-desk. Switching view changes one parameter. This makes the shared/not-shared contract self-evident, makes every state linkable — which the current product cannot do — and makes the migration redirects in §21 trivial.

List specifics

• Default columns: Appointment (locked, per Deel), Customer, Staff, When, Status, Service/Bookable, Source. Type is added automatically when >1 vertical is enabled and hidden otherwise — Principle 07 applied to a column.
• Available columns: location, resource, duration, price, payment status, created, created-by, confirmation number, notes, customer tags, recurrence, buffers, add-ons, capacity, custom fields.
• Column management: popover, two buckets (shown/hidden) with search, drag-reorder, count in the chip, reset to default.
• Status editing: inline dropdown in the cell, preserving the existing red-outline treatment for action-required. This is the single best interaction in the current product and should not change.
• Bulk actions: floating bar on selection — confirm, cancel, reschedule, reassign staff, send reminder, export. Destructive actions confirm with a count and, per our conservative-defaults principle, never fire notifications silently.
• Scale: virtualised rows, server-side sort and filter, cursor pagination. Row grouping by day is the default because the dataset is inherently temporal.

What each vertical owns — and what it must not

The rule: a vertical owns its bookable definitions and its booking rules. It never owns staff, locations or resources.

Staff & resources — the extracted destination

The Eligibility tab is the payoff for the extraction. Today, answering “what can Jane be booked for?” means visiting Services, then Meetings, then eventually Rentals. Afterwards it is one screen — and it is the screen that makes cross-vertical conflict detection explicable to the user rather than mysterious.

Booking pages

Each vertical has a customer-facing booking surface. RecommendationKeep each vertical’s booking-page configuration inside that vertical (as Services does today) rather than centralising it, because the content of a booking page is inseparable from the offering it presents — a rental page needs a gallery and rate table, a round-robin page needs host selection. Centralise only the shared theme: brand, colours, logo, domain, and legal copy live in Settings › Booking page appearance, which every vertical page inherits and may override. This mirrors the audience-based grouping Acuity uses and avoids a single overloaded page-builder.

Two explicit disagreements

Should Settings live inside Calendars or at platform level? Both — and the split must be principled

The test I would apply: would this setting still exist if Calendars were deleted? If yes, it is platform. If no, it belongs to Calendars.

Settings structure

RecommendationAdopt Plane’s explicit scope tabs at the platform settings level (Account · Workspace · Products) so users stop guessing which scope they are in. This is a platform-level change beyond this project’s remit, but Calendars should be designed assuming it arrives — and should not be blocked on it.

Eleven flows, end to end

The behaviours worth writing down

View switching

• Preserves filters, range, search, selection, saved view and dirty state. Swaps display config only.
• Never re-fetches if the underlying query is unchanged — the switch should feel instant, which is also what convinces users it is one dataset.
• Keyboard: C / L. Range navigation ← / →, T for today, D/W/M for granularity, / for search, N for new.

Filter behaviour

• Live apply for single-dimension chips (staff, type, status). Batched apply only inside the advanced condition builder, where a partial condition is invalid anyway.
• Chip labelling: 0 selected → dimension name; 1–2 → the value names; 3+ → “Staff 4”. Naming beats counting whenever it fits, per Airtable.
• “Clear all” is always present when any filter is active, and does not clear the date range — range is orientation, not a filter.
• A filter that would produce zero results still applies; the empty state explains which filter is responsible and offers to remove it.

Saved-view dirty state

• Any change to a stored property marks the view dirty: dot on the chip, tooltip “Modified”.
• Chip menu when dirty: Revert to saved · Save changes · Save as new view. For shared views, Save is disabled without permission and shows “Ask an admin, or save as a new view” — a dead end with an exit.
• Navigating away with unsaved changes does not prompt; the dirty state persists in the session and in the URL. Prompting on every navigation in a tool used dozens of times a day would be intolerable.

Calendar direct manipulation

• Drag to move; edge-drag to resize; both show a live conflict indicator and snap to the slot granularity. Drop outside working hours warns but permits — operators legitimately override.
• Drag across staff columns reassigns, and checks eligibility: “Sam is not eligible for Gel overlays” with Reassign anyway / Cancel.
• Every drag is optimistic with a 5-second Undo toast, and reverts visibly on server rejection.
• Multi-day and all-day items are not vertically resizable — only their day span changes.

Loading, empty and error states

Preserve the visual language; change the structure

Per the brief, the screenshots are the source of truth. The mockups in this document use the existing product’s tokens deliberately.

Trade-offThe one place I would spend new visual budget is the calendar block. Today’s blocks are uniform grey with a coloured left edge and carry only “Busy” plus a time. The unified calendar needs them to carry type, status, capacity and customer — roughly four times the information in the same space. That requires tighter type (11px, 1.3 line-height), truncation rules, and a hover/click detail popover doing more work. This is the highest-risk visual change in the proposal and the first thing I would prototype at real density with a real account’s data.

What breaks, and the designed answer

Six phases, ordered by risk

Fact251k accounts, 1.5m MAU, and a detractor spike already recorded in the last 30 days. The sequencing below is driven by blast radius, not by design coherence — the most satisfying change is deliberately not first.

What happens to existing artefacts

Rollout mechanics

• Per-phase feature flag with account-level targeting; internal, then design partners, then 1% / 10% / 50% / 100%.
• An explicit “switch back” for Phase 1 for at least one release, with a reason prompt. The reason data is worth more than the engineering cost.
• Given the recorded detractor spike, add NPS-verbatim monitoring keyed to scheduling terms for the duration of the rollout, and set a rollback trigger before shipping rather than after.
• Fact10+ booking entry points are instrumented. Every phase needs regression coverage across all of them — routing, conversation, opportunity, embed, third-party — not just the calendar page. A change that looks safe in the UI can break a booking source that never touches it.

What to measure, and what we do not yet know

Validation plan before the expensive phases

1. Tree test (unmoderated, n≈40–60, mixed roles): current IA vs Options A, C and D on eight findability tasks. Directly tests the naming decisions in §10, especially “Booking calendars” and “Staff & resources”. Cheapest high-value study available and it should run before Phase 1.
2. Moderated usability (n≈8–10, recruited to include heavy Appointment-List users and at least three multi-vertical accounts): the unified calendar at real density, Flow 7 creation, and the saved-view dirty-state contract.
3. Density prototype with real data — the highest-risk unknown. Load a genuine high-volume multi-vertical account into the encoding system and test legibility with front-desk staff on the hardware they actually use.
4. First-click test on the type chip vs a sidebar for visibility control, to check the Amie-derived toolbar-pill bet.

Thirteen screens

Screens 2, 3, 4 and 5 are rendered above. The rest are specified for design and engineering pickup.

Key interaction states to design

• Saved-view chip: default / active / dirty (dot) / dirty-shared-no-permission.
• Type chip: hidden (1 vertical) / All / named single / counted multiple / permission-limited.
• Filter chip: empty / named / counted / conflicting.
• Calendar block: confirmed / pending / action-required / cancelled / busy-external / no-permission / conflicting / recurring / at-capacity / multi-day.
• Empty states: nothing booked / filtered to zero / no verticals / no permission / partial vertical failure.
• Create panel: type not chosen / type chosen / conflict detected / eligibility warning / saving / failed-with-input-preserved.

Where this could go wrong

Decision matrix

Scored 1–5, where 5 is best. Scores are my judgement against the evidence in §7 and the reasoning in §9, not measured data.

Reading the scores. Option D loses only on migration effort — and it loses there for exactly one reason: the shared-object extraction. That is also the single change that most improves configuration efficiency and future extensibility, so the cost buys the two things the current architecture most lacks. Option C ties D on structure and loses on discoverability and mental-model fit purely on the naming problem (§9). Option A is a genuine improvement over today and is the right thing to ship if the shared-object extraction cannot be funded — note it scores 45, well clear of the current 24, so a partial adoption is still a large win. Option B scores below Option A on almost every user-facing criterion despite being cheapest to build, which is the clearest sign it optimises for delivery convenience.

The recommendation

1. Adopt Option D. Appointments as the operational hub with Calendar and List as view types; verticals as conditionally-rendered siblings; shared objects extracted; Settings scoped to Calendars with principled cross-links.
2. Ship the unified calendar with All as default, encoding type by glyph and border, status by colour, with a user-switchable “Colour by”. Gate on the query-performance work.
3. Build Saved Views as a dataset-level object with a shared filter set, per-view-type display config, and a preferred view type — the one structural correction to the brief’s model.
4. Rename “Meetings” to “Booking calendars”; keep “Calendars” as the product name. Fix the collision at the child level, where it is cheap.
5. Keep Statuses in Calendars. Split Connections. Both against the brief’s stated suspicion, for the reasons in §16.
6. Sequence by blast radius, not coherence (§21). Instrument first; extract shared objects last.
7. Run the tree test before Phase 1. It is the cheapest study available and it tests the naming decisions this whole tree rests on.

What I could not resolve from the available evidence

1. How many accounts run more than one vertical? The single most load-bearing unknown in this document. It determines whether the unified calendar is a flagship capability or a niche one, and whether Principle 07’s adaptive defaults are the main experience or an edge case. Answerable from Pendo in Phase 0.
2. How often is the vertical scope dropdown actually changed? Rarely ⇒ unification is low-risk and mostly invisible. Constantly ⇒ density is the primary design risk and the encoding system needs far more validation.
3. What is the real Smart List creation and reuse rate? If it is very low today, the Saved Views investment needs its discoverability plan strengthened before Phase 2, not after.
4. Can the cross-vertical query meet interaction latency on the largest accounts? An engineering question that gates the unified default. It should be answered with a spike, not an estimate.
5. Is Rentals genuinely time-bookable in the same sense as the others? Multi-day, stock-based, often staff-less. It fits the entity model, but if rental operators do not think of listings as living on a staff-oriented calendar, Rentals may want its own occupancy-grid presentation as a third view type — which would contradict my two-view cap. Worth testing specifically with rental accounts.
6. Does “Booking calendars” actually test better than “Meetings”? I have argued it from semantics and migration cost, not from evidence. The tree test settles it, and I would change the recommendation if the data disagreed.
7. Should the platform adopt explicit settings scope tabs? Plane’s pattern would resolve a class of confusion well beyond Calendars, but it is a platform decision outside this project’s remit. Calendars should be designed to work with or without it.
8. What is causing the recorded NPS detractor spike? Unknown, and it matters for sequencing: if it traces to a recent Calendars change, that regression should be fixed before a restructure lands on top of it.
9. Where does Waitlist belong? Square treats it as a peer of Calendar. We have no equivalent today. If it arrives, it is a third operational surface — and I would want to know before finalising the Appointments header, since it would compete for row 1.
10. How do custom objects interact with this? The current left nav shows Pets, Pet Owners and Massage Chairs as top-level items. If custom objects can become bookable, “vertical” stops being a fixed set of four and the adaptive-nav model in Option D becomes essential rather than merely preferable. Worth confirming with the platform team.

Evidence base: six current-product screenshots; the platform left-nav prototype (structure, tokens and motion extracted from its deployed source); Pendo Calendars instrumentation; and 50 screens plus 4 multi-step flows reviewed on Mobbin across 34 products. No user interviews or usability testing were available for this problem space — §22 proposes how to close that gap.