2026
-
Suntory Beverage & Food Limited
One Suntory Walk
An admin console for running a company-wide walking event across global branches, built lean enough to sell.
Category
Admin Dashboard / Global UX
Role
Product Designer (UI/UX)
Overview
Defining a lean admin system, with engineering, before a spec existed
Suntory Plus runs a walking event that every branch of a global company takes part in, including overseas offices. I designed the admin system that lets each branch set up and run that event. The project began as a renewal of Suntory's internal tool, but partway through the goal expanded: build it so it could also be sold to other companies.
I joined before the spec existed. On a six-week timeline, I scoped a minimum viable feature set, deliberately cut the rich extras, and defined the spec hand in hand with engineering, weighing every decision against real implementation cost.
Contribution
Requirements & spec definition
MVP feature prioritization
Admin IA & flows
Spec defined with engineering
UI design
Team
2 PM
2 designers (me)
4 engineers
Timeline
6 weeks
Context
What the admin system has to do
The walking event is a company-wide health initiative: employees across every branch, including overseas offices, take part together over a set period. Someone has to set it up and keep it running, create the event, manage participants and communities, and track progress. That is the job of the admin system.
Because the company is global, the tool isn't used by one team in one place. It has to serve administrators across multiple branches and regions, with different languages, time zones, and levels of access.
Problem & Stakes
Define what to build, and ship it, at the same time
Two constraints made this hard at once.
Strategy & Decision
Scope was the design problem, so I designed the scope first
Because no spec existed, I started by sketching a rough wireframe of the ideal system, everything the tool could be, then used it as a map to decide what to keep and what to cut. Rather than building everything an administrator might one day want, I kept the minimum set the event genuinely needed and dropped the rest. A lean tool that shipped on time was worth far more than a complete one that didn't.
Wireframing with Engineering
Shaping the screens, and the spec, with engineering
The requirements weren't fixed yet, and with a tight timeline the spec had to be settled around what we could actually build in the time we had. So rather than finishing wireframes and handing them off, I brought engineering in while I was still wireframing. I shared the ideal-system wireframe, we worked through it feature by feature against implementation cost, and we firmed up the requirements together as the screens took shape.
Final Design
A focused console, built for one company and structured to extend to others
The admin system lets a branch administrator set up an event, manage participants and communities, and track progress and rankings through a small, deliberate set of screens. Designed for Suntory first, but structured so the same base can serve other companies as an external product.
Status & Outcome
Shipping a base that can grow into a product
The system is currently in development. Holding scope to a true MVP kept the six-week timeline realistic, and defining the spec against implementation cost gave the team a foundation that can extend toward an external offering rather than a one-off internal tool. Deferred features like the real-time world map are mapped for a later phase.
Reflection
Designing under ambiguity, and designing to feasibility
With no spec and a hard deadline, the highest-value work wasn't adding features. It was deciding what not to build, and defining the rest shoulder to shoulder with engineering, where every choice balanced user value against build cost.
Designing a tool meant for external sale also pushed me to separate one company's habits from what any company would actually need, an instinct that matters whenever an internal tool becomes a product.
