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.
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?
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.
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 — on the floor, one-handed, mid-shift
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.
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.
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.
What building a question actually looks like
Four thousand two hundred and twenty-five questions live in here. A hundred and forty-four questionnaires assembled out of them.
And the tool for making them is a form. Program, internal ID, risk level, question type, effective start date, effective start time. Fill in the fields, hit submit, hope.
There is a preview panel, and it does show you the question you are writing. What it cannot show you is the question in context: where it sits in the assessment, what it nests under, how deep it has just gone, or what any of that looks like on the phone it will be answered on.
Nothing here says you are building an experience. It reads like data entry, so that is what people do.
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.
Questions, with the structure made visible — filters, status, versions, all on one row
coming soon
coming soon
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.