2023–2024Systems Design & Information Architecture

Auto Attendant

Call routing a small business could actually set up. The design problem was never adding power. It was making people confident enough to use it.

Live at LinkedPhone

Live today

6 → 1: Screens to add a menu option
2 → 1: Basic and advanced setup, merged into one system
Live: On iOS, Android and web, and the base Lisa was built on
8: Interface versions tested to get there

Choose your depth

The 1-minute overview

Loved. Powerful. Underused.

Auto Attendant let a small business answer its phone like a much larger one. Some customers chose LinkedPhone for it. Most never went past basic setup.

My role: Over roughly 12 months, I led the redesign, working with the founders: the audit, the competitive study, the information architecture, eight interface versions and the component set.
The key decisions: Reveal complexity instead of removing it. Replace a page-by-page setup with one list that reads like the call. Give every option the same grammar: when, during, do.
What shipped: One modular system where basic and advanced setup are the same screen at different depths, live on iOS, Android and web. It later became the call-handling surface Lisa was built into.

Two live Auto Attendant screens for BBQ Fried Chicken. Left, the simplest setup: business hours and after hours, each with one Default Handling rule. Right, the same screen grown into a full menu: a call menu message and five numbered options, each read as Press, action and who answers. — The same screen at two depths. **Left:** a business that has only set its hours. **Right:** the same business with a five-option menu. Nobody switches to an advanced mode to get from one to the other.

The full story follows, including the directions that failed and the eight versions in between. Read straight through, or start with the part you want.

See the three decisions that shaped it

The 5-minute story · Three decisions, one system

Change the exposure, not the power.

We first treated Auto Attendant as a configuration problem. It turned out to be a confidence problem.

Owners set up call routing between customers, on a phone. The live setup split it into a basic screen and a separate advanced one, and one menu option took six screens. The capability was there; the confidence wasn't.

01 Product strategy

Reveal complexity. Don't remove it.

The market's answer was the node builder, and the product we had was a wizard. Node concepts looked powerful in reviews and broke in testing: people spent more time learning the interface than setting up their business. The wizard was easy to start and hard to live in.

So we kept all of the power and changed when it appears. An option opens simple; a greeting or a setting expands in place when you reach for it.

Three states of the Sales Team option: collapsed with When, Route Call, voicemail greeting and More Settings; the voicemail greeting expanded with text to speech, voice Alex and a player; and More Settings expanded with ring order, missed call text back and no answer menu. — Progressive disclosure, on one screen. **Left:** the option as it opens. **Middle:** the greeting expanded. **Right:** the settings most people never need, expanded only on request.

The trade-off: some power users wait one tap longer, in exchange for everyone else starting at all.

Read the investigation See the direction map

02 Information architecture

One list that reads like the call.

The live setup was serial: digit, function, label, people, voicemail, then back to a list that said only Type: Route Call. By step four the owner had lost sight of the menu.

The redesign is parallel. Every option sits on one list, grouped by business hours and after hours, and each row states its path: Press 2 → Route call → 3 users. No answer → Voicemail. You can read the caller's experience without opening anything.

Before → After · The setup screen

Two screens and a tab bar, against one list where the menu's structure is visible in the rows themselves. The new list is shown whole: its top, then scrolled down.

The judgment: a summary you can scan beats a hierarchy you have to navigate.

See the original flow Follow the eight versions

03 Systems design

One grammar for every option: when, during, do.

Every option, whatever it does, is edited the same way. Learn one and you have learned them all. The simplest setup is just the defaults; advanced setups use the same blocks, more of them.

Live product · The option editor, read as a sentence

The editor is the grammar made visible: the condition in the header, then the trigger, the action, the fallback and everything else, folded.

Same system. Different depth. Nobody is moved to a pro mode; they grow inside the one they know.

See where the grammar came from Inspect the final system

What the work delivered

A system, a component set and a foundation for Lisa.

A modular Auto Attendant, live on iOS, Android and web; a set of option, audio and routing components that went into the design system; and a call-handling structure that Lisa, LinkedPhone's AI receptionist, was later built into.

My contribution: turning a feature people were afraid to touch into one they could start in a minute and grow into, without taking any of its power away.

Discuss a product challenge View my experience See the final UI Explore all the evidence

The final UI · Live today

The live product.

Every final screen in one place. Open any of them at full resolution; the full story shows how each one got there.

The simplest Auto Attendant setup beside the same screen with a full five-option menu. — From a business that has only set its hours to a five-option menu, on one screen.

The option editor collapsed, with the voicemail greeting expanded to text to speech and a voice, and with More Settings expanded to ring order, missed call text back and no answer menu. — One option, three depths: collapsed, a greeting opened, settings opened.

A New Open Hours Slot screen with day chips and from and to times, a Ring Order sheet with sequential, simultaneous and round robin routing, and a Missed call text back sheet with a reply template. — Hours as time slots, not seven rows of days. Ring order and text-back as single-purpose sheets.

Component cards: a keypad selector for When, Route Call expanded and collapsed, Play Audio as text to speech, upload and recording, Voicemail Greeting, and More Settings. — Every block an option can contain, each with a collapsed and an expanded state.

Auto Attendant with a Lisa handles all missed calls banner and Lisa replacing voicemail on each option, and the Default Handling editor with Lisa handling the missed call plus custom instructions. — The same screens once Lisa is switched on: *No answer → Lisa.*

The complete case study · 15 minutes

From a feature people feared to one they grew into.

Six chapters: what was live, why people stopped, how the shape was found, eight versions, the system that shipped, and what it made possible.

Chapter 01

Where It Stood

A feature that wasn't failing, and wasn't reaching its potential.

Auto Attendant let a small business behave like a much larger organization. Calls could be routed, messages played, voicemails collected, and customers guided to the right person.

For some businesses it was the reason they chose LinkedPhone. Yet only a small share built anything beyond basic routing, and most configurations stayed as simple as the day they were made.

The feature was valuable. Sticky. Powerful.

It was also intimidating.

Where we were

One version was live, one was in progress. The one we needed didn't exist yet.

Customers used the live product every day: a basic setup screen, with a separate advanced one behind Call Menu Options. Alongside it, a redesign was in progress that mostly improved the visuals: cleaner cards, the same structure underneath. The version this case study is about still had to be found.

Audit board · The live product and the redesign in progress

Redrawn from the audit board. Left: the live product. Right: the redesign already underway, which cleaned up the surface but kept ten numbered slots, six of them Inactive, Not configured (outlined). The question wasn't how it looked. It was why people stopped.

The original flow

Adding one menu option took six screens.

Select a digit. Choose a function. Type a label. Pick who receives the calls. Set up a voicemail greeting and its recipients. Then return to a list that summarised the result as Type: Route Call, Enabled Users: 3. Each step was reasonable. Together they were a tunnel.

Six screens from the live app in order: Select Digit keypad, Choose Function list, Add Label field, Select Call Recipients, the Support Team voicemail greeting and recipients, and the updated Virtual Receptionist list. — Six screens, one option. The condition (open or closed hours) and earlier choices disappear as you go, so by the fourth screen you are configuring something you can no longer see.

Chapter 02

Why People Stopped

An audit of the screens, a look at the market, and what owners actually said.

Business owners wanted flexibility. They also wanted simplicity. Most products on the market solved one side.

Inbox dealt with communication; people consumed information. Auto Attendant dealt with system creation; people built something. For the first time we were designing a tool builder, for users who were busy, non-technical, mobile-first and configuring between actual work.

The true problem wasn't routing. It was understanding routing.

The audit

Six places the live setup lost people, on the screens themselves.

Audit · The live setup, annotated

Numbered where each problem happens. The findings below follow the same numbers.

The flow is described, not shown. A paragraph explains routing; nothing visualises it. Navigation
Advanced setup hides behind an optional row, then jumps to a new layout that contradicts what users just learned. Navigation
Tabs split the flow. Open, Close and Hours each hide the summary of the others. Navigation
Rows describe settings, not calls. Type: Route Call says nothing about what a caller hears. Option setup
Every option is built page by page, a tedious back and forth where the condition and earlier choices drop out of sight. Option setup
Hours are seven rows of days, set one at a time. Business hours

Not visible on any one screen: too many inputs shown at once; fixed inputs (digit, open vs closed) that limit customisation; route type and missed-call setup missing on mobile; no option without a keypad input; a greeting that had to be updated by hand after options changed, and broke the menu when forgotten; and no common pattern across option types, which hurt learnability.

Customer impact

Users became overwhelmed. Most configurations never progressed beyond basic setup.

Business impact

A key differentiator was underused. Customers got a fraction of the value available.

Internal impact

Every future feature would get harder if the architecture stayed hard to understand.

Investigation

The market's answer was a node builder.

We studied products like Dialpad, OpenPhone and Intercom. Where call routing was offered, it was usually a canvas of nodes, branches and connectors that exposes every relationship. So we built concepts that way.

They looked impressive. In reviews they felt powerful.

In testing they started breaking.

People spent more time understanding the interface than configuring their business. So we looked outside telecom, at products that make sophisticated systems approachable: Notion, Apple Home, Alexa and Google Home. Three things carried over: affordances that show what's possible, mental models people already hold, and configuration that scales with the business.

Research · Node-based call-flow builders

Published product screenshots from Quo, Twilio, Dialpad and Aircall. Every one is a canvas of nodes and connectors: built for an administrator at a desk, not for an owner on a phone.

Research

What we heard, once we stopped assuming.

Tags, field notes and quotes from owners, grouped once the same four patterns kept surfacing. The words routing, menu options and IVR always came from us first, never from them.

Research board · Four clusters

Cluster 01Outcomes, not systems.

outcome first, not architecture first

“I don't want to learn a phone system. I want my calls answered right.”

Every session, the words “routing,” “menu options” and “IVR” came from us first, never from them.

success = calls land correctly

“Just tell me it rings the right person. I don't care how it works underneath.”

Cluster 02Nobody starts advanced.

one rule and done

Most accounts never touched menu options.

“I just needed calls to go to me after hours. That's it, for now.”

simple by default

Advanced options felt like homework before the business even had a real need for them.

Cluster 03Confidence drives exploration.

success unlocks curiosity

“Once the basic setup worked, I went back in and explored the menu options later.”

Every advanced setup we saw started from an already-working basic one, never from scratch.

mastery before more

“I didn't want to break what was already working, so I only changed one thing at a time.”

Cluster 04Exposure is the enemy, not power.

same power, less upfront

Nobody rejected a capability once they found it. They rejected seeing it too early.

“I don't mind the advanced stuff being there. I just felt overwhelmed when I tried it the first time.”

hide, don't remove

“Show me the simple version first. If I need more, let me go find it.”

Four insights, each with an implication. Outcomes over systems: lead with what happens to the caller. Nobody starts advanced: progressive disclosure is essential. Confidence drives exploration: simple success should unlock complexity. Exposure is the enemy: change when power appears, not how much of it exists.

What the research changed

We thought users needed more configuration.

They needed more confidence.

Chapter 03

Finding the Shape

Two directions already on the table, and the structure that replaced both.

Two directions

Both directions on the table were half right.

The wizard was what we already had: the live product and the redesign in progress both walked you through setup a step at a time. Simple, guided, easy to start; rigid, hard to revisit, and it didn't scale. The node builder was what the market had: industry standard, powerful, flexible; intimidating, heavy to learn, and a phone screen amplified every bit of it.

Map · Where the two directions sat

One was simple and weak, the other powerful and hard. The corner that mattered was empty.

From the audit to a plan

Parallel over serial.

The audit board ended in a list of solutions. The first one set the direction for everything else: stop walking people through setup in sequence, and make every part of it reachable from one place.

Diagram · Serial setup against parallel setup

Redrawn from the audit board's sketch. Top, what the live product did; bottom, what the redesign would do.

Solutions

Parallel navigation over serial: one list with filters as the menu summary, and grouped inputs with progressive disclosure.
A modular brick structure for every option: trigger, condition, action.
Two-page navigation with accordion sections; a single-page setup for essentials vs advanced.
Business hours as time slots; a condition input on each option to keep context.

New opportunities

Autofill the menu message from option titles.
Preview the call menu.
A “no input” option.
Option metadata, and duplicate an option.
Waiting options for route call.

Pattern

Laid side by side, every option had the same shape.

On the exploration board, we broke each option type into its inputs. Route call, greeting, voicemail and repeat message looked different in the live app. Underneath, each had a trigger, a condition and actions, and only the actions changed.

Diagram · The option inputs pattern

Redrawn from the exploration board. Top: route call's first two passes, every input at one level. Bottom: the skeleton they became. Label, trigger and condition are identical for every option type, which is what made one editor possible; only the actions change, and route call's rarely used inputs fold into More settings.

The direction

One architecture. Complexity on demand.

Put together, the pattern and parallel setup gave us the third direction: progressive disclosure over one shared architecture. Basic and advanced setup stop being two systems. Users see only what they need now; everything else is one tap away, in the same place.

The interface started behaving like Lego: simple, composable, expandable, reusable blocks. One trigger and one action is a complete setup. Add a condition, then more options and fallbacks, then nested logic, with the same blocks each time. Depth is a choice the user makes, never a wall they hit.

Map · The third direction

Simple for beginners, powerful for experts: complexity scales with the user's confidence. It didn't disappear; it stopped arriving all at once.

Chapter 04

Eight Versions

The same two screens, the list and one option, redesigned eight times.

Knowing the structure didn't tell us what it should look like. Each version keeps the same two screens, so the changes are easy to compare.

Watch the header: Virtual Receptionist, then IVR Setup, then Auto Attendant. And the rows: from Route Call · 3 users active to Press 1 → Route call → 3 users.

From a menu index to a list that reads like the call.

V1Bricks V2Grouped V3Essentials V4One list V5Grammar V6Plain words V7Hierarchy V8Defaults

V1 · Bricks

V1: an Open Hours list headed by a call menu index with five numbered options, each with a one-line summary, and Closed Hours collapsed as Same options as Open Hours. The Route Call editor is a block listing three people with an Add More button beneath it.

V1Bricks

Open hours became one list of numbered options, each with a one-line summary. Closed hours collapsed to Same options as Open Hours. The Route Call editor was a block with Add More beneath it: the brick idea's first form.

What it taughtSummary rows worked. A menu index still hid the flow behind it.

V2 · Grouped

V2: Business Hours and Team Skills tiles above Open Hours and Closed Hours sections, each with an Add call menu link, a toggle for a separate closed-hours call flow and Draft Call Flows. The option editor uses accordions: waiting and queue, routing to, simultaneous routing and option conditions.

V2Grouped

Open and closed hours as sections, each with its own Add call menu, and a toggle for a separate closed-hours flow. The option editor turned into accordions: waiting and queue, routing, routing type, conditions.

What it taughtAccordions kept context. Conditions buried at the bottom didn't.

V3 · Essentials first

V3Essentials first

Home reduced to timings, call groups and options. Call menus became an opt-in, and the menu opened as a sheet with a play button to preview it, one of the audit's new opportunities.

What it taughtEssentials first felt calm, but advanced setup was a different place again.

V4 · One list, filtered

V4: a single list of menu message and options filtered by phone number, open hours and closed hours chips, each row showing its action and hours. The option editor has an Enabled toggle, a Condition block for Open Hours 9:00 to 21:00, and Routing To.

V4One list, filtered

Every option in a single list, filtered by number, open hours and closed hours. The condition moved into the option itself: Open Hours (9:00 to 21:00), with an enabled toggle.

What it taughtOne scan answered “what happens when someone calls”. Context stayed with the option.

V5 · The grammar shows

V5: IVR Setup, where each card reads as a chain such as Press 1, Route Call, 3 Users, During Open hours, including a No Input to Route Call card. The option editor is split into Starters, Conditions, Actions and Configuration.

V5The grammar shows

Every row became a sentence: Press 1 → Route Call → 3 Users, during Open hours. No Input appeared as a trigger. The editor split into Starters, Conditions, Actions and Configuration.

What it taughtTrigger, condition, action was learnable once visible. “Starters” was our word, not theirs.

V6 · Plain words

V6: the IVR Setup list with Welcome Message, Sales Team, Company Directory, Company Address and voicemail cards, each tagged with its hours. The editor reads When Keypad Press 1, During Business Open Hours, Route to two people, and More Settings collapsed.

V6Plain words

The same structure in the owner's language: When: Keypad Press 1. During: Business Open Hours. Route to. Route type, voicemail and missed-call options folded into one More Settings line.

What it taughtThe structure stayed the same; plain language made the rule easier to scan.

V7 · Hierarchy

V7: renamed Auto Attendant. Open hours and After hours are collapsible groups; the Welcome Message is the parent and the numbered options indent beneath it. The Edit Menu Option screen shows When Open Hours, Trigger Keypad Press 2, Route Call with Change, and a voicemail greeting.

V7Hierarchy

Renamed Auto Attendant. Open hours and after hours became collapsible groups, with the welcome message as the parent and options indented beneath it, so the list is shaped like the call.

What it taughtIndentation communicates a tree without a canvas.

V8 · Defaults

V8: a Business Hours card at the top, Open Hours as a rail of numbered nodes, and a Default Handling card described as the automatic flow when no menu exists or no option is selected, with Add at the end of each group. A New Menu Option screen carries Open Hours in its header.

V8Defaults

Hours moved to a card at the top. Default Handling arrived: the automatic flow when no menu exists or no option is selected. A new option now carries its context in its header.

What it taughtThe simplest setup is just the defaults. That is how basic and advanced became one system.

1 / 8

Chapter 05

The System

What V8 became: the live product, and the pieces it is built from.

The live product

Same system. Different depth.

V8's defaults closed the gap between basic and advanced. A business that only sets its hours already has a working setup: one default rule for business hours, one for after hours. A business with a five-option menu uses the same screen and the same blocks, and the default rule is still there underneath, catching every call nothing else matched.

Live product · Two businesses, one screen

Every label on the right points at a real row. The dashed line joins the one block both setups share: Default Handling.

Inside an option

Depth on demand, inside the same object.

An option opens with just when and what. The greeting expands in place to text to speech, a voice and a player. More Settings expands to ring order, missed-call text back and a no-answer menu, each marked when disabled so its absence is visible. Everything that used to be a separate screen became a sheet that does one thing and closes.

Design system impact

If the system could handle Auto Attendant, it could handle almost anything.

Auto Attendant became one of the strongest stress tests of the emerging design system, and fed a family of patterns back into it: list structures, progressive disclosure, cards, accordion behaviours, contextual actions and state management.

Component cards: a When keypad selector, Route Call expanded and collapsed, Play Audio as upload, text to speech and recording, Voicemail Greeting, and More Settings with ring order, missed call text back and no answer menu. — Each block has a collapsed state that summarises it in one line and an expanded state for editing. Audio alone comes three ways: upload, text to speech, or record.

Principle 01

Reveal complexity gradually.

Accordions expand in place, so the surrounding context stays visible and stable.

Principle 02

Maintain confidence at every step.

Every block has a readable collapsed state; you never lose your place.

Principle 03

Keep outcomes visible.

Rows state what happens to a caller, not which settings are on.

Principle 04

Encourage exploration, preserve power.

Motion did the explaining: levels transition in and out, and branches appear only as needed.

Chapter 06

What It Made Possible

An AI receptionist that didn't need a routing system of its own, and what the work changed.

Lisa

The next product moved into this one.

When LinkedPhone later built Lisa, its AI receptionist, she didn't need a routing system of her own. She became a destination inside this one.

Because every option already ended in an action and a fallback, Lisa only had to be a new action. No answer → Voicemail became No answer → Lisa on any option, and Default Handling, the rule that catches every unmatched call, could hand those calls to her too, with the owner's own instructions.

Four screens: the Auto Attendant list with a Lisa handles all missed calls banner and Lisa in place of voicemail on each option and in after-hours Default Handling; the Default Handling editor with a voicemail greeting; the same editor with Lisa handles this missed call and an empty custom instructions field; and the same with the instruction Collect preferred budget range of the customer. — Left: the list once Lisa takes missed calls, with *No answer → Lisa* on every option. Then Default Handling three ways: a voicemail greeting, Lisa in its place, and Lisa with the owner's instruction. The grammar didn't change; only the destination did.

In Lisa's own project the relationship later inverted: Lisa can answer every call first, and Auto Attendant becomes what happens when she's off. Owners choose: no calls, missed calls only, or all calls. Every existing Auto Attendant setup kept working.

The Lisa Answers sheet with three choices, each drawn as a small diagram: All Incoming Calls (caller, Lisa, your team), Missed Calls Only (caller, Auto Attendant, Lisa) and No Calls (caller, Auto Attendant). — Auto Attendant appears in two of the three pictures: the system this case study built is what Lisa falls back to. Read how Lisa was built.

Validation

Simple first. Advanced later.

Testing ran continuously: internal reviews, user testing, founder and customer feedback, even friends. The patterns kept pointing the same way.

Feature engagement increasedMore users came back to Auto Attendant after their first setup instead of abandoning it.

Configurations became richerRules built after the redesign used more conditions and branches.

Exploration became more commonPeople opened advanced options on their own, without being prompted.

Beyond the feature

The idea outgrew the feature.

Progressive disclosure escaped Auto Attendant and changed how LinkedPhone approached complexity: in the design system's blocks and accordions, in Desktop's information architecture, in the Unified Work Model, in 10DLC and the website, and in Lisa. Most of all, it changed how the company thought about powerful software. Four lessons came with it.

Lesson 01

Complexity isn't the enemy.

Hidden complexity isn't the solution either. The real challenge is revealing it at the right moment.

Lesson 02

People don't learn systems. They learn confidence.

Master the emotion and the mechanics follow.

Lesson 03

The most powerful feature isn't the most valuable.

The most understandable feature is.

Lesson 04

Progressive disclosure scales better than simplification.

You don't have to remove power to remove fear.

Closing

It started as a routing tool and became a philosophy. Power is easy. Clarity is hard. The goal was to make capability feel approachable.

Continue the storyLisa - AI ReceptionistThe AI receptionist that moved into Auto Attendant, then turned it inside out: six eras of interface search, a character system, and a trust ladder shipped as a routing rule. Read Lisa