Spectrum Agent OS Ledger
Below is the case study for a seven-day sprint where 10 designers from different disciplines collaborated to create a new call-center ledger.
The Challenge
Reduce call times and improve call-center agent productivity by reimagining how to present customer billing data.
Stakeholder objectives: Create a ledger that is both easy to use and takes little to no training to learn.
Designers (10 total):
Content Designers: Tandylyn Terry & Tom Quinn
Team Leaders: Michael Blakely & Brian McPherson
The Original Ledger
Day 1: Define the Problem, Make a Map and Lightning Demos
Before solutioning, we defined the problem we wanted to solve, came up with scenarios where the ledger would be used and looked at creative ways to present data from the real world. After listening to a research readout and watching agents interact with the current ledger, I formed my own problem statement: How might we redesign how billing data is presented to help the agent tell a more comprehensive and accurate customer story.
The problem: The sprint started by synthesizing the research presented and working as a team to define the problem. We all took turns presenting our interpretations of the problem and came up with a final design question.
Storyboard: Alongside the customer experience team, we created a scenario that would serve as a use case we would create the designs around.
Lightning demos: Finally, we all looked at existing designs and brought them to the group to present features we thought could benefit the new ledger. I thought the Google Flight's graph could be a creative way to display data.
Team goal: Design and build a Ledger that is efficient and conveys an easily understandable narrative of the account. However, the ultimate intent is to reduce Ledger use by creating contextually relevant, efficient tools/components outside of the Ledger so that it increases the Agent's trust in AgentOS and is relayed to the customer without translation.
Day 2: Crazy 8s and Solution Sketches
We spent time thinking about how we would solve the problem. I thought about Excel functionality and being able to copy and paste numbers by clicking on them instead of coping them into a calculator. I took this approach because during user testing, agents spent a lot of time transcribing data from the ledger to their calculator.
Crazy 8s: We all took ten minutes to sketch eight designs and presented them to the group. This was the first time we started talking about potential solutions to our sprint goal. Out of Crazy 8s, we came up with the preliminary ideas for a graph feature, a calculator, filter and search.
First draft solutioning: Next, we took four hours to come up with a low-fidelity solution that we all individually presented to the Spectrum's vice president of design. I focused mine on two concepts: including a calculator with Excel-like functionality and a page with answers to high-frequency questions.
Day 3 and 4: Designing
We split up into groups to tackle different parts of the design. I worked on the ledger structure with Brian McPherson (Product Designer) and Kathy Nguyen (UX Prototyper). We focused our conversations around which filters to include (relying on research and storyboards), how to name the categories (looking at other available tables to stay consistent) and how to access the page (whether it should be its own spoke). After two days of designing, we came up with the structure of the ledger.
I was directly responsible for the UI and design of the future months toggle.
Day 5 and 6: Prototyping and UX Testing
On day five, we finished the designs and Kathy created the prototypes while we worked with UX Researcher Eileen Beall to create the usability testing script. On day six, we were able to watch the usability tests that were conducted by Eileen.
Day 7: Research Review
Lastly, we affinitized the results and talked as a group about how we can use our research to better the ledger for the final designs that would be passed off to the development team.