A story about the layer underneath

The UI was fine. The structure underneath it wasn't.

I was assigned one feature. What I found was a content structure with no limits on it — six people could build questions however they liked, nest them as deep as they wanted, and nobody had ever set a rule. On a phone, at the counter, it fell apart.

Client
Chick-fil-A
Role
Senior UX Designer, contract
Team
Self-directed, alongside the CMS roadmap
Focus
Content structure · Mobile · Design systems
Tools
Figma · Claude, with a rebuilt style guide
Status
Proposed
Scene 01

Assigned one thing

This didn't start as a redesign. I was working a single feature in the CMS.

Ops Hub CMS is where a small group of Chick-fil-A admins author the food safety assessments that every restaurant fills out. It feeds Daily and Assess, which feed Report, which feed the operator's score. Everything downstream depends on what gets authored here.

The deeper I got into the feature, the more I found sitting underneath it that hadn't been examined in years.

Which user is taking which assessment, on what device?
Scene 02

Nobody could answer it

I asked a question I assumed had an answer, and it didn't.

The response I kept getting was “could be anything — phone, tablet, desktop.” Which is another way of saying we had never defined it.

That's not trivia. It sets the ceiling on everything: how much text a question can hold, how many levels of structure are usable, whether a table is even an option. Without it, every authoring decision is a guess that someone else has to live with.

Scene 03

So I went and found out

There was no budget for a study, so the method was asking around. I talked to ops leads, a few product owners who sat closer to the operators than I did, and some people at headquarters who'd worked in a restaurant themselves and knew when these actually get filled out.

Mostly mobile and tablet. Team members take these on the floor — at the counter, in the back room, on a break. In practice, it's a phone.

Worth being clear: I never spoke to an operator or a team member directly. This is secondhand, and I'd tell you that before you asked. It was enough to change what I was designing for, and it was more than we had the day before — but it's the first thing I'd want to replace with something real.

Where assessments actually get taken — mobile views of Daily and Assess

Scene 04

The schema was the problem

The authoring model had no constraints, and the interface was paying for it.

Six admins can build whatever they want. A question can hold sub-questions, those can hold their own, and there's no defined limit — I found structures four levels deep. Nothing in the model says how deep is too deep, because nothing in the model says anything at all.

In the current UI those levels render as accordions inside accordions. Two or three tiers down, on a phone held one-handed at a counter, the person answering has lost the thread of what they're even being asked.

So this looks like an interface problem and isn't. You can redesign the accordion all day. The shape of the data is what decides whether the screen can work.

Four levels of nesting, rendered on a phone

Scene 05

What it costs, and who pays for it

I wanted to make this case in terms the roadmap could act on, not just design terms.

Every badly shaped question is answered thousands of times across the network. A team member misreads it, answers the wrong thing, and the finding that reaches the operator is wrong. They appeal it. An admin reviews the appeal. Someone edits the question. That's real cost, spread thin enough that nobody had added it up.

And there's a tradeoff I'd want named honestly rather than buried.

Constraining the schema means the six people who author these lose freedom they've had for years. Depth limits, validation on question length, rules about when a sub-question is allowed. That's a real loss for them, and they're the ones who'd have to live with it daily.

My argument is that the freedom is currently being paid for by team members on the floor, who never agreed to it and can't see where the cost is coming from. But I'd rather put that trade in front of the admins than decide it for them.

Scene 06

Building the toolchain I needed

I couldn't get access to the design system, so I rebuilt it somewhere I could use it.

Chick-fil-A wasn't going to hand a contractor the token file. Reasonable, and it left me working against a system I couldn't reference directly.

So I reconstructed the style guide as working context for Claude — tokens, component rules, spacing, the patterns I'd already had approved on the 2030 project. Once that existed, I could generate and iterate on structural concepts that came out on-system instead of needing to be corrected back onto it afterward.

That's most of how this project got done. Not AI as a shortcut past the thinking, but as a way to hold the system in place while I worked through the harder question underneath it.

The style guide, rebuilt as working context

Scene 07

What I designed against it

A constrained schema only helps if the authoring tool makes the constraint feel obvious rather than punitive.

So the wireframes worked two problems at once: giving admins a builder that shows them what they're making, and capping the structure at a depth that survives a phone.

Live preview beside the question. A visible depth indicator, so nesting has a cost you can see while you're doing it. Question types that carry their own limits rather than relying on a house style nobody wrote down.

Wireframe — builder with live preview
Wireframe — depth limits made visible
Wireframe — question type constraints
Wireframe — mobile render check

Final mockups — the authoring experience, on system

Final mockups — the same assessment on a phone, before and after

Scene 08

Why I kept pulling

These assessments are what the whole product runs on. If they're answered badly, every report downstream is wrong, and the operator is appealing a score that was never accurate to begin with.

A team member is doing this on their lunch break. That experience deserved more care than it was getting — and so did the admin building it. Both ends were bad, and they were the same problem seen from two directions.

Where it stands

Nobody asked for any of this, which is the point and also the problem.

The proposal exists. The finding is real and the argument holds. It has not yet turned into a decision, and I don't control whether it does.

What I'd want next is small and specific: sit with two or three admins, show them the four-level question on a phone, and find out whether they'd trade some authoring freedom for it. Half a day of work, and it would settle the argument better than I can from the outside.

That's the version of this I'd rather be showing you. It's also the version I'd start on Monday.