SUMMARY
In furtherance of City National's interest in streamlining the bank's problem asset reporting procedures, the quarterly Problem Asset Review Meeting (or PARM) reporting process was identified as one that would greatly benefit from a custom application. Therefore, I was tasked with designing an experience that maximized workflow efficiency, leveraged available report data from current problem asset applications and included a formal approval process.
LEGACY REPORTING PROCESS
The legacy reporting process began with identifying loans that met the 'non-performing' and 'criticized/performing' criteria and have balances in excess of $3MM as of the most recent quarter-end date. Loan data was then manually entered into individual Excel spreadsheet templates to create a very rough report draft. These report drafts were then distributed via email to team managers who distributed the reports to account credit officers to complete the reports.
A stark inefficiency of the legacy reporting process was that the reporting officers had to dig into their borrower's most recent Problem Credit Management Form to manually copy missing data and commentary into what became a very cramped and hard to read spreadsheet template.
Once completed, the prepared report was submitted via email to a team manager for approval. If approved (it could be returned for further editing) it was then forwarded for further approval via email usually by a division manager and, ultimately, a final approval by Credit Administration.
When all of the reports were approved by Credit Administration, they were manually compiled into a final report PDF for presentation at the quarterly Problem Asset Review Meeting and final review by senior level officers from Credit Administration, Credit Portfolio Risk and Special Assets.
With its reliance upon time-consuming manual tasks, data deficiencies, too many emails and absent a formal approval procedure, the legacy reporting process left much to be desired and was definitely in need of a streamlined application solution.
High-Level Legacy Reporting Process Flow Diagram
CONSIDERATIONS & CHALLENGES
How can I streamline the reporting process to maximize workflow efficiency by reducing the number of touches and automate the process as much as possible?
How can we leverage existing problem asset reporting data to reduce the amount of time and effort required to prepare a PARM Report?
How can I design a real-time, transparent approval process so that users know: the current status of their report, to whom their reports are going for review, who has reviewed them, what was the decision and what were the reviewer's comments?
PRODUCT IDEATION
Given the considerations and challenges, and after developing a solid understanding of the current process and defining the major pain points and the needs of our users, I started to ideate on some design solutions for the new product.
Instrumental to this effort was using Jeff Patton & Associates' user story mapping concepts to "keep your users and what they're doing with your product front and center'' to map out the entire process .
At some point in the ideation process, I started to see the design of the PARM reporting product as having three integral parts: a user dashboard, the report detail page(s) and a separate section devoted to the selection of recipients for the reports. I'll present and discuss each one of the these parts in detail shortly.
Buy the book
Once this concept was established, I created a comprehensive user flow to dive in and explore all of the nitty-gritty details of how each of these parts would work on their own as well as how they would fit together to complete the process. This was an invaluable part of my process to find any holes, uncover different user scenarios and address any edge cases prior to beginning work on the prototype.
User Story Map - Completing Quarterly PARM Reports
Scenario: As a Special Assets officer, Julie is required to report on the status, plan(s) of action, and risk classification for her borrowers with problem asset to senior management for review at the quarterly Problem Asset Review Meeting.
Currently, her task is almost entirely a manual process that involves the re-keying of data and commentary from one form, the PCMF, into yet another form, a cramped Excel spreadsheet that gets emailed up the management chain for rounds of review and, ultimately, for approval and inclusion in the PARM report.
"When are we going to fix this? Can't we do better than this?" is something Julie might say.
Julie needs a streamlined reporting process, one that: leverages the work she's already completed, provides easy-to-use editing functionality, a simple approval workflow with real-time report status and a well-formatted final PDF output.
DASHBOARD
At the end of each quarter, the system generates report drafts for borrowers with problem assets that fulfill the criteria which I previously discussed and automatically assigns the reports to the account officers of record. An electronic email is sent simultaneously to the account officers with a handy link to the PARM Reports dashboard.
On the dashboard, the core user needs are the abilities to identify the report(s) that need their attention and to take immediate action. Thus the view toggle control is default set to "My Pending Reports" when the page loads and I decided to 'raise the volume' here by adding a numbered red notification to the UI to draw users' attention to the reports that need action. It's a simple and widely-used design element that I didn't find in use in the bank's applications but I was thinking it may be effective for our very busy users that often don't take or have the time to read everything on the page.
PARM Reports User Flow - Happy Path outlined in green
I was genuinely excited to design an effective display for the individual report statuses as it was something that our users really needed. Not only does it communicate the status of the report but it also lets our users know exactly where their report is as it progresses through the review/approval process. So no more digging through emails or files to find a report, no more guesswork about the status of the report and, lastly, there is only one version of the report which alleviates a lot of potential confusion and frustration that comes with having multiple versions.
I'll dive into the design details of the report recipients later, but it's important to mention that it needs to be here on the dashboard so that users can see the status of the report recipients and can easily navigate there to view and edit the Recipient Queue.
Lastly, after speaking to some of our users, I wasn't entirely convinced that there was a great need to search for past reports but it was a business requirement and so it was decided to provide a very basic search functionality.
Preparer View - 'My Pending Reports' Ready to be Prepared - Recipients Not Finalized
Preparer View - My Pending Reports Completed & Submitted - Recipients Finalized
Preparer View - All Reports from My Team
Report Status States
Recipients Finalized
Recipients Not Finalized
REPORT PAGE
Leveraging existing data and the commentary sections from the borrower's most recent PCMF (or Problem Credit Management Form) yielded one of the biggest wins for our report preparers in that they start the reporting process with a report that is almost entirely complete. By automatically linking the most recent, approved PCMF directly to the PARM Report, the drudgery of having to find, copy and paste the required data into the report was eliminated. All that really remains for the report preparer is to condense their commentary sections to provide just 'the big picture' for consumption by our busy senior-level managers and credit administrators.
Another improvement to the efficiency of the PARM reporting process is allowing users to immediately submit their reports to the next reviewer for approval right at the bottom of the report page (provided the report recipients have been finalized). This feature represents a break with the design of a number of existing applications at the bank that require the extra step of having to go to a separate page to start the approval process.
To this end, I provided a comments box as well as an expandable 'Recipient Queue' section so that the user can see exactly to whom his or her reports are going. I placed these immediately above the Report Status section where users will be expected to make a decision as to what they're ready to do with the report. Similarly, for the Reviewers of the report, they will be able to see a complete history of who has reviewed the report, when they reviewed it and what were the other reviewers' decisions.
As you will see below, the design of the the bottom of the report page is dynamic and changes in accordance with whether or not the recipients of the reports have been finalized. 'Finalized Recipients' means that at least the next recipient (reviewer) of the report has been selected and added to the Recipient Queue.
Preparer's Report Page - Recipients Finalized
Preparer's Report Page (Bottom) - Recipients Not Finalized
In this scenario, this report and any other reports saved as 'Complete' by this team are immediately submitted to the next Reviewer when the recipients are finalized so there's no need for the user to return here to do anything.
REPORT RECIPIENTS & APPROVAL PROCESS
A number of assumptions were gleaned from my discussions with our product owner to help inform and drive the design of the report recipients and the approval processes. These included:
- The report recipients (reviewers) would be the same for each team at the bank and the reports would progress in a linear approval workflow starting with the preparer to: the team manager, then the division manager and would conclude with a final approval by a Credit Administration officer.
- Because the report recipients are the same for each team's report, the idea of requiring just one person (anyone) on the team (perhaps a team admin) to 'set up' the recipients for all was assumed to be a far more sensible and efficient solution.
- A flexible design that allows the different teams at the bank to decide whether to build out the entire approval chain at the beginning of the reporting period OR allow the reviewers to select the next reviewer in the chain at each review level. The former of these two options would make for a more efficient process because it's one less task for the reviewers and these same reviewers could possibly be automatically reused for the next quarter's reports.
- If a report was returned for any reason by a reviewer, it would be returned to the preparer for editing who would then have to resubmit the edited report for review and approval by the same recipients.
- Our users would need the ability to add a 'Read-Only Reviewer' strictly to read and review the report but the Read-only Reviewer would be unable to render a decision on the report.
Recipients Page - No Recipients Added
One challenge for the design of this page was to make it completely clear to the user that they will be adding recipients for all of the reports from his/her team. One of the ways I hoped to do this was through the use of explicit labeling and by displaying a list of all of the reports with the different preparer names from the team. Similarly, we carefully crafted the language immediately above the 'Save' button so that the user would know exactly what's going to happen next to the team's reports.
Recipients Page - Recipients Finalized
Once the user has added the report recipients, set the desired order for the reviews in the Recipient Queue using the drag and-drop tools and clicked 'Save', we display the 'Recipients Finalized' confirmation message as shown above.
At this moment, all of the reports that were saved as 'Complete' by the preparers (such as Acme Foods LLC, Kwik Bicycles, Inc and Think Pictures, LLC) on the report pages were automatically sent to their manager, George Welles, for his review. Any reports that were saved as 'Pending Completion' retain that status until the preparers save them as 'Complete' at which time they, too, are automatically sent to George Welles. All of these actions are recorded and displayed here in the expandable report history and the same is available for display on the individual report pages as well.
With the exception of a report being returned for editing, the team's reports would continue their journey on through the remaining recipients saved in the Recipient Queue until final approved by the final approver (e.g., Richard Price), in Credit Administration.
NEXT STEPS
The PARM Report application is currently in the build phase with the Technology & Innovation team at City National Bank.
WEAPON OF CHOICE
