Simplifying a messy problem into a clear model
This project came with the brief already written. We had to move a dashboard with 15 sub dashboards onto a new platform, for mainly 3 types of users, in 4 months. It seemed very simple. We thought, okay, the brief is pretty clear. But then we started talking to the people who were actually going to use it on the ground, and we figured out that the brief didn’t even touch the real problem. This is the story of the weeks before a single screen got designed, and how they changed what we built.
- Client
- A global beverage company, supply chain team
- Product
- A benchmarking-to-value platform used by bottlers across ~2,000 plants
- Role
- Design Analyst, discovery and requirements
- Timeline
- Sept to Nov 2025
- Phase
- Research, requirement gathering, discovery
TL;DR
- Problem
- A 7-year-old programme was running on 5 apps, password-locked Excel files, SharePoint folders and a lot of emails. The brief already had a fix for it, but it was written before anyone had asked the users what was actually hurting.
- What was done
- We planned and ran discovery with the client’s tech lead and programme lead, kept track of what we had and hadn’t learned, used the gaps to set the agenda for the next call, and pulled 17 user types into one access model.
- Team
- PM, tech lead, data team
- Result
- 10 things in the brief changed before design started. The scope changed, the user model changed, and the client himself gave us a clear test for success.
The brief
Some context first.
Every year, bottlers (the companies that make and ship the drinks) share their supply chain numbers with the global team, like costs, volumes and efficiency. They then get compared against each other, anonymously. Bottlers who want to go deeper fill in a cost breakdown and a 400+ question best-practice survey, and they get an action plan at the end.
Nobody has to do any of this. It has been running for 7 years only because bottlers find it useful.
This is what it was all running on:
- An Excel template, shared over SharePoint
- A cost template, locked with a password that only a couple of people had
- 5 separate Power BI apps, which made up the 15 sub dashboards
- A survey app in 6 languages
- Someone at the end of it all, screenshotting reports into PowerPoint by hand
Even getting someone access meant two separate IDs and a ticket to IT.
So the brief made sense on paper. Put everything on one platform, convert the 15 sub dashboards, and design for 3 types of users: bottler, regional team and super user. It had to ship by January.
Our job was to run discovery and lock the requirements, which basically meant checking if that answer was actually right.
How discovery ran
We had two people to learn from. The tech lead knew how everything was wired, and the programme lead had built the templates and knew why every number existed.
Both of them were busy, so we couldn’t afford vague calls.
Every question had a follow-up
Next to each question, we wrote a follow-up for when the first answer came back too neat, because people usually answer the question you asked and not the one you meant.
Here are a few examples:
| What we asked first | What we asked if the answer was too neat |
|---|---|
| What would you automate? | What did you spend 2 hours on last week that should’ve taken 20 minutes? |
| How do you segment bottlers? | Give me an example of a high-priority bottler vs a low-priority one. What’s different about how you treat them? |
| How are action plans approved? | Has a bottler ever said no to a plan? What happened? |
| What can regional teams customise? | Tell me about a time you and a regional team disagreed. Who had the final say? |
We also marked some questions to skip. AI and predictions were too early. We only planned to ask about language if they pushed on it, because we weren’t sure it was a top-3 pain. It turned out to be one, and that comes up later.
- 01
Tracking what we didn’t know
After every call, we marked each question as fully covered, partly covered or not covered. The partly covered ones were the most interesting. For example, we knew how many bottlers submit data, but nobody could tell us the completion rate.
- 02
Gaps became the next agenda
The first call left us with 11 gaps, and those 11 gaps became the agenda for the call with the programme lead. Whatever he couldn’t answer went to the next session with a name next to it. So every open question either got answered or got an owner, and nothing just got lost.
What we heard
We found a lot of things, but these are the four that actually changed what we built.
- 01
The plan doesn’t belong to the regional team. It belongs to the bottler.
The brief said regional teams create action plans and bottlers view them. That sounded reasonable, but it’s not how it works at all.
The whole thing is voluntary, so bottlers decide what they want to fix, and they build the plan themselves with some help. Nobody hands them a to-do list.
So what changed
The action planning space became the bottler’s workspace instead of a report they receive. That one change decided who the main user was for half the product.
- 02
“As easy as Excel, or they’ll go back to 100 systems.”
You would expect people to want to get rid of Excel, but they didn’t.
A single bottler can have 15 to 20 people filling in data. They split the Excel file, work offline, stitch it back together and upload it. And it works. The programme lead said getting bottlers to fill data was “zero problem.”
Then he said the line that stayed with us for the whole project. If it’s not easy, bottlers will go back to their own systems, which means 100 systems at the end of the day.
So the web form was competing with Excel, and he was very specific about what that meant: copy and paste, and seeing lots of fields at once. If you can only see 5 values on screen, people will just fill Excel and type it all over again.
So what changed
Excel stayed, and the web form became an option instead of a replacement. And when two people edit the same form, their answers merge so that one doesn’t wipe out the other.
- 03
Success meant fewer “how do I use this” questions
We asked what success would look like six months after launch, and we expected an answer about revenue numbers or adoption rates.
He said fewer complaints, faster responses and less support. People should be asking about the content, not about how to use the tool.
That gave us a very clear test, and every design decision after this had to pass it. We also found out that a separate company was building training material at the same time, and they needed our screens while we were still designing.
So what changed
Help went into every step instead of one training session at the start, and screenshots went to the training team during design instead of after launch.
- 04
“Analytics” was actually two products
Everyone kept saying “analytics” like it was one thing, but it wasn’t.
A bottler wants to see their results from their workshop. The global team wants to see the whole programme across ~2,000 plants, like whether bottlers are actually saving money, or which survey questions everyone answers “yes” to. If 50 questions are always yes, they can be removed. If 90 are always no, that’s a global problem and not a bottler problem.
So it was the same data, but for completely different jobs.
So what changed
We split it into process analytics for bottlers and a programme view for the global team, which we called Mission Control. Mission Control went from a nice-to-have to the top priority.
From 17 user types to one grid
The brief had 3 types of users. When we mapped everyone who actually touches this thing, we got 17, including plant managers, regional heads, admins on both sides, content approvers, translators and the tech team.
You can’t really design for 17 personas, because it just turns into a spreadsheet nobody reads.
So instead of asking who someone is, we started asking two questions: what can you do, and how far can you see? That gave us 6 capabilities and 5 levels, and all 17 types fit somewhere on this grid.
| Capability | Plant1+ plants | Bottler regiona region | Bottler1 whole bottler | Regional teammany bottlers | Global~2,000 plants |
|---|---|---|---|---|---|
| Data operatorSubmit data, see results | Plant teams | Regional heads | Bottler centralBottler admins | OU users (TBD)OU admins | Global adminGlobal viewers |
| Access managerAdd users, assign plants | Bottler admins | OU admins | Global admin | ||
| Content managerEdit forms and rules | Global adminContent team | ||||
| Deployment managerCoordinate rollouts | Bottler headview only | OU usersview only | Global adminDeploy leads | ||
| Programme monitorMission Control | Global adminGlobal viewers | ||||
| System maintainerBackend and code | Tech team only |
OU = the regional operating team. What OU users can do in data entry was still unconfirmed when discovery ended.
Once it was on the grid, the pattern was easy to see. Entering data happens at every level, but changing the rules only happens at the top, which is exactly the control the programme lead wanted. It also meant we had to design 5 flows (the 6th is backend only) and not 17 versions of the same screen.
What the brief assumed vs what we found
This is the most important part of the project. Here are the 10 things the brief assumed, next to what people actually told us.
| The brief said | What we found |
|---|---|
| Regional teams create action plans | Bottlers own their plans, because the whole thing is voluntary |
| 3 types of users | 17 types, which we pulled into 6 capabilities across 5 levels |
| Super users will need Python to configure things | The programme lead wanted to change things through the interface, and code stays with the tech team |
| Convert all 15 sub dashboards | Some reports nobody opens, so rebuild based on what’s actually used instead of copying the old ones |
| Languages are an add-on | Languages were core. The real pain was waiting 2 to 4 weeks for every translation before anything could be published |
| Regional teams send reminders | The global team sends reminders by hand, based on relationships, and regional teams don’t even have admin access |
| “Monitor usage” | Mission Control became the top priority |
| There’s no system for cost mapping | There was one. It was Excel on SharePoint, just not connected to anything |
| (Excel wasn’t mentioned) | Excel stays, and that was non-negotiable |
| A chatbot as an add-on | It moved out of the first version, and when it does come, it has to say “I don’t know, ask X” instead of guessing |
This doesn’t mean the brief was bad. It was written before anyone had spoken to users, and that’s what discovery is for.
Then we checked it against the platform
So now we knew what users needed, and the next question was whether the platform could actually do it.
We went through every requirement with the platform team and colour-coded each one: already available, not available, needs more clarity, or needs the platform team to confirm.
Some of the answers were hard to hear:
- No auto-translation on the platform, and we had just learned that languages were core.
- Region-based data access wasn’t built in, which is a big deal when bottlers must never see each other’s data.
- The platform ships as a locked image, so “admins with coding skills can extend it” wasn’t really true.
So we had to be honest about what could go in the first version. A deployment-tracking tool, a community forum and the chatbot all moved out. Exporting to PowerPoint moved out too, which hurt, because of the person screenshotting reports into slides. Action plans export to Excel, PDF and image instead.
There were also some things we protected no matter what. Bottlers only ever see their own data. Question IDs stay the same when only the wording changes, so you can still ask “has this plant improved over 3 years?” And data is kept forever, because, quote, “data is not a cost factor.”
A big part of requirements is saying no to things and being able to explain why.
Being honest about it
What this role was part of
- The question bank and the follow-ups
- Running the discovery calls
- The coverage tracker and the gap analysis
- Turning findings into features, design decisions and success criteria
- The 6 x 5 access model
What this role didn’t own
- The brief, the scope and the commercials
- The platform feasibility calls, which sat with the platform and tech team
- The templates and the maths behind the benchmarks, which are all the programme lead’s work and genuinely impressive
What was still open when discovery ended
We didn’t have everything figured out, so here’s what was still open.
- Mission Control needed its own session. We knew what it was for, but not exactly what went in it.
- The plan-on-a-page had no designs yet. The programme lead said, fairly, “I have not seen anything so I can’t comment.”
- We still hadn’t confirmed how much regional teams can see in the cost and survey modules.
- We never got a real answer on what happens when a bottler says no to a plan.
What would change next time
Push to talk to a bottler directly, and not just the global team. Every insight about bottlers here came secondhand. The “as easy as Excel” line was right, but it would’ve been great to watch 15 people actually stitch that Excel file together.
And count things earlier. The tracker covered what we had learned, but not how many requirements actually changed because of it, and that number would’ve made this story easier to tell.