Telecommunications Internal Operations
Overview
When “Just a Quick Change” Turns Into a Two-Week Wait
It was my third month in the Project Review and Learning (PRL) team when I noticed a pattern: every time something needed to be changed, such as adding a new project leader, tweaking a delivery area, or updating an email template, the process would come to a halt.
The irony? PRL was a tool designed to capture learning and improve future delivery across the whole of BT Group: BT, BT International, BT Business, EE, Plusnet and Openreach, yet internally, our process was slowing down learning in real time.
So, I decided to fix that.
Business Problem
An Invisible Time Sink Eating Developer Hours
The development backlog was cluttered with minor admin/configuration tasks that didn’t need to be there. A Jira ticket would be raised, a developer would (eventually) pick it up, and a small update would crawl through the pipeline like it was a major release. This was misaligned with our department's (Corporate Units Digital) goal: to improve operational efficiency through targeted digital transformation.
That meant:
Delays of days for changes that could take minutes
Developer time spent on low-value tasks
Solution
An Admin Dashboard Built for Autonomy
The Product Owner had a one-page mock-up for a simple admin screen. However, I quickly realised the scope was far bigger: we weren’t just adding a page; we were essentially giving admins the keys to the engine.
I pitched a more robust admin dashboard that would let admins:
Add/remove leaders instantly
Update delivery areas and methods with transfer lists
Create, edit, and send email templates without touching SharePoint code
Make inline edits without a page reload
And most importantly, do it without developer involvement.
Key Challenges & How We Resolved Them
Constraints Made It Stronger
Constraint 1: 💁♀️ The new kid on the block
Being new to the team, I needed to quickly get under the skin of how PRL worked from an admin’s perspective. I led a discovery workshop to map the admin journey, surface constraints, and understand the real-world workflow.
From there, I created a user flow (below) to gain a clear, end-to-end view of:
How admins accessed PRL
The sequence of actions they took to complete tasks
Where bottlenecks, dependencies, and handoffs occurred
Constraint 2: 🚫 Budget? What Budget?
With no additional design tools budget (it was an impromptu Q4 project), I had to make the most of my existing Figma licence and get creative with what I had. I leaned heavily on the BT Group Corporate Units Design System, which not only saved time but also kept the design consistent with brand guidelines.
Constraint 3: 🖥️ Built on SharePoint
SharePoint was both our host and our limit. I worked closely with developers early to understand what was possible within its constraints, adjusting designs so they were both usable and technically feasible.
Research
Data Told Us Where to Start
I pulled up the Jira backlog (below), which at the time of looking was about 80 tickets, and tagged the ones an admin could handle with the right tools. Around 20% were instantly obvious wins.
I also looked at other internal admin systems for patterns: how they handled authentication, error recovery, and fast editing.
Design and Iterate
Designing for “One-Click and Done”
I began with rough conception designs to ensure I was heading in the right direction before investing time in higher fidelity work.
I brought these early designs to an all-day workshop at BT’s HQ, One Braham. The response was positive, the team liked the foundation and overall direction, but a few important questions and suggestions came up:
Leader edits: In the initial flow, reassigning a leader’s business unit meant opening a separate edit form (in the form of a modal, similar to the 'Add Leader' flow. I suggested this may create unnecessary clicks and context-switching, as essentially, the main purpose of editing a Leader was to change their business unit. I proposed that inline editing would let admins make quick changes directly in the table, keeping them “in the flow” (below)
Undo actions: Removing an item in the MVP design was permanent. Admins raised concerns about accidental changes and the time cost of correcting them. Adding an “Undo” link in toast banners, supported by a “soft delete” in the API, would give a safety net without slowing down work (below)
Testing
Agile Loops, Tangible Progress
We worked in two-week sprints. After each iteration, I:
Ran mini “backlog simulations” to check which Jira tickets the design could now replace
Gathered team feedback and made quick adjustments
Validated technical feasibility with devs before locking anything in
Finally, by sprint 4, we had a dashboard design that could clear 20% of the backlog.
Results and Impact
Less Waiting, More Doing
Key results included:
20% backlog reduction for admin/config tasks in the first 2 months
Time on task:
Adding a leader: 4–5 mins → around 2 mins (backend → dashboard)
Updating delivery area: 6–8 mins → around 2 mins (backend → dashboard)
I asked for feedback from the Product Owner:
“Amanda has mapped out user journeys for the learning tool over the last six months, and each time she has presented, she has improved.
Before mapping any journeys, she reached out to other areas to understand best practices, which is always very helpful.
In her designs, she tries to make things simple and easy to understand, and her use of Figma is very good!”
Reflection
Small Changes, Big Freedom
While this project wasn't about flashy UI, it was about giving PRL admins the ability to act instantly instead of waiting potentially for days, and freeing up devs to do actual development.
What I learned:
Backlog analysis can quantify design value before you even start
SharePoint constraints aren’t blockers if you co-design with devs.
And yes, we did use PRL to record our feedback!
Thank you for reading.