PROJECT OVERVIEW
Pilot is an internal web application that users use to generate various financial reports for a financial services company based in Southern California. I’ve spent time working with Margaret Farron, a Visual Designer from Avanade, to improve the user experience of re-running reports in Pilot.
About this project: Re-run reports in Pilot
Problem: How might we provide clear indication to users that a report needs to be re-run after modifying the date in the date picker, ensuring accuracy when creating reports for investment group clients?
Solution: Design an overlay to remind the user to re-run the report, reducing human error when generating reports.
Timeline: From creating mockups to building the first iteration, the process took about 2 weeks.
My Role: I took the lead on the UX/UI design of a new feature to improve the report re-running experience, with my colleague’s support throughout the process.
Team: Myself and Margaret Farron (Visual Designer, Avanade)
Tools: Adobe XD, Figma
Please note: Due to legal & compliance guidelines, the company name and sensitive data has been removed from the mockups included in this case study.Before redesign:
Below: There is no visual indication that the date range for the report has been changed. Users have to remember to re-run the report.
Step 1: Synthesize user research findings
Based on previous user interviews, there were some common themes regarding how users typically use Pilot:
Users commonly engage with Pilot, along with a few other internal data applications, primarily during a specific 1-2 week period each month.
Users often leave Pilot in the middle of their workflow to verify data across other tools.
Users have to constantly change the date range across reports during the monthly reporting period.
Step 2: Usability audit
I performed a usability audit on the interaction of changing the date for a report in Pilot to identify opportunities for improvement. Findings:
Reports do not run automatically after the user has changed the date range.
Users can change the date for reports in Pilot, but there is no visual indication that the report needs to be re-run to reflect the changes.
The “Run” button remains in an active state before a date range has been applied.
Step 3: Ideation
Due to time and business constraints, I went straight into creating hi-fidelity mockups of some designs to demonstrate an alert for the user to re-run the report and shared my designs with the Product Owner:
Below: After the user changes the date, there would be a 30 second delay for the user to make changes to the report display options and a semi-transparent overlay would appear on top of the data with a message to give the user options to keep the current data or re-run the report.
Below: After the user changes the date, there would be a 30 second delay for the user to make changes to the report display options and a small modal would appear on top of the data with a message to give the user options to keep the current data or re-run the report.
Both of these options make it clear to the user that they need to take 1 of 2 actions: re-run the report or keep the current data. Requiring the user to take action prevents user error when creating reports for the investment group.
The Product Owner felt that the users would find this interaction distracting and overwhelming because the message would cover the data in the report. He suggested a tooltip design:
Below: After the user changes the date, an error icon would appear next to the report name and a tooltip would state that report options have changed.
Step 4: Finalizing the design
The tooltip solution would allow users to click anywhere on the page to dismiss the warning message. This would not solve the issue where users are able to mistakenly export data for an incorrect date range.
My colleague supported my design decisions and we convinced the Product Owner to agree on the overlay design with specific functionality requirements:
The overlay should be displayed after a timed delay (30 seconds) so that users can make changes to the report display options and date before seeing the re-run message.
Users will also be able to make changes to report display options while the re-run message is displayed.
The overlay should be transparent enough so that users can still see the data under the overlay.
Step 5: Handing designs over to the developers
I discussed with the development team about the desire to have 2 buttons to keep the data or re-run the report with the “loading overlay” option, but the developer assigned to this task said it would not be possible due to limitations with AG-Grid, the data system used for Pilot.
There are only 2 overlay options for the grid (see further documentation on AG-Grid.com):
Below: There is a ‘Loading Overlay’ with a small modal containing a simple message and a translucent overlay on top of the data.
Below: There is a small modal with a message on top of the data.
I shared the feedback from the developer with my colleague and asked her how we could adjust the design. Fortunately, my colleague had front-end development experience and knew that our design was possible with custom code.
My colleague and I met with the developer to confirm the desired design and user requirements, and we were able to come to an agreement by using custom code.
Final design:
Below: Following a user's date change in a report, a message appears after a 30-second delay, presenting the choice to either retain the current data or re-run the report.
Step 6: Gathering user feedback after build
The initial release of this feature incorrectly prompted the message to appear after less than 3 seconds. Users were frustrated with the design because they constantly saw the reminder.
I created a new development story in Jira for the developers to fix the code so that the message would appear after 30 seconds.
By the next release, the message appeared after 30 seconds, as expected, and 3 users gave feedback that the reminder is helpful if they are interrupted in their workflow and leave the application for a long period of time.
Reflection
After running into some road bumps with this design, I realized how important it is to advocate for users when explaining design decisions. In order to convince the Product Owner that the overlay solution was the best solution, I shared a specific use case based on user interview findings, “Users typically open Pilot, among a handful of other web applications, to create reports for investment group clients. It’s common for users to minimize the window for Pilot in the middle of their workflow to attend meetings, answer pings, or work on a time-sensitive ad-hoc report. When users re-open the window for Pilot, they have to re-orient themselves, it isn’t clear that a date has been changed, and they might mistakenly use/export incorrect data.” Sharing this use case with the Product Owner helped me defend my design and provide the best user experience for users.