From Pages to Possibilities
A user design case study on the website Project Gutenberg
Designing trust into AI-powered ordering
Images and UI/UX artifacts are protected by non-disclosure agreements; conversations regarding these systems are always welcome .Conceptual imagery within this portfolio includes AI-generated assets.*
Overview
At Square, I design seller-facing and conversational commerce experiences — a lot of it centered on how AI interacts with menus, pricing, availability, orders, and the moments when things go wrong. This case study looks at one specific problem: what happens when a customer says something an AI ordering system doesn't fully understand?
The Challenge
Most interfaces are predictable. A user clicks a button, and we know what happens next. Conversational AI breaks that assumption completely — a customer can ask for almost anything, in almost any way.
Take a real example: "Give me a chicken sandwich, make it spicy, remove dairy, and I'll pick it up around 7."
In one sentence, the system has to resolve the item, the modifiers, a dietary restriction, availability, location, pickup timing, and any resulting price change — all at once, and all correctly. There's no single point of failure to design around. There are dozens.
The real design question wasn't "how do we make the AI smarter." It was: what do we do the moment it isn't smart enough?
My Role
I worked with product, engineering, and ML teams to understand where the model's confidence actually broke down — not just where it succeeded. From there, I designed the interface layer that sits on top of that uncertainty: confirmation, clarification, fallback, and recovery states.
Designing for Three Levels of Confidence
Rather than treating every AI response as either "right" or "an error," I designed around three distinct states:
Full understanding — the system proceeds and confirms clearly, so the customer always knows what was heard and what's about to happen.
Partial understanding — the system asks, rather than guesses. If a customer's request could match two menu items, the interface doesn't silently pick one. It asks: "Did you mean the grilled chicken sandwich or the crispy chicken sandwich?"
Low or no confidence — instead of a dead end, the customer gets a path forward: rephrase, choose from valid alternatives, or move to a human.
Underneath all three, I used the same simple framework: what happened, what does the user need to know, and what can they do next. Technical detail — model confidence scores, API failures, internal error codes — never reaches the customer. It doesn't help them, and it decreases their trust in the product.
Working Within the System, Not Around It
Before designing anything new, I checked whether an existing pattern already solved the problem using Square's Figma component library, Variables, design tokens, and Storybook. Confirmation states, warnings, loading states, and inputs almost always already existed in some form. When a use case genuinely didn't fit, I extended the pattern deliberately and documented why, rather than creating a one-off. Five designers solving the same problem five different ways eventually costs the product its consistency and costs engineering the maintenance.
What I'm Proud Of
It's tempting, on any AI project, to spend most of your energy making the assistant feel smart. I spent more time on the opposite question: what does it feel like when it isn't? Designing the recovery path — clarifying, offering real alternatives, or handing off to a person — mattered more to the overall experience than any of the "happy path" screens. A good AI product isn't defined by how often it's right. It's defined by how gracefully it handles being wrong.
