Legacy Finance App Redesign
OVERVIEW
A Fortune 500 Company [Client] reached out to Accenture interested in a complete redesign of their legacy application to transition their internal desktop application to a web-based platform and address numerous user complaints they’d received over the years.
*This work is confidential and all visuals have been extensively reworked to protect client confidentiality. The purpose of this case study is to emphasize process and method. Finwallet and [Client Product] are used throughout this case study as pseudonyms.
ROLE & DURATION
Lead UX Designer,
7 months
PROGRAMS
business Problem
Users are leaving the product in favor of outside applications for critical data entry. Tasks performed externally present an unclear paper trail and an auditing issue for managers and government compliance.
stakeholder interviews
Understanding the stakes
For this engagement, we spoke with several senior level executives, but focused primarily on Stakeholder A and Stakeholder B, once we identified them as the true decision-makers of the project. They provided a balanced perspective since Stakeholder A was the Vice President of the US region and Stakeholder B oversaw the non-US regions.
Both Stakeholders were considered Super Users of the product, as well, because they were the only two persons with sign-off privileges for all 40+ users of the application. Any journal entries or other product errors required their input.
Stakeholder A came with a lot of insights from the business perspective with a focus on metrics and how to standardize final outputs. While, Stakeholder B was more concerned about the quality of overall process because the non-US users had shared more functionality concerns.
“We want to create something new and exciting. Think beyond the current boundaries.”
“I want to sit down, log in and the screen shows me how to prioritize the day.”
“I just want to be able to see only what I care about. Not everything all at once.”
user interviews
Getting to know the users on a global-level.
Over the course of five weeks, I facilitated 40+ hours of user interviews with over 25 users across 5 regions and 10 countries. The Client pre-selected these individuals for interview based on their job functions. Their skills and familiarity with the product ranged from beginner to expert.
We suspected the biggest painpoints might be similar across all team regions since the product lacked a natural workflow process. But, we also wanted to be able to be able to highlight the concerns from non-North American teams since they frequently expressed feeling last to be heard.
Users are moving their work to Excel and duplicating calculations that could have been done in [Client Product].
Users don’t find the actual process overwhelming. Instead, what they do find overwhelming is the amount of “irrelevant information” that’s displayed to them.
Users prefer to input all their data at once.
Users are leaving [Client Product] to track deal statuses.
Users complain about how many clicks and windows it takes to complete a single task.
*Non-North America teams are more collaborative than their North America-based colleagues.
*Non-North American users are frustrated by the lack of cultural considerations, like currency defaults and government taxes, causing them to do additional calculations outside of the product.
user Journeys
Following a Day-In-The-Life
So, we customized a journey map with horizontal lanes for each application the users interact with during a deal including, [Client Product], Excel, other internal Client products, or even their email inbox. Then, created vertical columns to identify different phases within a deal type. And then below, we listed user pains and gains during specific tasks.
As we’re building these maps, in a single view we’re now able to see what the user is trying to do, where they’re doing it, when they’re doing and how they feel about it. And finally, we color-coded each region’s journey so we could combine these journey maps to see where our regions were overlapping and where they’re deviating.
Despite the extreme complexities of the system, we realized at the product’s core, every single user needs to:
First,
Log Fees.
(regardless to whether the client is the recipient or the sender).
Then,
Adjust Balances.
(regardless to whether the client is the recipient or the sender).
And Finally,
Settle Debts.
(regardless to whether the client is the recipient or the sender).
product workshop
Understanding and prioritizing the user painpoints
After identifying our focus areas, we moved on to prioritization. We re-color-coded each of our original 10-15 observations to its paired product theme allowing us to clearly identify pattern themes in any quadrant. Creating this hierarchy established the new design’s foundation and guiding principles for the client. And we frequently referenced it when rationalizing specific product features and how they’re displayed in relation to other features in the new design.
From throwing all our sticky notes up on the matrix, we saw a lot of the ‘Streamlined Process’ sticky notes ending up in ‘Quick Wins’ followed by ‘Error Recognition.’ Meanwhile, we saw ‘System Integration’ stickies consistently falling under ‘Big Bets.
Targeting big ticket items at the fair
Streamlined Workflow
Comes from user frustrations that [Client Product] isn’t intuitive enough to know their job tasks.
Excel Features
Users repeatedly referenced Excel when explaining the preferred features that were keeping them from using [Client Product] properly.
System Integration
The Big Ticket Item. While this one is the least reliant on us and more on funding, it’s still necessary to point out. Most of the need comes from them wanting automation.
Data Validation
Speaks don’t trust [Client Product’s] math. Every user in every region has an Excel file on backup with various calculations for their workflow.
design thinking
Brainstorming potential solutions to user concerns
Recognizing that the leading painpoint for System Integration was outside of our control, we began to strategize how to mitigate these issues with solutions that were in our control to ensure the user needs are still addressed. As a team, we used the How Might We activity to reframe the main user and stakeholder painpoints and needs as questions in order to strategize solves.
How Might We…
Potential Solutions
Reduce user time out rates without compromising security?
Allow users to pre-determine whether the content is final or requires a ‘Draft Mode’
Add auto-save functionality throughout the workflow in critical sections where users frequently time-out
Standardize the workflow across all regions?
Push most frequently used option to first position based on user journey
Disable selections that don’t match the user journey
Ease the transition of the new design for users?
Include ‘Info‘ icons to explain new categorizations
Add a ‘Help’ section in Navigation
Add a walkthrough tutorial video or .pdf
Include email contact to [Stakeholder A] for follow-up questions
Get users to trust [Client Product’s] math?
Add ‘Tool Tips‘ to show formula
Group all affected content together so changes can be see in real-time
Export a final Excel sheet to double check the math
Page types & product flow
Categorizing and connecting the dots between content
Using the User Journey maps, we identified what tasks were being accomplished and when to create the page types housing specific features. We created two categories: Key Pages and Workflow.
Key pages build up the navigational framework and feed into the Workflow pages that establish the linear workflow. Using the user journeys as a guide, we re-grouped tasks that are completed in a single sitting to reduce the amount of windows user interact with.
Anchor Pages: MyDeals, Deal Library, Journal Entries
Workflow: Deal Dash, Summary, Deal Calc, Fees, Trading, Expenses, Invoices, Settlement
We devoted the early stages of wireframes to building out blocks that had a holistic approach to both current and future content. Although our project scope did not encompass a full redesign of [Client Product], we wanted to ensure the pages we did own were a strong enough foundation that the page types would serve as templates for development far beyond our engagement period.
low & mid-fidelity
Sketching a rough road map
Throughout the process, we prioritized design annotations, that logged our rationale throughout wireframing process. By doing so, we ensured each content block carried a clear purpose that was rooted in our Design Thinking discussion, including features decisions and previously confirmed product flows.
This streamlined the approval process when having discussions with development and the client. [Product] is an extremely complex application, but by being able to link decisions to past discussions, we continued to build trust with [Client].
summarizing complex workstreams
Keep It Simple:
MyDeals is only an aggregate of information and users should spend least amount of time here
- Created high-level content blocks for the MyDeal page’s framework, which mostly comprised of tables.
- Worked with the stakeholders to determine the biggest table column identifiers, so that users could quickly confirm their selection.
recognizing the individual experience
Keep it Simple:
Globally, the internal process for users differs across all regions and those differences should be accommodated.
- Pointed out even Stakeholder A and Stakeholder B preferences differ on opposite ends of the spectrum.
- Confirmed with Dev which customizable features would be easy lifts with a huge impact.
building task-oriented dashboards
Keep it Simple:
Both the MyDeals and Deal Dash dashboard need to create a to-do list.
- Focused on how to direct users to a solution in same view as the task request.
- Highlighted the importance of validating successful completions to avoid negative associations with either of the dashboards.
seeing data at a glance
Keep it Simple:
Deal Dash needs to provide a pulse check of a deal so both managers have a high-level summary and users have a to-do list in the same view.
- Identified the greatest indicators of deal status from each page type within Deal Dash.
- Pinpointed valuable data visuals users are used to seeing when working with specific data sets.
design system and hi-fidelity
Marrying content to color
Working in an Agile environment, we accepted information can always change and treated our design system as a living document. But, at the same time, if we create systems firmly rooted in confirmed content, then the production cycles will be much more manageable.
And with so many different data sets and user types, the style guide needed to be intentional and purposeful to be effective. This ensures users will immediately recognize content that is labeled to:
- Categorize content on an individual/team/region-level;
- Indicate status or;
- Differentiate input data vs. output data.
solution
How to measure success
This product is currently in the build phase, and design is not scoped for additional support. But we recommended the following metrics for success measurements:
Increase in single session completion rate
Decrease in session time-out rates
Decrease in time spent on search/results page
Decrease in flagged errors
