Staff product Designer
1 PM, 1 Researcher,
4 Engineers
0→1 Project (3 months)
Retail, Fulfillment, and Reporting teams
Restaurant economics are structurally broken. Food costs have risen nearly 29% over the last five years and the average restaurant runs on a 3–9% total profit margin. A single bad purchasing decision can flip a week from profitable to not. 2025 tariffs made a bad situation materially worse, forcing restaurants to raise prices, reduce staff, or close altogether.
Square's strategy is to use AI to help restaurants survive and thrive driving more GPV and attracting net-new sellers upmarket. The goal for the company was economic empowerment, and I was leading key initiatives to help Square move upmarket. My role was to lead design on one of those initiatives: a price comparison tool that helps restaurant owners buy smarter.
I conducted seller visits with the team across California to define our ICP and understand the nuances between procurement needs. While I was doing an empathy-building exercise, our researcher was conducting diary studies and surveys to capture a broader scope of the problem.
Most processes were entirely manual. Sellers communicated with sales reps via email or text. Invoices were processed monthly, running a restaurant requires managing a series of IOUs and credits between vendor and restaurant with no single source of truth. Owners were spending unnecessary hours normalizing unit cost across vendors just to figure out the cost of ingredients. That's doing unnecessary math instead of running a restaurant.
After talking to 10 sellers through interviews, diary studies, and surveys, we validated the problem and identified key opportunity areas. The biggest takeaway: there is a quality scale, sellers will try cheaper products, but only when quality isn't compromised.
After all our research that we conducted, we narrowed down on our ICP: QSRs and Cafes w/ 1–5 locations that needed price comparison tooling. Over five, we were seeing they needed more advanced tooling for order frequency.
For example, if you're a bakery selling vanilla cupcakes the flour is most important for texture, you'll pay any price. But the vanilla extract and sprinkles are supplementary and you're looking for cost savings there. Owners think in ingredient tiers, not categories. That insight shaped the entire product direction.
I made a journey map to guide discussion with my PM and leadership as to what we could potentially be tackling. I outlined opportunity areas along with pain points that owners told us. Walking through a concrete tomato-purchasing example made the problem tangible, abstract research doesn't move stakeholders, but a specific item at a specific price does.
We wanted to start with a price comparison tool, lowest-hanging fruit with the highest immediate impact. The long-term strategy was inventory tracking and insights, then purchase order fulfillment, and eventually driving down cost by doing group ordering on behalf of restaurant networks in a neighborhood as the longer term strategy.
Our strategy was presented to execs and core leadership, and we got bought in to proceed with the Food and Beverage vertical team.
I went through existing Square patterns to see what I could leverage not to reinvent, but to identify where we'd need net-new components vs. where we could ship faster with existing system primitives. I also used AI as a tool for discovery: it helped me rapidly iterate on directions and stress-test concepts I hadn't fully thought through.
I built a custom GPT trained on our research reports to simulate an “owner” persona, allowing me to quickly gut-check design directions and maintain momentum. Beyond the research inputs, I incorporated key workflows we had identified so the model could make more informed, consistent decisions. This approach significantly accelerated early-stage exploration without introducing additional research overhead for each decision.
Feedback results for designs:
The value prop preview was too buried, we needed to surface potential savings sooner. Sellers also wanted to see product images to understand what they were actually available to purchase. Both became P0 fixes before engineering handoff.
After getting feedback that the value prop was buried, I opened the first item in the table so sellers could immediately see what live data would look like, with a prompt to connect their first vendor. I wanted to pre-fill vendor data to reduce friction, but pricing is negotiated seller to seller, so pre-populating it would have surfaced inaccurate information. The empty state became an entry point where sellers could immediately see the value, have most of their ingredients pre-populated, and quickly attach a vendor to start comparing prices.
Vendor management centered on surfacing the right information at the right time. I removed contact details from the main view and replaced them with last pricing update status, what sellers actually needed to see at a glance. Details and locations were managed within the blade UI to keep the surface clean. To eliminate manual data entry entirely, I leveraged Retail's OCR feature to capture physical price sheets and pull pricing data automatically.
The order guide was built around what sellers told us mattered most, organized by priority: brand name, vendor and order minimum, delivery window, sold by price, and unit price. Sellers could configure the table using filter options for location, vendor, and item type, giving them a single view to compare costs across vendors without the manual legwork. After validating ideas with AI prototypes, we added drag-and-drop functionality so sellers could move items into different lists to compare them across groups.
Looking back, I would have invested more time in the multiple list use case, customizable ordering lists would have meaningfully streamlined the reordering experience for sellers. On the AI side, I would have used agents instead of custom GPTs so vendor pricing data refreshes automatically rather than requiring manual updates. And for prototyping, I would have used Cursor and Figma MCP to build out the webpage from the start, which would have compressed the design-to-handoff loop significantly.
Learn more