Scaling transactions
Background
Level built an initial UX to support dental and vision benefits, but as we expanded the product offering to funds and other accounts, we needed to rebuild our core flow from the bottom up. This meant leaving behind the construct of a “claim” for a broader concept of a “transaction.”
Before:
Made for claims and visits to dental and vision providers
Process
Research
Before we got started, I worked with the designer to conduct a competitive audit of like products and their receipt-like experiences. For benefits and payments products, what were the key elements that went into a given transaction, and what was the hierarchy. We also conducted a card sort exercise as part of a user research session.
Competitive audit
Content development
Content and design development were done in concert. I worked closely with PM to understand every last use case, while working with design to solve for a universal flow that would support them all. Even before I started constructing any content, I set principles to keep the work grounded.
Content management
With over 30 core use cases, at least three surfaces for a message, plus solving for a sequenced build, there was a ton of content to manage. Sometimes the simplest solution is the best to a complex problem, so I created one heavy spreadsheet to manage it all.
A sample of a much larger content matrix: 37 core scenarios: notification, in-app explanation (sequenced for build complexity, emails)
Design Iteration
Where would all this content go? Informed by user research and spurred by an ambitious list of requirements, we settled on a “subway stop” model that showed transactions in process, as well as a space to show history and detail.
An example of a final, complex example. A food transaction where a member had to pay back an overage. Preview and expanded view. Looks simple. Isn’t!