B2B2C · Arity (Allstate) · 2023–2026

Arity

Connected-vehicle data, delivered through partner products and into customer lives.

Role

Director, Design Lead

Parent

Allstate

Partners closed

Experian ·Alarm.com/ADT ·SiriusXM

Products shown

Mobile Publishing ·RTA ·Geosight

The situation

Allstate did not own the data. Arity did.

Arity is Allstate’s connected-vehicle data business. The asset is enormous: anonymized driving telemetry from tens of millions of vehicles, refined into insights a carrier, retailer, municipality, or connected-home platform can act on — owned and operated by Arity, not the parent brand.

The asset wasn’t the problem. Getting it inside an experience customers actually use was — usually through a partner’s app via the SDK. That is B2B2C: the product you design is never the product the end customer sees.

The architecture I was designing into

Three audiences. One shared data substrate.

Across Arity’s four business units, three audiences kept showing up — and the design had to honor all three on every screen.

A

Arity (the platform owner)

Needs the data integrity preserved, the source attributed, and the platform’s standards visible enough that the next partner can trust them. Internal stakeholders: product, sales, data science.

B

The partner (the mid-tier business)

For Mobile Publishing, this is Experian, Alarm.com/ADT, SiriusXM — each of them embedding Arity inside their own product, under their own brand. They need the integration to read as theirs, not ours. For Aggregated Insights, this is a state DOT or municipal traffic team. For InSol, it’s an insurance underwriter.

C

The end customer (the consumer or operator)

The driver inside an Experian app. The homeowner inside an Alarm.com dashboard. The municipality resident affected by a traffic decision. Most often these people never know Arity exists, and that’s correct — the brand promise belongs to whoever sits in front of them.

Every design decision had to make all three audiences right at once. Optimize for any single one and the other two start to fail.

Three products, three decisions

How the framework played out in shipped work.

Three places to show the decisions: RTA, a B2B SaaS tool I led design on (Story Builder for retail and municipal trade-area analysis); Geosight, a B2B data product I prototyped for state DOTs, insurance carriers, and other regional operators; and Mobile Publishing, the SDK partnership family where the design has to live inside a partner’s app and brand.

Decision 01 · RTA

Progressive disclosure for a question that takes a while to ask.

Arity RTA Story Builder, v1 dark theme. Left rail with READY-tagged steps (Primary Location, Trade Area, Select Competitors, Timeframe). Map of Chicago with circular trade-area geofence around 7-Eleven #1247. Traffic corridors panel listing inbound/outbound routes with conversion and competitor metrics.
RTA Story Builder, v1. A 7-Eleven location with 1-mile pass-thru trade area, three named competitors (BP, Circle K, Shell), and 19 ranked traffic corridors. Demo Mode pill, top right.

Site selection is not one question. It is six questions in sequence, where the answer to each one constrains the next: which store, which trade area, which traffic type, which competitors, which window of time, which behaviors. A retailer who wants to know whether a Chick-fil-A in Naperville will pull pass-thru traffic from a Walmart isn’t going to absorb that as one screen.

The decision: build the analysis as a Story Builder — numbered steps in a left rail, each one marked READY when complete, locked progression so the analyst sees the model’s assumptions as they assemble them. The map updates live as each step lands. The complexity is real; the experience of building the query is not.

Arity RTA v3, light theme. Chick-fil-A #3814 Naperville with drive-time isochrone (30 min), data-driven catchment cells visualized as a green polygon mesh radiating from store pin. Volume / Conversion / Opportunity tabs at top.
RTA v3 iteration, light theme. Same Story Builder logic, refined visual language. Drive-time isochrone replaces fixed-radius geofence; analysts gain a more honest trade-area model.

The design decision was not the map, the colors, or the components. It was the order of operations. The framework had to teach the analyst how trade-area thinking works while she was using the tool, so that the final report she handed to her boss carried not just an answer but the model that produced it.

Decision 02 · Geosight

Same data substrate. Different audience. Different shell.

Geosight, dark theme. State of Texas with five named rating territories (DFW Metro, Houston Metro, Austin/San Antonio, Rio Grande Valley, Rural East TX) visualized as colored circles. Left rail shows rating territory list with average driving scores and drift percentages.
Geosight for the state DOT view. Texas, five rating territories, drift threshold filters. The user is a transportation analyst.
Lighter zip-code level driving score heatmap, San Francisco Bay Area. Each zip code shaded green/yellow/red by average driving score. Tooltip on 94019 Half Moon Bay N shows 77.16 average driving score.
The zip-code drill-down for an insurance underwriter. Same data, denser geographic resolution, lighter chrome.

Geosight runs on the Aggregated Insights data product — anonymized driving and road-segment data, rolled up to zip-code, town, and regional levels. The same underlying numbers serve a state Department of Transportation deciding where to repaint a corridor, an insurance carrier setting usage-based premiums, and a retailer evaluating last-mile delivery risk.

The decision: resist the urge to ship one product for all three audiences. A DOT analyst wants geographic visualization at the territory level; the right entry point is a map of regions with drift filters. An insurance underwriter wants a sortable deviation table with risk and opportunity columns; the right entry point is the analytical dashboard below.

Geosights light theme, full analytical dashboard. Left rail: Analysis Scope (Region, Metric, Timeframe, Sensitivity) and Quick Analysis presets (Worst Scores, Highest Risk Behavior, Trending Worse, Opportunities). Center: Chicago Metro choropleth map with 43 ZIPs flagged for Phone Usage per Mile. Right widgets: Primary Metric Trend line chart, Behavioral Context multi-line chart, Exposure Context numerical summary, Correlation Analysis scatter plot, ZIP Code Metrics sortable table. Results summary 43 flagged / 12 risks / 14 opportunities.
Geosight insurance-underwriter view. Chicago Metro, Phone Usage per Mile metric, four linked widgets (trend, behavioral context, exposure context, correlation, ZIP table). The same data substrate as the DOT view, surfaced for a completely different decision.
Geosights with Deviation Summary side panel open. Panel shows Chicago Metro / Phone Usage per Mile / Last Quarter; 26 of 184 ZIPs flagged at 1.5 sigma from regional mean. Greatest Loss Exposure table lists Wood Dale, Country Club Hills, East Garfield Park, Elk Grove Village, River Forest with deviation values. Best Competitive Pricing Targets table lists Des Plaines S, Gary W, Ashburn, Skokie, Oak Brook. Save JSON, Export CSV, Copy Summary buttons.
Deviation Summary side panel for the same analyst — this is the artifact she emails to her pricing committee. Save JSON, Export CSV, Copy Summary. The design has to leave the screen, on her terms.

The decision was not just to make two views. It was to refuse the synthesizing instinct — the design-leader instinct — that wants to ship one elegant product. The two audiences deserved two products that respected what they were each there to do. Shared data, separate shells.

Decision 03 · Mobile Publishing

When the design has to disappear into someone else’s brand.

The Mobile Publishing business closed three SDK partnerships during my tenure: Experian (driver-score features inside a credit and identity product), Alarm.com / ADT (vehicle and driving signals inside a connected-home dashboard), and SiriusXM (connected-vehicle features inside an in-car audio experience). Each one is a B2B SDK licensing arrangement. Each one ends up in front of millions of end customers who will never see the Arity name.

I cannot show those partner-cobranded screens here — they belong to the partners, under NDA — but I can show the decision framework I used across all three.

i.

Defend the data, defer on the chrome.

The rule I held: Arity gets to insist on how the data is computed, labeled, and qualified. The partner gets to insist on how the data looks, sounds, and is named inside their product. The boundary lives at the integrity of the calculation, not at the pixel.

ii.

One reference design, three theme adapters.

We built a single reference implementation of each SDK feature in an Arity-branded sandbox, then produced a theme adapter for each partner that bound the same component tree to their type, color, spacing, and copy systems. The partner’s product engineering teams could read the diff, not relearn the system.

iii.

Design the demo before the negotiation.

Each partnership opened with a working prototype on partner data — not a Figma deck. AI-augmented prototyping (Cursor, Figma Make, Copilot, frontier LLMs against real telemetry) made that possible at sales-cycle speed. The conversation moved from “could you build this” to “here is how it feels.” All three partnerships closed.

The pattern is the same one you see in WeCare upstream: figure out who the end user actually is, design for her honestly, then negotiate the institutional layers above her without compromising her experience. The Mobile Publishing model just makes the institutional layers more literal.

Outcome

Three closed partnerships, two live products, one design culture that ships.

3

Mobile Publishing SDK partnerships closed (Experian, Alarm.com/ADT, SiriusXM)

2

B2B products shipped to demo / live (RTA Story Builder, Geosight)

days

Concept to working prototype on real telemetry — the cycle time AI-augmented prototyping bought us

The thing I am proudest of is not in the metrics. It is that the team learned to ship working prototypes on real data fast enough that the conversation with partners moved from speculation to evidence. Sales got a tool. Product got reactions. Engineering got a target. The design culture earned its credibility by shipping — not by presenting.

Why this work matters here

B2B2C in health is the same problem with higher stakes.

A health platform is sold to an employer, used by an employee, mediated by a coach or a clinical team, and underwritten by an insurance or benefits structure that nobody sees. Each layer wants different things from the same shared substrate. The end user has the least power and the most at stake.

What I learned at Arity transfers directly. Defend the integrity of what the data and the clinical content actually say. Defer to the partner’s brand and operating model where it doesn’t compromise that integrity. Design the demo before the negotiation, so the conversation is grounded in something working. And keep the end user — the person actually trying to change their life — at the center of every call, even when she is the audience with the least voice in the contract.

That last commitment is the one I borrowed straight from WeCare, a decade earlier, and have never put down since.

← Previous: EdjSports Next: inSure →