

Getting 50 managers off Excel.
BMW Group Johannesburg · 2023/4
BMW built an internal data management tool for regional managers. Nobody was using it. I was the only designer on an engineering team, ran user interviews before touching a screen, and redesigned the tool from the ground up. A 4-minute task now takes 30 seconds.
My Role
Solo UI/UX Designer
Timeline
August 2023 - December 2023
Shipped
80% despite pushback
Getting 50 managers off Excel.
BMW Group Johannesburg · 2023/4
BMW built an internal data management tool for regional managers. Nobody was using it. I was the only designer on an engineering team, ran user interviews before touching a screen, and redesigned the tool from the ground up. A 4-minute task now takes 30 seconds.
My Role
Solo UI/UX
Designer
Timeline
August 2023 - December 2023
Shipped
80% despite pushback
Getting 50 regional managers off Excel and back into the tool built for them.
B2B Enterprise· BMW Group Johannesburg · 2023-2024
BMW built an internal data management tool for its regional manager network. Nobody was using it. I joined as the sole designer on an engineering team that had never worked with a designer before, ran user research before touching a single screen and redesigned the tool from the ground up. The most common daily task went from over 4 minutes to under 30 seconds.
My Role
Solo product designer
Users
10 – 50 regional managers across APAC
Timeline
Aug – Dec 2023 · 5 months
3 min read
01
The Problem
The tool existed.
Nobody wanted to use it.
BMW had built an internal data management tool for regional managers. The people responsible for tracking dealer performance, deadlines, and reporting across multiple locations.
When I joined as the only designer on the team, I found something that should have been a red flag from day one: managers had quietly gone back to Excel. They were copying data manually and building their own tracking sheets.
That's not laziness. That's a signal the tool failed them.


The original tool blue tiles, no deadlines visible, no clear hierarchy, two buttons that said exactly the same thing. It worked technically. It didn't work for the people using it.
Business impact of the problem: Regional managers were spending significant time on manual data reconciliation across 3+ disconnected systems. Deadline tracking lived in email threads. Dealer performance data required cross-referencing multiple exports. The tool existed but it wasn't reducing their workload at all.
02
Earning A Seat At The Table
My first job wasn't
to open Figma.
The engineering team had never worked closely with a designer before. My first job was earning their trust and not by presenting slides about design thinking, but by putting real users in front of them. I built a clickable prototype and brought managers into the room to use it while the engineers watched. When a manager spent four minutes trying to find something the engineers thought was obvious, the room went quiet. After that, the conversation changed entirely.


Working as the sole designer embedded in an engineering team. The turning point came when engineers watched real users struggle with a tool they thought worked fine.
03
User Research
Ten managers with two formats.
One clear picture.
Before touching a single screen, I ran one-on-one and group interviews with 10 regional managers asking them to show me how they worked, not just describe it. The two formats revealed different things.
One-on-one interviews
Where the real frustration came out
In private, managers were much more honest. They told me they'd stopped trusting the tool because data was wrong or missing. They'd
built their own Excel systems because they couldn't afford to miss a deadline waiting for the tool to catch up.
"I just don't trust what it's showing me. I check it in Excel anyway."
Group sessions
Where the shared pain became obvious
In group sessions, I asked managers to walk through a typical task together. When three different people hit the same dead end trying to find the same piece of information, it stopped being an individual complaint and became a clear design problem.
"Oh, you do it that way too? I thought it was just me."
Group sessions
Where the shared pain became obvious
In group sessions, I asked managers to walk through a typical task together. When three different people hit the same dead end trying to find the same piece of information, it stopped being an individual complaint and became a clear design problem.
"Oh, you do it that way too? I thought it was just me."
Group sessions
Where the shared pain became obvious
In group sessions, I asked managers to walk through a typical task together. When three different people hit the same dead end trying to find the same piece of information, it stopped being an individual complaint and became a clear design problem.
"Oh, you do it that way too? I thought it was just me."
04
The Redesign
Every decision tied to
something a manager told me.
Decision One: Integrated into BMW's ONE platform
The old tool was a standalone app with its own login and a completely different visual style. Integrating into the ONE platform gave managers personalisation, single sign-on, and a consistent experience, no more remembering separate passwords for separate tools.


The redesigned tool integrated into BMW's ONE platform same premium feel as every other BMW application, single sign-on, personalisation built in.
Decision Two: Deadlines you can actually see
Managers kept saying the same thing: "I didn't know it was due." or "I have to search through multiple emails to find it." The redesign made deadlines impossible to miss. Clear status indicators and a timeline view showing what was coming up, overdue, and done. No more separate Excel trackers.


Deadline tracker to show when users need to reach their deadline. Users can also change their deadline cycle.
Decision Three: Any task in 2 clicks or fewer
I mapped every common task managers did daily and rebuilt the navigation around those tasks not around how the system was structured. Speed wasn't a nice-to-have. It was the reason managers had given up on the tool in the first place.


New navigation built around the tasks managers do every day, not the system's data structure. Every key task reachable in 2 clicks or fewer.
Old Designs Vs New Design


Old vs new shown side by side in the stakeholder meeting. Same task, same user. 4 minutes became 30 seconds. The room didn't need convincing after that.
05
Stakeholder Pushback
The Product Owner pushed back.
The research pushed back harder.
Because the majority of BMW's configurator traffic arrived from social media on mobile, every decision was pressure tested on a phone screen first. Package cards sized for thumb taps. Price pinned to the bottom bar so it never disappears mid-scroll. Colour swatches enlarged and spaced for finger selection. Step navigation accessible from a fixed bottom control.
The Challenge
The Product Owner wanted to cut scope to hit the release deadline. The deadline tracker and unified data view were the two main features managers had specifically asked for and both were flagged for removal by the Product Owner. These weren't nice-to-haves. They were the exact reason managers had gone back to Excel.
How I Responded
I mapped each threatened feature back to a specific user interview finding. One point, stated clearly: cut the deadline tracker and managers go back to Excel. Cut the unified view and they keep jumping between systems. Both features shipped. 80% of the redesign delivered.
06
Outcome
From drop-off to
completion.
The redesign addressed every identified drop-off point: scroll fatigue, login friction, mobile usability and lack of visual engagement and launched two new features that removed the barriers stopping social traffic from converting.
88%
4 min task now under 30 seconds
0
Excel workarounds needed after launch
80%
Of redesign shipped despite scope pushback
07
Reflection
What I took away
Great design is only half the job. The other half is helping people around you understand why it matters without being preachy about it. I couldn't make great screens and expect the team to follow. I had to show them, with real users in the room, why the way something feels to use changes whether people use it at all. The 20% that didn't ship? I understand why. What I'm proud of is that the 80% that did ship was the right 80%. The features that mattered most to the managers opening that tool every single morning.
Next Case Study
3 min read
01
The Problem
The tool existed.
Nobody wanted to use it.
BMW's regional managers are responsible for tracking dealer performance, reporting, and deadline compliance across multiple locations. To support this, BMW had built a dedicated internal platform. When I joined the team, I discovered that managers had quietly gone back to Excel and were building parallel tracking systems by hand.
That's not user error. When people abandon a purpose-built tool and rebuild its functionality manually, the tool has failed them in a fundamental way. My first task was to understand why.

The original tool blue tiles, no deadlines visible, no clear hierarchy, two buttons that said exactly the same thing. It worked technically. It didn't work for the people using it.
Business impact of the problem: Regional managers were spending significant time on manual data reconciliation across 3+ disconnected systems. Deadline tracking lived in email threads. Dealer performance data required cross-referencing multiple exports. The tool existed but it wasn't reducing their workload at all.
Business impact of the problem: Regional managers were spending significant time on manual data reconciliation across 3+ disconnected systems. Deadline tracking lived in email threads. Dealer performance data required cross-referencing multiple exports. The tool existed but it wasn't reducing their workload at all.
02
Constraints & starting conditions
No user research existed and
no trust was built.
The engineering team had never worked with a designer before. There was no UX research, no documented user needs, and no baseline usability data. The Product Owner's working assumption was that the tool was technically sound and that adoption was a change management problem, not a design problem.
That framing was the first thing I needed to change and I couldn't do it with slides.
Constraint 01
No established design practice. I was building the case for UX from scratch, not inheriting one.
Constraint 02
Engineers assumed their mental model of the tool matched how managers actually used it. It didn't.
Constraint 03
Hard release deadline. Scope was fixed. Every design decision had to be defensible under pressure.
Constraint 04
Managers were busy. Research had to earn their time and not just request it.
03
Earning A Seat At The Table
My first job wasn't
to open Figma.
Before I could redesign anything, I needed the engineering team to understand why the tool was failing not from me telling them, but from watching it happen. I built a clickable prototype of the existing tool and invited regional managers in to use it while the engineers watched.
When a manager spent over four minutes trying to locate a piece of information the engineers believed was obvious, the room went quiet. That session changed the dynamic entirely. We stopped debating whether the design needed rethinking. We started talking about what the research had found.

Working as the sole designer embedded in an engineering team. The turning point came when engineers watched real users struggle with a tool they thought worked fine.
04
USER RESEARCH
Ten managers with two formats.
One clear picture.
I chose interviews over a heuristic audit deliberately. The interface wasn't completely broken on a technical level, it had been abandoned. An audit would tell me what was wrong with the UI. Interviews would tell me why people had stopped trusting it entirely. These are different diagnoses requiring different methods.
I ran one-on-one sessions and group walkthroughs with 10 regional managers. The two formats revealed different things: in private, managers disclosed the real frustration, data they couldn't trust, deadlines they found out about too late. In group sessions, the shared failure points became visible. When three different managers hit the same dead end on the same task, it stopped being a personal complaint and became a structural design problem.
Root cause 01
Data spread across 3+ disconnected systems. Managers had no single reliable view.
Root Cause 02
Deadlines were invisible inside the tool. Managers tracked them via email chains and personal reminders.
Root cause 03
Navigation built around system structure, not user tasks. Common tasks required 6–8 clicks.
Root cause 04
Trust was broken from inaccurate or delayed data. Once managers stopped trusting it, they stopped opening it.
05
Critical decisions & trade-offs
Every decision tied to
something a manager told me.
Decision One: Integrated into BMW's ONE platform
Managers were already using ONE daily. A standalone app meant a separate login, a different visual language, and one more thing to remember. Integration gave them single sign-on, personalisation, and a consistent experience at no additional cognitive cost.


The redesigned tool integrated into BMW's ONE platform same premium feel as every other BMW application, single sign-on, personalisation built in.
Rejected
Redesigning it on its own is quicker, but it keeps the same problems that made users leave in the first place.
Chosen
ONE platform integration meant more engineering effort, but removes the switching cost that was killing adoption.
Decision Two: Deadlines you can actually see
Every interview surfaced the same pattern: managers didn't find out about deadlines until too late. A separate "deadlines page" would have replicated the problem, something else to remember to check. Deadline status needed to be present in the default view, without the user having to seek it.


Deadline tracker to show when users need to reach their deadline. Users can also change their deadline cycle.
Rejected
Separate deadline module was cleaner to build, but maintains the behaviour of checking elsewhere.
Chosen
Deadline status displayed in the primary view. This required more layout work but eliminated the root behaviour.
Decision Three: Any task in 2 clicks or fewer
The existing navigation mirrored how the backend was structured, logical for engineers, invisible to users. I mapped the 6 tasks managers performed daily and rebuilt the navigation around those tasks. The alternative was adding a search bar to the existing structure. I rejected it because the search puts the burden on the user to know what they're looking for. These managers needed the tool to anticipate them.


New navigation built around the tasks managers do every day, not the system's data structure. Every key task reachable in 2 clicks or fewer.
Rejected
Add search to existing structure meant lower risk, lower effort, doesn't change the underlying navigation failure.
Chosen
Task-based navigation rebuild. Any key action reachable in 2 clicks or fewer.
Old Designs Vs New Design


Old vs new shown side by side in the stakeholder meeting. Same task, same user. 4 minutes became 30 seconds. The room didn't need convincing after that.
06
Stakeholder Pushback
The Product Owner wanted to cut the two features that mattered most.
Three weeks before the release deadline, the Product Owner proposed removing the deadline tracker and unified data view to protect the timeline. These were the two features every manager had named in interviews as the reason they'd built Excel workarounds. Cutting them would have shipped a tool that fixed the aesthetics and none of the problems.
I didn't argue on design principle. I mapped each threatened feature back to a specific interview finding and presented a single, clear trade-off: remove the deadline tracker and managers have no reason to stop using email. Remove the unified view and they're still jumping between three systems. Both are the product. Everything else is polish.
I then offered to descope a proactive notification system which was genuinely deferrable without compromising the core value. That gave the Product Owner something to cut that wasn't load-bearing. Both priority features shipped. The notification system was logged for phase two.
What this required: Understanding the difference between what's deferrable and what's structural and being able to make that argument with research, not opinion.
06
Outcome
From drop-off to
completion.
The redesign addressed every identified drop-off point: scroll fatigue, login friction, mobile usability and lack of visual engagement and launched two new features that removed the barriers stopping social traffic from converting.
<30s
Key task time down from 4+ min
3 to 1
Systems were consolidated into ONE platform.
80%
Core scope shipped on the original deadline
07
Outcome
From worked around to task
completion within the tool.
The redesign launched in December 2023 with 80% of the planned scope. The 20% deferred a proactive deadline notification system was descoped by mutual agreement to protect the delivery date without cutting core functionality.
In a post-launch comparison run with regional managers, the most common daily task was locating a specific dealer's performance data and checking deadline status which dropped from over 4 minutes to under 30 seconds. Three separate systems were consolidated into one view with a single login.
Within weeks of launch, managers had stopped requesting Excel exports. The tool they'd abandoned became the one they opened every morning. That shift from workaround to default was the outcome we'd set as the success benchmark at the start of the project.
<30s
Key task time down from 4+ min
3 to 1
Systems were consolidated into ONE platform.
80%
Core scope shipped on the original deadline
Note: Adoption data is directional, based on post-launch team observation and manager feedback. Quantified adoption tracking was not instrumented at this stage and was a gap I flagged for phase two.
08
Reflection
What I'd do differently.
The most effective thing I did on this project wasn't a design decision, it was putting real users in front of the engineering team before presenting any solutions. That session changed the team's relationship with the work in a way that no amount of UX advocacy would have.
What I'd do differently: I'd push harder to instrument adoption tracking before launch, not after. We had a clear behavioral benchmark were managers stop using Excel, but no way to measure it systematically. Asking someone to observe and report is not the same as having a metric.
The outcome was real. The evidence was thinner than it should have been.
The 20% that didn't ship? The right call.
What I'm most proud of is that the decision about what to descope was research-led, not pressure led. The features that mattered most to the managers who opened that tool every morning are the ones that shipped
