Designing pricing clarity for franchise operators
Role
UX/UI Designer & Front-End Prototyper (independent)
Date
2024 — upcoming launch
Client
Pizza Hut franchisees via Converge for Restaurants
Platform
Deloitte Converge · Franchisee Portal
Sector
Restaurant / Enterprise
Challenge
How do you give franchise operators visibility into complex pricing recommendations without overwhelming them — or undermining their autonomy?
Background
The Crust Upcharge Configurator is a pricing configuration tool within the Pizza Hut franchisee portal in Converge, Deloitte's pricing optimization platform.
A Pizza Hut pizza price isn't a single number. It's the result of a combination between variety (Cheese, Supreme, Meat Lovers, Veggie Lovers) and crust type (Hand & Tossed, Thin & Crispy, Tavern, Pan, Stuffed Crust). On top of that, some crust types carry an upcharge over the base price, and that upcharge can vary by size and by each franchisee's local market conditions.
Deloitte's price advisors generated recommendations for these combinations, but franchisees had no real visibility into how those numbers were built or tools to adjust them with any confidence. The result was an opaque process that eroded operator trust in the recommendations and limited their ability to make informed pricing decisions.
Process
Before designing anything, I spent time understanding how pizza pricing is configured across other franchise brands — existing UI patterns, industry conventions, and operator mental models.
The most important finding wasn't about interface. It was about the business: medium and large are not just different sizes, they are different product contexts. A large pizza's greater surface area enables ingredient combinations that don't exist on medium, which means different pricing conditions apply. Understanding this before designing determined a fundamental architectural decision: the first choice in the flow had to be size — not variety, not crust — because size defines the entire space of possibilities that follows.
From research to architecture
With the research findings in hand, I used Claude to build a first version of the concept as a conversation artifact for an early review with the PM and the price advisor assigned to Pizza Hut.
That session produced the most structurally significant change in the project: dropping the idea of solving everything on a single screen. The information density — sizes, varieties, crusts, upcharges, recommendations, manual adjustments — made a single view unworkable without sacrificing clarity. A fully integrated table was logically correct, but it didn't match how the operator actually processes those decisions.
Breaking it into a four-step wizard wasn't simplification — it was respecting the order in which the user thinks.
Full prototyping
With the architecture defined, I used Figma Make to build the complete interactive prototype — every state combination, every interaction, every edge case. The goal was to arrive at user validation with something that behaved like the real product, not static screens.
Validation with a franchisee
Validation took the form of a demo with open conversation with one of the franchisees. The element that worked better than expected was the comparison matrix in the final step: a view that crosses each pizza variety against each crust type, shows the user's adjusted price against the original recommendation, and includes a toggle to return to the recommendation at any time.
For the franchisee, it solved something that previously required multiple files and manual comparisons. Seeing the intersection of pizza adjustments and crust adjustments — all visible at a glance — fundamentally simplified how they understand the impact of each pricing decision.
The session also confirmed something about the feature's audience. The franchisee said it directly: this configurator is not a primary screen — it's an advanced settings entry point. Not every operator will use it. But those who do are the ones most invested in the detail of their business, and for them, the level of control the wizard provides is exactly what they need.
Key design decisions
Each of these decisions had a discarded alternative. The reasoning behind each choice was as important as the choice itself.
Size as the first step. Not variety, not crust — size, because medium and large are different product contexts. Size defines the entire space of possibilities that follows.
A four-step wizard over a single view. Information density on one screen broke clarity. The wizard wasn't a simplification — it respected the order in which the operator actually thinks.
Comparison matrix at the final step. Surfacing the comparison earlier could have anchored users to corporate recommendations and suppressed legitimate local pricing decisions.
Toggle to return to recommendation. Lower friction than a reset button with confirmation. Users can compare without fear of losing their reference point.
Deviation badges as information, not errors. Deviations from the recommendation are valid decisions. Framing them as errors from the start would undermine operator autonomy.
Feature positioned as advanced settings. Not all franchisees need this level of granularity. Designing for the power user without imposing it on everyone was a deliberate choice.
Results and lessons learned
The feature is approaching launch. Validation with the franchisee confirmed that the comparison matrix — the highest-risk design element — generated the most perceived value.
Beyond Pizza Hut, price advisors from other franchise brands who saw the feature in an internal demo have already expressed interest in a similar solution. This suggests the problem it solves — giving operators granularity and visibility without compromising the integrity of the recommendations — is category-wide, not specific to this client.
- Research the business before designing the interface. Understanding that medium and large are different product contexts, not just sizes, determined the flow structure from the outset. That wouldn't have come from reviewing UI patterns.
- Design for the user's mental model, not the system's logic. The integrated table was correct from a data logic standpoint. It wasn't correct from a user logic standpoint. The wizard was an empathy decision.
- Knowing who you're not designing for matters. Recognizing that this feature is for power users, and designing accordingly — without trying to make it work for everyone — was what made it possible to give that user the level of control they actually need.
- Respecting user autonomy is a product decision. Showing the comparison at the end — not during editing — is a deliberate stance: franchisees have the right to make local pricing decisions without the system framing them as errors from the start.