Rethinking Charter's Expense System
Rethinking Charter's Expense System
Redesigning Charter's expense reporting system in Power Apps to resolve significant usability issues and create a more efficient workflow for employees to submit and manage expenses across any device.
Redesigning Charter's expense reporting system in Power Apps to resolve significant usability issues and create a more efficient workflow for employees to submit and manage expenses across any device.
COMPANY
COMPANY
Charter Telecom
Charter Telecom
ROLE
ROLE
UX UI Designer
UX UI Designer
TIMELINE
TIMELINE
4 Months
4 Months
TOOLS
TOOLS
Figma & Power Apps
Figma & Power Apps
01 - OVERVIEW
01 - OVERVIEW
The Context & Problem
The Context & Problem
Before I joined, Charter's legacy expense reporting system was nearing discontinuation and needed to be replaced, prompting the software team to begin developing a new application. I was brought on to improve the UI where possible, but early observations quickly revealed several usability issues including inconsistent UI patterns, unclear visual hierarchy, and more.
Before I joined, Charter's legacy expense reporting system was nearing discontinuation and needed to be replaced, prompting the software team to begin developing a new application. I was brought on to improve the UI where possible, but early observations quickly revealed several usability issues including inconsistent UI patterns, unclear visual hierarchy, and more.
After presenting my findings, we decided to undertake a full redesign. I led by conducting a heuristic analysis to identify key usability issues, creating wireframes and prototypes to test different iterations, and developing a design system in Figma to maintain consistency throughout. I then collaborated closely with our developer to implement the final solution in Power Apps.
After presenting my findings, we decided to undertake a full redesign. I led by conducting a heuristic analysis to identify key usability issues, creating wireframes and prototypes to test different iterations, and developing a design system in Figma to maintain consistency throughout. I then collaborated closely with our developer to implement the final solution in Power Apps.
PROBLEM
PROBLEM
Charter's current expense reporting system has some major usability issues, making it difficult for employees to efficiently manage and submit expenses.
Charter's current expense reporting system has some major usability issues, making it difficult for employees to efficiently manage and submit expenses.
GOAL
GOAL
How might we redesign this system to resolve the current usability issues and create a more efficient workflow for Charter employees to submit and manage their expenses?
How might we redesign this system to resolve the current usability issues and create a more efficient workflow for Charter employees to submit and manage their expenses?
01
01
Inconsistent icons
Inconsistent icons
Icons were used inconsistently across screens, preventing users from building a reliable mental model of the interface.
Icons were used inconsistently across screens, preventing users from building a reliable mental model of the interface.
02
02
Poor spatial density
Poor spatial density
Oversized elements and poor use of space made the interface feel unpolished and required unnecessary scrolling.
Oversized elements and poor use of space made the interface feel unpolished and required unnecessary scrolling.
03
Unclear interactions
Interactive and non-interactive elements look identical, making it unclear what users can act on and creating confusion.
03
Unclear interactions
Interactive and non-interactive elements look identical, making it unclear what users can act on and creating confusion.
02 - USER RESEARCH
02 - USER RESEARCH
Key Insights
Key Insights
To better understand some of the challenges employees were facing I spoke with Ronnie Scott, Charter’s CTO and one of its most frequent users. During our conversation, he shared frustrations with the current design and emphasized how important it was that the system was easy to use, as he would be relying on it daily.
To better understand some of the challenges employees were facing I spoke with Ronnie Scott, Charter’s CTO and one of its most frequent users. During our conversation, he shared frustrations with the current design and emphasized how important it was that the system was easy to use, as he would be relying on it daily.
He also highlighted a major pain point, that the current system was desktop only, making receipt uploads difficult for employees who needed to submit expenses on the go. This was a major insight and made it clear that ensuring the application was responsive and accessible on mobile devices needed to be a central focus of the redesign.
"A lot of the time I take a photo of the receipt on my phone, but I can’t upload it until I’m back at my computer. By then I’ve either forgotten about it or lost the receipt."
"A lot of the time I take a photo of the receipt on my phone, but I can’t upload it until I’m back at my computer. By then I’ve either forgotten about it or lost the receipt."
— Ronnie Scott
— Ronnie Scott
03 - DEFINE
Problem Statement
Problem Statement
Charter’s expense reporting system has major usability issues and is restricted to desktop use, which prevents employees from submitting expenses in the field.
Charter’s expense reporting system has major usability issues and is restricted to desktop use, which prevents employees from submitting expenses in the field.
Framing
Framing
How might we redesign this system to resolve the usability issues and enable employees to easily submit expenses from both mobile and desktop devices?
How might we redesign this system to resolve the usability issues and enable employees to easily submit expenses from both mobile and desktop devices?
04 - WIREFRAMING
04 - WIREFRAMING
Early Explorations
Early Explorations
I began by creating multiple wireframe iterations of each screen in Figma, gathering feedback from users and my team throughout, and collaborating closely with the developer to ensure the designs were feasible within Power Apps.
I began by creating multiple wireframe iterations of each screen in Figma, gathering feedback from users and my team throughout, and collaborating closely with the developer to ensure the designs were feasible within Power Apps.
Early iterations revealed a few issues. Some elements were still too large and not using space effectively, contrast against the background was insufficient in several key areas, and competing visual hierarchies made it unclear what users should focus on first. These findings directly informed the design system, translating what was and wasn't working into clear rules for spacing, hierarchy, and contrast.
Early iterations revealed a few issues. Some elements were still too large and not using space effectively, contrast against the background was insufficient in several key areas, and competing visual hierarchies made it unclear what users should focus on first. These findings directly informed the design system, translating what was and wasn't working into clear rules for spacing, hierarchy, and contrast.
CONSTRAINTS
CONSTRAINTS
Every layout decision had to be validated against Power Apps' limitations before moving forward.
Every layout decision had to be validated against Power Apps' limitations before moving forward.
05 - DESIGN SYSTEM
05 - DESIGN SYSTEM
Building The Foundation
Building The Foundation
After identifying areas for improvement through my initial wireframing, I built a design system to establish a consistent foundation before moving into high fidelity designs. This provided a shared set of rules to build from, including a color system, component library, and typography scale, ensuring every screen felt intentional and cohesive going forward.
After identifying areas for improvement through my initial wireframing, I built a design system to establish a consistent foundation before moving into high fidelity designs. This provided a shared set of rules to build from, including a color system, component library, and typography scale, ensuring every screen felt intentional and cohesive going forward.
Since the application needed to be built in Power Apps, the platform introduced several constraints around available components, layouts, and font options. The design system addressed these limitations by defining clear patterns and components that could be reliably implemented while still maintaining a modern, polished interface.
Since the application needed to be built in Power Apps, the platform introduced several constraints around available components, layouts, and font options. The design system addressed these limitations by defining clear patterns and components that could be reliably implemented while still maintaining a modern, polished interface.
COLOR SYSTEM
COLOR SYSTEM
STATUS COLORS
STATUS COLORS
TYPOGRAPHY
TYPOGRAPHY
COMPONENTS
COMPONENTS
06 - TESTING & BUILDING
06 - TESTING & BUILDING
Further Refinements
Further Refinements
With the designs finalized, I created several prototypes in Figma to conduct user testing. However, due to time constraints introduced by the redesign, testing opportunities were limited and feedback was primarily gathered from Ronnie. While his input helped surface a few useful refinements before development, moving forward without broader user validation was not ideal and is something I would've approached differently given more time.
With the designs finalized, I created several prototypes in Figma to conduct user testing. However, due to time constraints introduced by the redesign, testing opportunities were limited and feedback was primarily gathered from Ronnie. While his input helped surface a few useful refinements before development, moving forward without broader user validation was not ideal and is something I would've approached differently given more time.
Once the designs were handed off, the developer and I worked together to build the final application in Power Apps. Post-launch feedback revealed that some elements were not rendering as intended, and after following up with the developer we traced the issue to an implementation problem which was causing certain elements to misalign. We eventually were able to find a workaround that ensured the designs were being implemented correctly.
Once the designs were handed off, the developer and I worked together to build the final application in Power Apps. Post-launch feedback revealed that some elements were not rendering as intended, and after following up with the developer we traced the issue to an implementation problem which was causing certain elements to misalign. We eventually were able to find a workaround that ensured the designs were being implemented correctly.
07 - BEFORE AND AFTER
07 - BEFORE AND AFTER
What Changed
What Changed
The original application was built without a designer involved. There was no design system, no defined patterns, and no user research. The result was an interface that worked functionally but created unnecessary friction at every step, leaving employees with a tool that was difficult to navigate and even harder to use on the go.
The original application was built without a designer involved. There was no design system, no defined patterns, and no user research. The result was an interface that worked functionally but created unnecessary friction at every step, leaving employees with a tool that was difficult to navigate and even harder to use on the go.
The redesign addressed this by introducing a structured foundation, clear visual hierarchy, and a responsive layout that worked across every device. Each decision was grounded from the heuristic analysis findings, ensuring the changes made were solving real problems rather than just making the interface look different.
The redesign addressed this by introducing a structured foundation, clear visual hierarchy, and a responsive layout that worked across every device. Each decision was grounded from the heuristic analysis findings, ensuring the changes made were solving real problems rather than just making the interface look different.
BEFORE
BEFORE
AFTER
AFTER
01
Responsive on every device
Employees can now submit and manage expenses from any device, directly solving the core limitation of the desktop-only original.
02
Clearer interface structure
A structured design system replaced the inconsistency of the original, giving users a predictable, easy-to-navigate experience.
03
Aligned design-to-dev handoff
Early collaboration with the developer meant the Figma designs translated cleanly into the Power Apps build with minimal rework.
01
Responsive on every device
Employees can now submit and manage expenses from any device, solving the limitation of the desktop-only original.
02
Clearer interface structure
A structured design system replaced the inconsistency of the original, giving users an easy-to-navigate experience.
03
Design-to-dev handoff
Early collaboration with the developer meant the Figma designs translated fairly cleanly into the Power Apps build.
IMPACT
IMPACT
Redesigned a business-critical expense reporting tool used daily by 150+ employees, resolving friction across the submission and approval process and freeing up time employees could redirect toward higher-value work.
Redesigned a business-critical expense reporting tool used daily by 150+ employees, resolving friction across the submission and approval process and freeing up time employees could redirect toward higher-value work.
08 - LOOKING BACK
08 - LOOKING BACK
What I Would Do Now
What I Would Do Now
Returning to this project with more experience, there are several things I would do differently. One of the biggest gaps was the usability testing, with limited time and feedback coming largely from a single stakeholder, the designs moved into development without the level of validation they needed. Given more time, taking the prototype into the backcountry and testing it in a real environment would have been an important step before finalizing the feature, ensuring the content held up where it mattered most.
Returning to this project with more experience, there are several things I would do differently. One of the biggest gaps was the usability testing, with limited time and feedback coming largely from a single stakeholder, the designs moved into development without the level of validation they needed. Given more time, taking the prototype into the backcountry and testing it in a real environment would have been an important step before finalizing the feature, ensuring the content held up where it mattered most.
Additionally, I would've invested more time wireframing before moving into high fidelity, using low and mid-fidelity prototypes as a testing tool rather than waiting until designs were nearly final. Earlier exploration would have caught issues sooner, reduced revision cycles, and given a stronger foundation before committing to a direction. Returning to this project later, I revisited the designs and explored a potential direction that built on the original while addressing some of the areas I felt had room to grow.
Additionally, I would've invested more time wireframing before moving into high fidelity, using low and mid-fidelity prototypes as a testing tool rather than waiting until designs were nearly final. Earlier exploration would have caught issues sooner, reduced revision cycles, and given a stronger foundation before committing to a direction. Returning to this project later, I revisited the designs and explored a potential direction that built on the original while addressing some of the areas I felt had room to grow.
01
01
Intuitive status colors
Intuitive status colors
The original used shades of blue to distinguish between statuses, requiring users to learn what each shade meant. I created a redesign that replaced this with more intuitive colors to reduce cognitive load.
The original used shades of blue to distinguish between statuses, requiring users to learn what each shade meant. I created a redesign that replaced this with more intuitive colors to reduce cognitive load.
02
02
Summary buckets
Summary buckets
A set of summary buckets were added to surfaces key values at a glance. This provides users with a quick snapshot of where things stand without having to scan through individual entries.
A set of summary buckets were added to surfaces key values at a glance. This provides users with a quick snapshot of where things stand without having to scan through individual entries.
03
03
More functional toolbar
More functional toolbar
I also introduced a more capable toolbar above the expense table. While this could not be implemented within Power Apps, it represents what the experience could look like on a more flexible platform.
I also introduced a more capable toolbar above the expense table. While this could not be implemented within Power Apps, it represents what the experience could look like on a more flexible platform.
9 - REFLECTION
9 - REFLECTION
What I Learned
What I Learned
Process is not optional
Process is not optional
A key takeaway from this project was the importance of following a proper design process from the start. The original application was a clear example of what happens when development begins without one, and experiencing that contrast firsthand reinforced just how much research, iteration, and testing contribute to a product that actually serves its users rather than simply getting shipped.
A key takeaway from this project was the importance of following a proper design process from the start. The original application was a clear example of what happens when development begins without one, and experiencing that contrast firsthand reinforced just how much research, iteration, and testing contribute to a product that actually serves its users rather than simply getting shipped.
Build as you design
Build as you design
Working within Power Apps' constraints taught me that design and development are most effective when treated as one continuous process rather than sequential handoffs. Catching feasibility issues early, adjusting designs in response to technical feedback, and maintaining an open dialogue at every stage meant fewer surprises, less rework, and a final product that was stronger for it.
Working within Power Apps' constraints taught me that design and development are most effective when treated as one continuous process rather than sequential handoffs. Catching feasibility issues early, adjusting designs in response to technical feedback, and maintaining an open dialogue at every stage meant fewer surprises, less rework, and a final product that was stronger for it.