DATA VISUALISATION.
Making powerful data
configurable
Restructuring the data architecture behind Capillary's loyalty platform so a marketing manager — not an engineer — could assemble a loyalty programme. The key move: organising the data the way a loyalty loop actually behaves.
CLIENT
Capillary Tech
ROLE
Lead UX Designer
FOCUS
Data architecture
PLATFORM
CDP+ · Loyalty+
STATUS
Shipped
2
Datasets split from one tangled structure
Activities · Actions
6
Data dimensions unified into one model
Architecture
12
Stakeholder interviews across roles
Card sorting
7
Critical data handoff gaps mapped
Problems identified
00 — CONTEXT
A platform that was powerful,
but unreadable.
Capillary Technologies powers loyalty programmes for hundreds of brands across dozens of countries. Its CDP+ and Loyalty+ platform generates vast amounts of customer, transactional, and engagement data every second.
But that data was scattered across disconnected modules, siloed by the system that produced it, and structured for machines — not for the marketing managers who actually had to build and run programmes on top of it. The scale that made Capillary valuable was the same scale that made it impossible to use without an engineer in the room.
BUSINESS RISK 01
Powerful features going unused
The most strategically valuable capabilities had the lowest adoption. Capability the business had invested in was sitting idle because no one could reach it.
BUSINESS RISK 02
Engineer dependency to configure
Marketing managers couldn't assemble a programme without technical help. Every configuration became a cross-team ticket, slowing every brand's time-to-launch.
BUSINESS RISK 03
Data the business couldn't see
"We have the data. We just can't see it." When clients can't access the intelligence they're paying for, the platform's core value proposition quietly erodes.
Design reframe
This was never a feature-building problem — the features already existed. It was a legibility and configurability problem. My job was to restructure the data so the people who run loyalty programmes could assemble one themselves, without translation.
01 — THE PROBLEM
The most valuable feature had the lowest adoption.
When I mapped feature adoption against feature value, the pattern inverted. This wasn't a training gap — it was a design legibility problem. The data existed; the path to it didn't.
Campaign Mgmt
88%
Loyalty Txns
82%
CDP Profiles
71%
Nudge Framework
38%
aira /ML
29%
LDS Reports
19%
Adoption rate by feature, at project start. The 5× gap between the most-used and least-used features maps almost exactly to their technical complexity — not their value.
These numbers were my brief, not my result. They defined the problem I was given to solve. Post-launch adoption measurement was owned by the client's analytics team, and I left Capillary before the longitudinal data was available — so this case study shows how the design directly targets each barrier, not a claimed after-number I can't substantiate.
PAIN 01
Data lived in silos, not stories
CDP+, Loyalty+, and LDS operated as isolated systems. Users had to mentally connect fragmented dashboards to build any picture of programme health — a task most gave up on.
PAIN 02
A technical wall around the intelligence
SQL analytics, Scala queries, and propensity models were inaccessible to the non-technical marketing professionals who needed them most.
PAIN 03
Opaque metrics breed distrust
The proprietary LDS metric had 19% adoption. Its calculation was a black box — users couldn't validate it, so they simply ignored it.
02 — RESEARCH & DISCOVERY
Mapping the data universe before restructuring it.
A structured approach to understand what data existed, how it flowed between systems, and exactly where it broke down for the people configuring programmes.
1
Platform Audit
Heuristic evaluation of CDP+, Loyalty+, and the analytics dashboard. Catalogued every data point and visualisation exposed to users.
→ 60+ data touch points mapped
2
Stakeholder Interviews
Spoke with marketing managers, programme analysts, and C-suite sponsors. Identified which data was valued vs. which was invisible.
→ 60+ data touchpoints mapped
3
Data Journey Mapping
Traced a single customer event from CDP → Loyalty → Nudge → LDS. Found the points where data became invisible between systems.
→ 7 critical handoff gaps
4
Opportunity Synthesis
Clustered findings via affinity mapping. Prioritised by user impact × business value × feasibility to define a clear direction.
→ 3 priority areas identified
60+
DATA TOUCHPOINTS MAPPED
12
STAKEHOLDER INTERVIEWS
7
CRITICAL HANDOFF GAPS
6
DATA DIMENSIONS TO UNIFY
03 — THE STRUCTURAL DECISION
I used the Hook Model to structure the data - not the product.
A loyalty programme isn't a static feature set. It's a loop: a customer does something, the programme responds, the customer receives and uses a benefit, the brand communicates, and the cycle repeats. That behavioural loop is the Hook Model — and I argued it should be the organising logic for the platform's data architecture itself.
The insight that made this more than theory: if the data is organised the way the loop actually behaves, a marketing manager can assemble a programme by composing the loop — instead of hunting for fields scattered across six systems.
Model 01 — The loyalty loop, as a Hook cycle
Activity by customer
trigger - brand's or their own
Communicate
app/message
PROGRAM
Triggers an action
in the program
Customer uses
the benefit
Customer gets
benefit/offers
Reading the loop: every loyalty program, regardless of brand, moves through these stages. The two teal stages are things the customer does.
The two amber stages are things the program does in response. That split is the whole insight - and it became the data architecture.
DATASET A
Activities the customer can do
Every activity a customer might perform in a loyalty programme lives in one dataset. A marketing manager browses this single space, picks the activities relevant to their programme, and adds new ones — without touching another system. One place, one mental model.
DATASET B
Actions the brand takes
The program responses — the actions that build the hook — live in a separate dataset. Keeping actions distinct from activities is what lets a manager compose cause-and-effect: pick an activity, attach an action, and the loop is configured. Mixing them was the original sin of the old structure.
Model 02 — How one activity connects to one action
1
Activity
by customer
Set
What does it
do to the
activity?
2
Activity
by customer
Scope
What does it do to the activity?
3
Activity
by customer
Condition
What does itdo to theactivity?
4
Activity
by customer
Expression
What does itdo to theactivity?
5
Action
by brand
Expression
What does itdo to theactivity?
The connective logic : a customer activity passes through four configurable layers — Set, Scope, Condition, Expression — before it connects to a brand action. This is the granular machinery that links Dataset A to Dataset B, and it's what made the loop composable rather than hard-coded.
WHERE I HAD TO HOLD THE LINE
A PM review pushed to make Hook the whole product. I argued its right scope was the
data layer.
In a stakeholder review, there was a pull to treat the Hook Model as the product's organising philosophy end-to-end — to let it shape flows, screens, and the entire experience. I pushed back. Hook was the right lens for structuring data — the activities-vs-actions split, the connective logic between them — but forcing it onto the whole product would have imposed a behavioural-engagement frame on what was fundamentally a data-comprehension problem.
Being precise about where framework applies and where it doesn't was the most important decision in the project. Hook earned its place in the data architecture. It didn't belong everywhere.
The result: a data model a marketing manager could actually compose with — activities in one place to browse and extend, actions in another to attach — without an engineer translating between them.
04 — SURFACING THE INTELLIGENCE
The AI already existed. My problem was making it reachable
SCOPE, STATED PLAINLY
I did not build Capillary's AI models — the Nudge recommendations, propensity scores, and ML outputs were the data team's work, and they were good. My design problem was different and just as hard: how do you make existing machine intelligence ambient, legible, and trustworthy for a non-technical marketer, without burying it or overwhelming them? That's a surfacing and placement discipline, and it's where my decisions lived.
SURFACING
Nudge, made
ambient
Barrier: flagship AI sat in a submenu at 38% adoption
The recommendations were strong but invisible. I moved Nudge from a buried submenu to a persistent daily panel — the first thing a programme manager sees each session. An AI recommendation that requires a click to discover has already failed; the design decision was to make the intelligence the default surface, not an optional destination.
LEGIBILITY
Narrative over
raw metrics
Barrier: marketers ≠ data scientists
Rather than expose raw metric tables, I designed plain-language summaries as the primary layer, with full analytical depth available on demand. Progressive disclosure: a marketer gets the meaning first; a data scientist can still drill to the SQL. Same platform, layered cognitive entry points — nothing hidden, everything sequenced.
TRUST
LDS, made
transparent
Barrier: most strategic metric, 19% adoption, opaque calculation
LDS was ignored because it was a black box. I designed a layered explainer — contextual tooltips, comparison scenarios, and methodology walkthroughs at every level — so users could understand and validate the number. An opaque metric is an untrusted metric; transparency was the design lever for adoption.
05 — OUTCOMES
What shipped, and what I can honestly claim.
The data restructuring shipped to the stakeholders. Here's what's directly attributable to the design work — and where the measurement boundary sits
2
Datasets split from one tangled structure — activities vs. actions
Directly attributable
6 - 1
Siloed data dimensions unified into one narrative layer
Directly attributable
01
Shipped the activities-vs-actions data restructuring into the live platform, giving marketing managers a single composable space to assemble loyalty programmes
02
Connected six previously siloed data sources into one narrative layer, eliminating the cross-system context-switching that defeated most users
03
Repositioned the flagship AI from a buried submenu to the default daily surface — directly targeting the 38% adoption barrier
04
Designed the LDS transparency system to convert the platform's most strategic but least-trusted metric into a validatable decision tool
05
The honest boundary : post-launch adoption measurement was owned by the client analytics team
06 — LEARNINGS
What this project confirmed about how I design.
01
A framework's value is knowing its edges
Hook was exactly right for the data architecture and exactly wrong for the whole product. The skill wasn't applying the framework — it was defining precisely where it applied and defending that boundary in review.
02
Structure the data like the behaviour
Organising the data the way the loyalty loop actually behaves — activities apart from actions — is what made it composable for a non-technical user. Architecture that mirrors mental models needs no translation.
03
Surfacing is its own discipline
I didn't build the AI, but making existing intelligence ambient, legible, and trustworthy was as much a design problem as any interface. Placement and disclosure decide whether powerful features get used at all.
04
Opacity is an adoption killer
LDS at 19% wasn't a value problem — it was a trust problem. Users won't act on a number they can't validate. Transparency isn't a nicety in data products; it's the precondition for adoption.
05
Don't simplify by hiding
Progressive disclosure preserved full analytical depth for power users while leading with meaning for everyone else. Simplification is sequencing the data's presentation, not removing the data.
06
Claim only what you measured
The adoption numbers were my brief, not my proven result. Being explicit about the measurement boundary is what makes the rest of the case study credible — a number you can't defend undermines the ones you can.
A PM review pushed to make Hook the whole product. I argued its right scope was the
data layer.
The work at Capillary wasn't about adding features — it was about structure. When you organise data the way people actually think about their work, powerful systems stop needing a translator. That's the difference between a platform that's capable and one that's usable.
I care about this kind of enterprise data work because the stakes are quiet but real: a buried AI recommendation is wasted investment, an opaque metric is an eroded relationship, a feature no one can reach may as well not exist. Making intelligence legible is design at its most leveraged.
Designed & built with care · Edwin Fernandes © 2026
Available for full-time roles
Edwin Fernandez