Role: Experience Design Intern
Company: Capital One, Card Design
When you think about design, banking might not be the first industry that comes to mind. That’s part of the reason why it initially appealed to me. Capital One is investing in design, and in doing so, investing in a better experience for the customer. Money affects people everyday and can be a source of joy or of stress, and I was excited about the prospect of reducing the latter. As a member of the platforms team in card design, I had that opportunity.
The main projects I worked on over the summer fell under an overarching theme of relationships: relationships between teams at Capital One, between customers and Capital One, and between customers and their money.
Problem I: The lack of a standardized close-out process between tech, design, and product doesn’t ensure follow-through
For my first project, I was in primarily a service design role as I worked with a teammate to outline the closeout process. We began by interviewing designers, product owners and developers to better understand each team’s process and identify gaps that could be preventing follow-through.
I created user journeys based on the interviews to identify the gain points that worked well for teams and pain points that didn’t work so well. For a more comprehensive view, I created a combined journey of the three perspectives.
We put together a slide deck that detailed what teams could do at each step of the design process and what resources they could use to make for a better close-out. I translated that into two blueprint checklists–one of the design process from start to finish and one focused on close-out. The idea is that teams can use these checklists as guidance. The project will continue and go more in depth on intake and other parts of the design process.
I learned that process really depends on the project and the individuals on the project team, but that having everyone follow similar guidelines from before a project even begins can streamline communication and ensure consistency.
Problem II: Design teams aren’t able to maximize their use of communication platforms and share documentation seamlessly
For this project, I worked with a team to evaluate the current platform that the card design team was using for project and document sharing, identify issues, and make recommendations for restructuring use of the platform.
I began by diagramming a site tree to visualize the team’s current use of the platform. I went through and labelled sections of the tree to see how the items related to the team and to one another.
This revealed insights such as inconsistencies in how teams interpreted different sections of the site and in how projects were organized, which made their resources difficult to find if they fell under more than one topic area. The latter, for example, could lead to problems like duplicated efforts if team members didn’t realize another team had already done similar research that they were planning to do.
I collaborated with team members on ideas for a new structure and guidelines, including making a tagging system. Through this process I learned how digital systems can mimic real life.
Problem III: Need to understand how customers with authorized users think differently about their Capital One accounts and (future) ways to pay.
With changes happening to the architecture of Capital One’s website, they realized the need to make the current and future architecture scale for customers with multiple authorized users and multiple forms of payment for themselves and their authorized users. To help accomplish this, I created diagrams of mental models and architecture alignment that could be used as references for designers.
I began by trying to understand the diagram that my manager had given me as a starting point. I interpreted the relationships between the variables in the diagram, considered missing variables, and further defined variables.
After creating two new versions of the diagram, I put them in front of users with the scenario of being an account holder with multiple authorized users and asked how they interpreted the diagrams. With these findings I continued to iterate, but wanted to take a more user-centered approach.
I interviewed users to understand how they think about money at a deeper level. I asked questions such as, “Can you tell me about the most recent purchase you made and how you decided to pay for it?” I provided them with markers and paper in case they found it helpful to explain anything with visuals throughout the interview. In the end, I sketched diagrams based on what the users said and drew.
I then went back to iterating on the diagrams, and, in the end, provided two: one focused on the customer’s mental model and one focused on how the new website architecture aligned with the mental model. Through this project, I learned how seemingly simple concepts can prove to be complex and how not only design, but also research can be an iterative process.
Problem IV: The current website architecture is designed from the single account-holder perspective (feature-first), without taking authorized users and future ways to pay into consideration.
Following from my project on customer mental models for managing authorized users and future ways to pay, I created a cautionary tale to reveal what could go wrong if we didn’t take this perspective into consideration.
Based on research that had previously been conducted at Capital One, I came up with two personas, Will and Jackie, to show how both a family and small business might have issues with the current flow. I visualized this with the most common use cases for small business and families: locking a card and changing a spend limit. Adding an empathy map to the flow shared what users might think/feel and say/do in these different use cases.
The resulting deck proved that users needed to be able to take both a feature-first and user-first approach, because their mental model would be different depending on the scenario. Creating this deck taught me how to make a business argument with design and how use cases can accomplish that when prototypes aren’t complete.