A system of record for agile delivery teams and organizational structure. TIR has evolved to enable resource management and is the tool for activating teams in Jira with a user base of 7,000 associates.
UI design
UX research
Service design
Internal Tooling
About
Problem & Scope
TIR was introduced to a new set of customers (software developers, delivery leads and managers) with differing use cases that needed to be accounted for. There was an additional need to create 'application (ASV) and component mapping' for each team shown.
The original design was outdated, non-compliant with accessibility standards and corporate design standards and had a low customer satisfaction score (NPS) of just -2 (out of 100) that the product team wanted to boost. I was tasked with a complete design refresh and creating additional features for our new customers.
My Role
I was a UX designer.
I worked with a 6 person development team, tech lead, and product owner at Capital One Bank.
Discovery
Overview
I ran a competitive analysis, spending time looking into the experience of competitive tools such as Pulse and Workday and realized that TIR could fill in some of the gaps these products weren’t providing our customers such as an integrated HR hiring system and sufficient team information.
Empathy Interviews
We interviewed 30-40 users within our new customer sets in our multiple Capital One campuses around the USA.
During the interviews I realized that most of the software developers were unfamiliar with the tool, so we rewrote the script to understand their needs from a registry tool instead vs. from a user feedback perspective. This resulted in a better understanding of exactly what needs developers were looking for.
Here - after conducting our interviews, I created our three personas to better empathize each of their needs and jobs to be done in the registry. Each persona having a very different set of needs and tasks done - but all consuming the same data.
User Personas
Here - after conducting our interviews, I created our three personas to better empathize each of their needs and jobs to be done in the registry. Each persona having a very different set of needs and tasks done - but all consuming the same data.
User Journey Map
After understanding each of our new personas, I plotted our user feelings on a journey map to understand what pain points they were encountering and started to generate solutions at each of these different points. Overall - we saw a trend that data management and consumption were the hardest to consume so we decided to focus on that area when doing our redesign.
Creating Persona Matrix and JTBD Chart
Since, we had additional persona’s consuming data in TIR, I created this matrix to compare and contrast different user needs to see if there were any connections between our old personas and new ones.
Findings
Our research and testing, revealed to us that:
Having application/component data mapped was the highest priority for new personas
They would come into TIR looking to confirm the team they were looking for was correctly mapped to the ASV/component they were working on and be frustrated that it did not exist leading to incorrect messaging and confusion
There was no clear picture of the data flow and ecosystems that existed for these needs
The application had a lot of ADA violations. More than 50% of users struggled to differentiate smaller text due to incorrect color and size contrast.
The application needed a full design touch up, with components, colors, and font needing to be updated to our corporate design system. Users mentioned that visually it could be confusing to consume data.
Ideation
Whiteboarding and Wireframing
Using our journey maps and personas, we started whiteboarding low fildelity mocks of the wireframe. We wanted to keep top of mind, how the data is mapped, making sure the experience was simplistic despite there existing a plethora of information to process.
Prototyping
During this process, I was involved in a many unfocused design review meetings, never ending rounds of iterations and indecision. To combat this, I set up a structured design delivery process that the team could agree on moving forward. This saved me a lot of time iterating and allowed us an opportunity to talk straight to our customers.
Below in my ASV prototypes – I challenged different UI experiences, from hierarchical cards, to avatar drop downs. We needed to understand if our new design should follow a similar experience as our ‘Team View ‘ feature or if changing their previous mental model meant that the data was more digestible.
Validation
Concept Testing
For our ASV Mapping Feature, we narrowed it down to two designs we were both really excited about but couldn’t figure out which one made the most sense from a usability perspective. We wanted to validate that at least 70% of users would find it still useful if we shifted to a different interaction state (than in their current mental model).
After speaking to 15 users, 75% of users preferred the newer concept we wanted to validate, most stating it was easier to consume the data and the experience was more intuitive. We learned that users didn’t want to spend much time searching for information – just run in and get out. So our Card style A laid out the information just right.
High Fidelity Designs
Find Member Search
Our leadership has a table view of individual team members that is linked out to their specific managers and teams for quick view information and a quick way to contact them. I designed this page for clear scan-ability and ease of use.
ASV Mapping
Our extensive testing and research for our final design shows a clear representation of the sufficient data fields that our customer persona’s were looking for.
We worked with the Service Now team (Capital One internal Application mapping) to understand how the data is visualized on their site and how both of our portals could be linked with each other.
Results
Learnings
This experience taught me the importance of consistently keeping open lines of communication between different parties/external teams. Throughout the project, leadership would silo ideation meetings but not communicate outcomes which led to a lot of time spent working on deprecated ideas. I had to start grouping our communication processes on slack/JIRA (using my old scrum background) between leadership, external teams, and design team so we were passing the most updated changes and shifts in priority.
The organization of communication helped relay information faster - and brought our team out of working in siloed pockets by connecting with others that would further support our project.