Aggregated Risk Report
In 2020, Capital One's Enterprise Supplier Management group created a process called Aggregated Risk Report (ARR) to comprehensively identify, track, and manage material risks generated by third parties supporting critical business activities. The report is required to be completed annually, with the option of scheduling an off-cycle report at the beginning of each quarter. I was brought on to lead UX for this report within an internal application called Supplier360 and design an intuitive user experience tailored to a variety of user groups, including third-party managers, category managers, category directors & accountable executives.
The Design Process — Research Methodology
We used three different data collection strategies to begin design and initial iterations. Starting with empathy interviews with users that had recently completed an ARR since we knew the original experience was fresh in their minds. This qualitative research method allowed us to gain deeper insights into edge cases through conversations with select user groups. Once I started designing, focus groups quickly became the teams favorite research method for the rest of the project. Gathering a small, but diverse group to discuss a specific topic or feature allowed us to quickly gather feedback on prototypes, new insights and solidify MVP requirements since our engineers were starting to plan out their development work.
In 2023, our MVP was finally ready in production! The business decided on a pilot group that consisted of 12 critical suppliers and our team launched the first quarter of ARRs in the new experience. We knew this pilot group was going to be vital for the success of the new process, so we conducted a user survey immediately after the ARRs were completed. This also enabled us to efficiently gather timely feedback from broader Capital One employees that were newly introduced to the ARR process.
The Challenge
While we knew from the user survey that the PDF wasn't formatting properly, soon this issue kept resulting in escalations from the business for our team to remediate due to time-sensitive nature of the ARR process. The PDF kept failing to handle extensive commentary from contributors. With limited front-end expertise among developers and I unable to access the PDF code via browser developer tools, implementing responsive CSS proved challenging. As a result, some TPMs reverted to the old process, while others opted to review their ARR directly within the application due to the PDF’s lack of presentation readiness. Given that this was an internal application team within Capital One, fully staffed by external agencies, the issue quickly escalated into a resource challenge. Developers were frequently pulled away from new initiatives to address CSS problems, often with suboptimal results. Recognizing the inefficiency, the product team requested that the tech lead and I rapidly design an alternative solution that did not rely on a PDF viewer. It became clear that achieving the required responsiveness was unfeasible without the appropriate expertise.
In Conclusion...
Although the idea of the PDF Generator was innovative, it was creating a poor user experience for our third-party managers and accountable executives. Removing it allowed us to still meet business requirements and simplified the experience for all, including our developers. If a user requested a PDF version of the report, our best solution was to customized the browsers print experience to mimic a simplified UI by adding a 4th tab titled "View Full Report". This tab allowed users to see all commentary and data visualizations in a single view.
I learned a valuable lesson in tech and design debt, which I share more on in my Medium article titled "Decoding Application Design: 3 Lessons in Designing for Enterprise". If I am ever tasked with a similar experience to design, I will advocate for a simplified solution and add enhancements later within the product roadmap. No designer or developer wants to rollback a feature less than six months from releasing when they've spent a year prior building it. Nonetheless, the experience of leading UX on a enterprise process of this nature was invaluable and I am excited to bring those learnings to share with future teams.