Design how users interact with an AI scheduling assistant

[INTERVIEWER] Design how users interact with an AI scheduling assistant. This one's a trap if you treat it as a modelling problem, because it isn't. It's about interaction design and trust. Here's the insight that carries the whole answer. An assistant that automatically books meetings loses trust the very first time it gets one wrong. One bad booking in front of an important client, and the user turns the whole thing off forever.

So you design it to propose, not to act unilaterally, and you make correcting it a single tap away. Reversibility is the product. Let me show you why. Microsoft is testing whether you understand that with agentic features, trust is the actual product. Trust is fragile in a specific way, as it's slow to build and instant to lose. They want to see if you can design the unhappy path, the conflicts, the no shows, and the wrong bookings, rather than just the glossy demo where everything works.

By the end of this, you'll have a set of interaction principles you can apply to any assistant that acts on behalf of a user, whether for scheduling, email, expenses, or anything else. We will use the CIRCLES framework to structure the product sense half, starting with step one, clarifying scope. Scheduling isn't just one problem, so ask what kind.

Are we talking about internal one on ones, external meetings across companies, or recurring team syncs? Each has different constraints. External is the hard one. You've got no visibility into the calendar of the other side, so you're negotiating over email, not just reading free and busy times. Then ask what signals the system has. Does it have calendar access, email, timezone data, and stated preferences?

Assume it can read the calendar and email of the user, and act on their behalf with permission. Confirm the real job in the words of the user. Find a time that works for these people and get it on the calendar without ten messages going back and forth. That last phrase, without the messages going back and forth, is the value.

Hold onto it. Step two of CIRCLES is understanding the user and the goal. The user is a busy person who bleeds time and mental energy into scheduling logistics. The goal is fewer messages and less mental load to reach a booked meeting. The crucial qualifier is doing this without the assistant creating errors the user then has to clean up.

An assistant that saves you three messages but books one wrong meeting a week is a net negative. Your North Star metric is meetings booked with zero human messages going back and forth, measured as a share of scheduling requests. Your guardrail is the correction rate, which tracks how often the user has to fix or cancel what the assistant did.

A high correction rate means the automation is costing trust rather than saving time. That's the number that tells you whether you're actually helping. Now we reach the heart of the answer, which is the interaction design half. You must design the behaviour, not just the user interface. The first principle is to propose rather than automatically book. The assistant suggests two or three concrete slots and waits for a single tap to confirm anything that involves other people or leaves the control of the user.

Silent automatic booking is reserved for the lowest stakes and highest confidence case, like a solo focus block the user explicitly asked for. Second is confidence graded autonomy. For high confidence and low stakes, it acts and notifies. For lower confidence or higher stakes, like an external executive or a hard to move recurring meeting, it proposes and asks. The autonomy the assistant takes should scale with two things, namely how sure it is and how reversible the action is.

Third is a single tap undo on everything. Every single action has a visible and immediate undo option. Reversibility is what lets people trust automation, because if the cost of a mistake is one tap, the mistake stops being scary. Fourth is showing its reasoning briefly. It might say it's suggesting Thursday at 2pm because it's the only slot free for all four people and it respects the rule about no meetings before 10am.

That one line lets the user catch a bad assumption before it becomes a booking. Fifth is learning preferences but confirming before applying them. If it notices the user always declines Friday afternoons, it proposes making that a standing rule, rather than silently enforcing it and being creepy about it. Next, you must design the unhappy path, because that's where trust is actually won or lost.

This is also the part most candidates skip entirely. In case one, no slot works for everyone. The assistant proposes the least bad option and names the conflict honestly, or offers to ask one person to move. It doesn't pretend a perfect slot exists. In case two, the external other party doesn't respond. It follows up on a schedule and tells the user it's still waiting on Priya, rather than going silent and leaving the user wondering.

In case three, it books the wrong thing. The undo function restores the prior state, and then the assistant asks what it got wrong, turning that error into a preference signal for next time. Every failure becomes learning. That's the design. Let me expand on confidence graded autonomy. Scaling autonomy to confidence and stakes is a nice phrase, but an interviewer wants to see you actually operationalise it.

Picture a simple two by two matrix. On one axis, consider how confident the assistant is. Does it have a clear best slot or a messy tie? On the other axis, consider how reversible the action is, such as a solo focus block versus a locked in meeting with an external CEO. In the bottom left, you have high confidence and fully reversible.

The assistant just acts and notifies, saying it booked the focus block for 3pm and the user can tap to undo. In the top right, you have low confidence and hard to reverse. It never acts alone. It proposes options and waits, and it might even say it isn't sure this works for everyone and ask if it should request Sam to move.

The two off diagonal cases get the middle treatment. It acts but makes the undo loud, or it proposes but pre fills the answer so confirming is a single tap. The point is that autonomy isn't a single global setting the user flips on. It's computed per action from those two dimensions every time. That's the difference between an assistant that feels considerate and one that feels reckless.

It's the level of specificity that wins this question. Step five of the framework covers metrics and feedback. The North Star is, as we said, zero message bookings as a share of requests. The guardrails are the correction and undo rate, along with the time it takes to get booked. Here's a nice addition, which is a trust metric. This tracks the share of proposals the user accepts without editing, measured over time.

If that accept rate is rising week over week, it means the assistant is genuinely learning this specific user. That trend is the clearest signal that the product is working. Every undo and every manual override feeds the preference model, so the system gets more right the longer you use it. Let me make it concrete with a worked example.

The user types a request to find thirty minutes with Priya and Sam this week. The assistant reads all three calendars, applies the known rule of the user about no meetings before 10am, and replies with two slots. It offers Thursday at 2pm or Friday at 11am, noting both are free for everyone and Thursday respects the no early meetings rule.

The user taps Thursday. The assistant books it, sends the invites, and shows an undo chip for ten seconds. If the user later drags the meeting to a different time, that move quietly becomes a preference signal. Your target is sixty percent of requests booked with zero follow up messages, and an undo rate under five percent. When the interviewer pushes back, they'll ask about the external case where you can't see the other calendar.

You're ready for this. The assistant drafts a proposal email offering three of the free slots of the user, tracks the reply, parses the chosen time, and books it. It still surfaces the final booking to the user for a single tap to confirm before it locks. These are the same principles of proposing and confirming, applied to a channel where you're blind to the other side.

Here's what makes the hiring manager lean in. First is proposing rather than automatically booking, paired with confidence graded autonomy. This means taking more control only when the assistant is sure and the action is reversible. That framework shows you understand agentic trust deeply. Second is that you designed the failure and recovery flows, not just the happy path. The unhappy path is where real products live and die.

Third is that you framed undo and brief reasoning as the trust mechanisms. These are the specific things that make automation acceptable to a nervous human. You didn't just say to make it trustworthy, you explained exactly how. Now let's cover the traps. The first trap is full automation with no confirmation. It looks impressive in a demo, but it fails the first time it's wrong, and it never recovers the trust of the user after that.

The second trap is designing only the happy path while ignoring no response situations, conflicts, and wrong booking recovery. That's exactly where a scheduling assistant actually gets tested. The third trap is having no preference learning at all. The assistant makes the same annoying mistake every single week, like booking the 9am slot the user always declines, and the user just gives up on it.

Let's assemble the whole thing for the recap. You clarify the scheduling type, especially internal versus external. You set a North Star of zero message bookings with the correction rate as the guardrail. You design five interaction principles, which are proposing rather than booking, graded autonomy, single tap undo, brief reasoning, and confirmed preference learning. You design the failure paths for conflict, no response, and wrong booking.

You measure a rising accept rate as your trust signal. Carry this final thought into the room. A scheduling assistant earns trust by proposing rather than automatically booking, scaling its autonomy to confidence and reversibility, and making every action a single tap to undo.