battleface is an insurance startup that grows revenue through partnerships with other insurers. In these partnerships, other companies sell our products under their own brand name — and in return, they send us monthly sales reports and pay a commission based on those sales.
Earlier this year, our executive team raised a concern: six potential partners had backed out before signing agreements — a major issue since partnerships are one of battleface’s largest revenue streams.
Design: Tyler M, Ethan W
Product Manager: Jay C
Research, Prototyping, Product Strategy, Usability Testing, Design Systems, 0-1 Design
To understand why potential partners walked away, we interviewed key stakeholders — including partner representatives and the service and software engineers who manage partner integrations within battleface’s ecosystem. These conversations revealed a deeper issue:
In summary, battleface was losing partnerships because sales data reporting and integration processes were rigid, manual and difficult to scale. This created a frustrating experience for both partners and our internal team.
Guided by our interview findings, I identified three opportunity areas that our design solution should address. I also met with my PMs to confirm business goals — the most important being to win back the six partnerships that had fallen through earlier in the year.
These became the criteria we used to evaluate every solution moving forward.
I also researched how other companies solved similar problems before exploring solutions.
✅ Strengths:
🚫 Weaknesses:
Early explorations and research led me to a data field mapping concept within battleface’s internal tool, Marvin. While similar patterns exist on other platforms, the data import mapper needed to handle the complexities of insurance data.
I began with low-fidelity sketches to visualize a mapper that connects column headers from a partner’s sample sales report to the corresponding data fields in battleface’s system. The data mapper concept enables:
Seeing test participants easily grasp the concept was exciting. For the first time, we could picture a scalable way to process partner sales data — but I still had work to do to iron out the details.
Once the concept was clear, the next challenge was to design a mapping interaction that felt intuitive and didn’t overwhelm users with data. My early explorations resulted in the following concepts:
✅ Intuitive mental model
⛔ Scales poorly with product reqs.
⛔ No custom field management
✅ Scales well with complex products requirements
⛔ Mappable fields not visible
⛔ No custom field management
After testing and iterating the designs, I landed on a hybrid design that combines that combines the clear mental model of the drag-and-drop input with the scalability of the dropdown option. By optimizing the data mapping process, our internal team could create mapping templates with less friction, and utimately accelerate partnership integrations. [wd]
I also ran into an unexpected challenge while designing the transformation step. Our initial concept separated the process into three steps: clean data, map fields, and automate — following a progressive disclosure pattern. The goal was to simplify a complex task by focusing users on one step at a time.
During testing however, this approach started to break down. Users didn’t know what transformations they needed ahead of time, so they would begin mapping, realize something didn’t work, jump back to clean their data, and then return to mapping again.
This back-and-forth created confusion, increased completion time, and ultimately introduced the kind of friction we were trying to eliminate in the first place.
To address this, I shifted the approach and integrated data transformation directly into the mapping flow, reframing it as “Create custom field.”Instead of forcing users to plan transformations upfront, this allowed them to make adjustments in context. This change:
After months of iteration and testing, battleface launched the Data Import feature, which maps a partner’s sample sales report to our internal fields and creates a reusable setup. From then on, partners can send sales files as-is, significantly reducing additional work and facilitating onboarding for new partnerships.The new workflow addressed every major pain point uncovered during research:
Above is a quick overview of the data import feature. Click here for a more detailed walkthrough.
The impact of the data import feature was immediate – within the first 3 months after launch, the mapper was able to achieve the following:
in partnership revenue generated
33% above target
Improvement in partner onboarding time
The importance of solving the right problem
Looking back, the most valuable lesson I learned from this initiative was advocating for the user in the face of engineering pressure. If I were to put myself from two years ago in this situation, I may have backed down, but I stood my ground and fought for the users, even if it meant more work.
The importance of early testing
Part of the reason why the design process went so smoothly was because our team tested the mapper concept early and frequently. Early and frequent testing allowed us to validate the design direction and build a feature that solved both battleface’s and partners’ needs.