.png)
As a global enterprise, Capital One has thousands of third parties that the corporation relies on to function. We set out to make a landing page that would add value and make tracking those relationships more efficient.
This is the process through which I designed the landing page for Capital One’s supplier data system. Details and designs will remain vague in the interest of NDA compliance.
Users have to navigate through many different systems in order to find all the data they need to do their jobs on a day-to-day basis.
A platform was created that connected to all of these different systems and became a single source of third party data.
This was a labor-intensive technical feat, and yet... there weren't as many users as expected.
When I joined the team, the product manager and program owner had already held interviews and focus group sessions with a variety users.
They landed on two main reasons people didn't use the platform:
We on the product team held brainstorm/whiteboarding sessions in the hopes of addressing these issues.
The current landing page was a list of "pinned" suppliers followed by a list of pending activities - activities that only really applied to one role in the company:
.png)
A dashboard could display the most necessary data in the most useful way.
The users who didn't know what to do would immediately see what they needed.
The users that didn't see the value of switching might be given value in the form of ease and efficiency.
Although the platform catered to a wide variety of roles within the organization, regular use would come from those who worked in the third party management department. We selected a specific role - Accountable Executive - that we thought could benefit the most from what we were doing and that was underrepresented in our user base, with the plan of creating versions that catered to other roles in the hierarchy afterward.
I conducted 9 interviews with Accountable Executives expecting some variety in what they'd want to see, but there was a unanimous common denominator:
Is everything okay? Are there fires that need putting out?
This was a role with a lot of anxiety and a lot of responsibility - it's in the title.
After all, what happened at a third party was largely beyond their control. They needed to know that at least they were on top of it.
There are a variety of metrics that measure different kinds of risk in the organization, but 8 that came up consistently and with varying levels of importance.
So this would be a risk dashboard and it would need to:
Show high risk on an individual supplier level so that problems could be easily spotted and attended to.
Show the overall health of their portfolio of suppliers so that more systemic problems could spotted and attended to.
Show how many contracts need approval - this wasn't a risk unless a deadline was missed. Notifications for these approvals came by email and were therefore easily lost in the shuffle or forgotten. Remind them!
The trickiest part of this design was going to be packing all those metrics for all those suppliers on a single page.
I played around with the concept of "Supplier Scorecards" that would combine all the metrics into one or a few aggregate scores. These scorecards could then open by accordion to reveal specifics.
I quickly realized that this idea would take up a lot of extra space, would require the user to translate scores, and would add a lot of extra clicks to get a better understanding of what was going on.
I realized that the best, most useful solution - while not the most aesthetically pleasing - was the most simple solution. What would come to be affectionately referred to as...
.png)
Capital One has a very robust design system, which made it easy to skip the wire-framing process and see how everything would actually look.
It's not pretty, but it sure is thorough, and for a critical internal system that's what mattered most.
Beyond that, four graphs would reflect the overall health of this portfolio of suppliers:
.png)
(Capital One uses a third party for its graphs), so I only did the mockups.)
Throw it all together and the landing page would look something like this (including the existing nav bars):
.png)
With these additional details:
1
The number of suppliers to confirm that the user is seeing everything they are supposed to.
2
Rather than simply telling the user how many approvals were outstanding, I added a button that would take them to the system where those approvals take place
3
A "more details" icon button opens a modal (below) with more details about the data that underlies the graph, and a link to the associated page in our platform.
4
Because some users have upawards of 100 suppliers, I added filters and sorts to all them to more easily find what they needed. Metrics were laid out in the order that users said they were most important, and the default sort prioritized that most important metric.
5
To cut through the clutter of all those numbers and metrics, I escalated the high risk cells by giving them a red background and making the value red and clickable. Clicking on these cells would open a modal with details about that particular risk and a link to the associated page in our platform.
.png)
Graph modal
Megatable modal
Our team chose to forgo usability testing since we were already planning a contained pilot that would allow us to test every aspect of the new page - tech bugs, data issues, etc. After getting the go-ahead from the SME's that there were no obvious issues from a design standpoint, the page was built and launched for a group of 30 users.
I sent out a survey to these 30 users two weeks into the pilot to get there input on the design. Was there anything in there that wasn't necessary? Was there anything missing? Was there anything confusing?
We also told these users to Slack us directly with any issues there were encountering.
What resulted was a GIANT spreadsheet. A tracker that the product team went over to determine priority and necessity. Many suggestions would have called for even more data to be imported to the landing page making the load times untenable. Some wanted the ability to customize the landing page, allowing them to reorder the columns, or having a widget system for the graph section, but on further exploration a) these users were dealing with edge cases unique to each individual user and b) this simply wasn't feasible from a tech standpoint at the time.
From a design standpoint, most notes had to do with changing of text for consistency with other systems. There were also multiple people who wanted the graphs and the snapshot to be downloadable, which was simple from an engineering standpoint and even simpler for design, only requiring the addition of some download icon buttons.
About 20% of the notes we got back had to do with other pages. This was a good sign since the landing page was designed to keep users on our platform. Now they were exploring deeper into the site and discovering all that it had to offer.
The feedback we received when we first tested the pilot was very positive, and users clearly thought that a dashboard was a game-changer for the way they did their job.
We noticed that new users included not just Accountable Executives, but users just above and just below them in the hierarchy which indicated that we had a good foundation for when we created a version specifically for those personas.
At the end of the first month of the full rollout, our number of regular users went up by...
41%...
...a number that far surpassed any expectations.