Xperiti Case Study: How We Rebuilt a Research Platform's Core Experience

This project didn't start as a platform redesign. It started as a conversation about fixing a few screens.

Xperiti was a research operations platform, a product built to help market research teams manage the entire lifecycle of qualitative and quantitative studies from one place. Recruitment. Scheduling. Interviews. Surveys. Incentives. Reporting. All of it.

The product worked. People used it. Revenue was growing.

But the experience was starting to crack.

Features had been shipped faster than the design could keep up. New capabilities were bolted on quarter after quarter. The navigation grew. The workflows forked. What had once been a focused tool was becoming a sprawling system that even its own team struggled to explain in a single sentence.

The initial ask was practical: clean up some flows, improve a few screens, make things feel more polished.

Within weeks, it became clear that the problem wasn't a few screens.

The problem was the entire product architecture.

"They asked us to redesign some pages. We ended up redesigning how the product thinks."

What we actually walked into

The first time we mapped out the platform's full feature set, we filled an entire wall.

Studies. Participants. Surveys. Interviews. Scheduling. Incentives. Payments. Communications. Reporting. Team management. Client portals. Participant marketplaces.

Each of these was a product in its own right. And they were all living inside one platform — connected technically, but disconnected experientially.

What we noticed immediately

Navigation had become archaeology. Finding a specific feature meant knowing where it was buried. There was no intuitive path — just memorized routes. New users had to be trained on the product's structure before they could do anything useful.

Everything affected everything else. Change a participant's status? That rippled into scheduling, incentives, communications, and study completion tracking. But the interface never made these dependencies visible. Users would update something in one place and not realize it had broken something three screens away.

Qualitative and quantitative research were treated like different products. Researchers managing both types of studies — which was common — had to context-switch between completely different mental models inside the same platform. Different layouts. Different patterns. Different logic.

Study creation was an endurance test. Setting up a new study required navigating a multi-step process that felt more like configuring enterprise software than starting a research project. The friction was high enough that some researchers kept templates in external documents just to remember what fields to fill in.

Participants were managed, not understood. The participant system tracked people as data entries. But it lacked workflow awareness — there was no easy way to see where a participant was in their journey, what they'd completed, what was pending, or whether they were at risk of dropping off.

The timing mattered

Here's what made this project more than a redesign.

Xperiti was entering a critical growth phase. The market research technology landscape was consolidating. Competitors were getting more integrated. Enterprise buyers were demanding platforms, not tool collections.

The product needed to evolve — not just look better, but work better at scale — to support the company's trajectory.

This wasn't a cosmetic exercise. This was a strategic business initiative disguised as a design project.

The stakes were real. And, as it turned out, the timing was perfect — the platform was later acquired by Ipsos, one of the world's largest market research companies.

The insight that changed everything

We interviewed researchers. We watched them work. We mapped their workflows across multiple studies, multiple tools, multiple days.

And we kept noticing the same pattern.

Every competing platform — and the existing version of Xperiti — organized itself around tools:

• Here's the survey tool.

• Here's the scheduling tool.

• Here's the participant tool.

• Here's the incentive tool.

But researchers didn't think in tools.

They thought in studies.

A researcher's mental model was: "I'm running a study on consumer behavior in Southeast Asia. I need 200 participants, 50 interviews, a screening survey, scheduled sessions across three weeks, and incentives paid within 48 hours of completion."

That's one thought. One workflow. One goal.

But in the existing platform, that single thought was scattered across six different sections, each with its own navigation, its own logic, and its own interface patterns.

The platform was organized around what it could do.

It needed to be organized around what researchers needed to accomplish.

"Researchers don't wake up thinking 'I need to use the scheduling module today.' They think 'I need to move my study forward.' That distinction reshaped the entire product."

Understanding four very different users

Most products have one primary user type. Maybe two.

Xperiti had four — and they had almost nothing in common.

Researchers

The power users. They lived inside the platform daily. They managed multiple studies simultaneously, tracked hundreds of participants, and needed operational control without operational overload.

Their biggest frustration: the platform made simple things slow and complex things invisible.

Study Coordinators

The operational backbone. They handled scheduling, participant communication, incentive distribution, and workflow coordination. They didn't care about research methodology — they cared about logistics running smoothly.

Their biggest frustration: no single view of what needed their attention across all active studies.

Clients

The people commissioning the research. They needed visibility — progress updates, participant numbers, completion rates — without needing to understand the platform's internal mechanics.

Their biggest frustration: getting answers about study status required asking the research team instead of checking the platform.

Participants

The most underserved user type. These were real people — consumers, professionals, interview subjects — navigating the other side of the platform. Their experience was often confusing, overly long, and poorly communicated.

Their biggest frustration: unclear instructions, broken scheduling flows, and delayed incentives.

The design challenge was building one platform that served all four — without any of them feeling like the experience was designed for someone else.

Mapping the ecosystem

Before we touched a single screen, we spent weeks mapping the platform's operational architecture.

This wasn't typical wireframing. This was system mapping — understanding how every feature related to every other feature, where dependencies existed, and where a change in one area would cascade into others.

What we discovered was that Xperiti wasn't really a SaaS product in the traditional sense.

It was an ecosystem.

Participant management didn't just store participant data. It fed into scheduling, which fed into communications, which fed into study completion tracking, which fed into incentive distribution, which fed into payment processing, which fed into reporting.

Touch one node and the entire chain moved.

This is why the original redesign scope — "fix a few screens" — was never going to work. You couldn't fix scheduling without fixing participant management. You couldn't fix participant management without fixing study structure. You couldn't fix study structure without rethinking the entire information architecture.

Everything was connected. The design had to respect that.

"We expected a product. We found an ecosystem. Every feature was a thread in a web — pull one, and the whole thing moved."

The information architecture problem

This was, honestly, the hardest part of the entire project.

The platform had:

• Studies

• Participants

• Incentives

• Interviews

• Surveys

• Scheduling

• Communications

• Reporting

• Teams

• Client access

• Participant marketplace

How do you organize all of that in a way that feels navigable?

What we tried

Attempt 1: Feature-based navigation. We grouped features by type: Research, People, Operations, Analytics. This was clean on paper but fell apart in practice — researchers constantly crossed between groups, and the boundaries felt arbitrary.

Attempt 2: Role-based views. We explored giving each user type a completely different interface. This solved individual clarity but created a maintenance nightmare — every feature update had to be reflected across multiple views.

Attempt 3: Study-centric architecture. This is where we landed. The study became the central organizing unit. Everything — participants, scheduling, surveys, interviews, incentives, reporting — lived within the context of a study. Cross-study views existed for operations and oversight, but the primary workspace was always study-first.

This matched how researchers actually thought. And it solved the navigation problem — instead of asking "where is this feature?" users could ask "where is this study?" and find everything they needed inside it.

The navigation decision that took three weeks

We debated the primary navigation structure for nearly three weeks.

The tension was between depth and breadth. A shallow navigation made the top level clean but buried critical features behind clicks. A deep navigation surfaced everything but overwhelmed new users.

We ultimately chose a progressive structure — a clean primary navigation organized around the study lifecycle, with contextual secondary navigation that expanded based on where users were in their workflow.

The navigation wasn't just reorganized. It was rebuilt around a fundamentally different logic.

Redesigning the core experience

With the architecture settled, we rebuilt the platform's major workflows.

Study creation that doesn't feel like a tax form

The original study creation flow was a long, multi-step form that asked for everything upfront — study type, methodology, participant criteria, scheduling preferences, incentive structure, reporting requirements.

Researchers abandoned this flow constantly. Not because they didn't have the information — but because the process demanded decisions in an order that didn't match how they actually planned studies.

We redesigned study creation as a progressive setup:

1. Start with the essentials — study name, type, and basic parameters

2. Build out details as needed — participants, scheduling, methodology

3. Configure operations when ready — incentives, communications, reporting

Each step was optional at creation time. Researchers could launch a study with minimal setup and add complexity as the study matured.

This mirrored real research behavior. Studies evolve. They don't arrive fully formed.

Unifying qualitative and quantitative research

This was one of the most important — and most debated — design decisions.

Qualitative research (interviews, focus groups, open-ended feedback) and quantitative research (surveys, structured data collection, statistical analysis) behave differently. They have different data structures, different workflows, and different outputs.

The original platform treated them as separate modules. Two different sections. Two different interfaces. Two different mental models.

But researchers often ran mixed-method studies — a screening survey followed by in-depth interviews, or a large quantitative study supplemented by qualitative deep-dives. Forcing them into separate modules for what was, to them, one study created constant friction.

We unified them under a single study framework. A study could contain surveys and interviews. The workflows remained distinct where they needed to be — you schedule interviews differently than you distribute surveys — but they lived under one roof, within one study, with one participant pool.

"To a platform architect, qual and quant are different systems. To a researcher, they're different chapters of the same story."

Participant management that shows the journey

The original participant system was a database view — rows of names, statuses, and metadata. It told you who participants were but not where they were.

For a coordinator managing 300 participants across a three-week study, "where" was the only question that mattered:

• Who's been invited but hasn't responded?

• Who's scheduled but hasn't confirmed?

• Who completed the interview but hasn't been paid?

• Who dropped off and why?

We redesigned participant management around journey visibility. Each participant had a clear status within the study lifecycle — invited, screened, qualified, scheduled, completed, compensated. Coordinators could see, at a glance, where bottlenecks were forming and where attention was needed.

This wasn't just a UI change. It was a shift from data management to workflow management.

Scheduling that coordinates itself

Interview scheduling was one of the platform's most painful workflows.

The original process involved manual coordination — researchers checking calendars, sending availability, waiting for responses, handling reschedules, managing time zones. For a study with 50 interviews across three time zones, this was a full-time job.

We designed scheduling as a coordinated system rather than a manual tool:

• Availability synced with researchers' calendars

• Participants selected from open time slots

• Confirmations and reminders automated

• Reschedules handled with suggested alternatives

• Time zone conflicts surfaced before they became problems

The goal was that scheduling should feel like it manages itself — surfacing decisions to humans only when human judgment is actually needed.

Incentives that don't become a separate project

In research, incentives aren't optional. Participants expect compensation — and the speed and reliability of that compensation directly affects future recruitment.

The original incentive system existed but lived apart from study workflows. Researchers finished a study, then had to separately navigate to incentives, look up participants, calculate amounts, process payments, and track completions.

We embedded incentive management directly into the study lifecycle:

• Incentive structure defined during study setup

• Payments triggered automatically upon participant completion

• Multiple payment methods — Stripe, PayPal, ACH, wire transfers — managed from one interface

• Payment status visible within participant profiles

• Bulk processing for large studies

The incentive system stopped being a separate administrative task and became an automatic part of how studies close.

The participant marketplace

On the other side of the platform, participants needed their own experience — entirely separate from the researcher-facing product.

Participants needed to:

• Discover available studies

• Understand what was expected of them

• Complete screening and qualification

• Schedule and attend interviews

• Complete surveys

• Track their compensation

The original participant experience was functional but frustrating. Instructions were unclear. Progress was invisible. The flow between study discovery and participation was disjointed.

We redesigned the participant experience around clarity and momentum:

• Study listings with clear expectations (time, compensation, requirements)

• Match scoring so participants saw studies relevant to them

• Progress tracking through every study stage

• Simple, mobile-friendly participation flows

• Transparent incentive status and payment timelines

If participants had a bad experience, they wouldn't come back. And if they didn't come back, the entire platform's value proposition collapsed. The participant experience wasn't secondary — it was foundational.

Building the design system

A platform this large — with dense data tables, complex forms, multi-state workflows, scheduling interfaces, participant cards, study dashboards, and payment systems — needed a design system that could handle everything without falling apart.

We didn't build a component library. We built a design language for complex research operations.

The principles underneath

Density with direction. Research platforms are inherently data-heavy. Tables with hundreds of rows. Dashboards with dozens of metrics. Study views with multiple active panels. The system needed to display density without creating visual noise. Every element earned its place through hierarchy — primary information at full weight, supporting data recessed, tertiary details available on demand.

States everywhere. Every object in the platform had a lifecycle. Studies could be draft, active, paused, completed, or archived. Participants could be invited, screening, qualified, scheduled, completed, or compensated. Payments could be pending, processing, completed, or failed. The design system needed a consistent, recognizable language for states that worked across every context.

Consistency at scale. With this many features and views, inconsistency would multiply fast. A button that behaved differently in scheduling than in study creation would erode trust. The system enforced consistency — same patterns, same interactions, same visual language — across every module.

Visual direction

The visual design balanced enterprise seriousness with modern SaaS clarity.

Typography: Inter. Chosen for its exceptional readability in data-heavy interfaces. Clean at small sizes. Distinctive at large sizes. Neutral enough to not compete with content but strong enough to create hierarchy.

Primary color: Teal (#009D9C). The platform's identity color. Used for primary actions, progress indicators, active states, and success signals. Warm enough to feel approachable. Professional enough for enterprise contexts.

Supporting palette:

• Blue (#2F469C) — categorization, secondary actions

• Green (#17C964) — success, completion

• Yellow (#F5A524) — warnings, attention

• Pink (#F31260) — errors, critical states

The palette was designed for functional clarity — each color carried operational meaning, not just aesthetic value.

Icons: Phosphor Icons. Flexible, consistent, and readable at the small sizes demanded by dense operational interfaces. The icon set scaled cleanly from navigation to inline table actions.

Components that carry weight

Some components worth calling out:

Study cards. The atomic unit of the platform. Each card showed study name, type (qual/quant/mixed), status, participant count, completion progress, and next action — all without opening the study. These had to be information-dense without feeling cramped.

Data tables. The backbone of participant management, incentive tracking, and reporting. Sortable, filterable, bulk-actionable, and exportable. We invested heavily in table UX — row selection, inline editing, status chips, contextual actions — because researchers spent hours inside tables.

Calendar components. Scheduling demanded a calendar system that could show availability, conflicts, time zones, and booking status simultaneously. This was one of the most technically complex components in the system.

Status systems. A unified visual language for status across every entity — studies, participants, payments, communications. Color-coded, icon-supported, and consistent regardless of where in the platform you encountered them.

Empty states. In a platform with this many views, users frequently landed on screens with no data yet. Every empty state was designed to be instructive — explaining what belongs here, why it's empty, and what to do next.

The development bridge

Here's what made this project different from most design engagements.

We didn't stop at Figma files.

Our team contributed directly to the frontend implementation — building Angular components, implementing responsive layouts, and ensuring the shipped product matched design intent.

This wasn't a "handoff" situation. It was continuous collaboration:

• Design decisions were validated against implementation cost

• Complex interactions were prototyped in code, not just mockups

• Edge cases were caught during development, not after launch

• The design system was built as living code, not static documentation

The result was a much tighter alignment between what was designed and what was shipped. The gap that typically exists between "the Figma version" and "the real version" was significantly smaller.

"Most design projects end with a handoff. This one ended with a deployment."

What made this project difficult

A few honest admissions about where this project pushed us.

The scope kept expanding — for good reasons.

Every time we solved one area, it revealed dependencies in another. Fixing study creation meant rethinking participant management. Rethinking participant management meant redesigning scheduling. Redesigning scheduling meant rebuilding the calendar system. The project grew not because of scope creep, but because the product was genuinely interconnected.

We had to learn when to draw a boundary and say "that's a future iteration" — even when the designer in us wanted to keep pulling the thread.

Designing for researchers and participants simultaneously was a balancing act.

These two user types had opposing needs. Researchers wanted power, depth, and control. Participants wanted simplicity, speed, and clarity. Both experiences lived inside the same platform, but they couldn't share the same design language without one group suffering.

We ended up creating what was essentially two design expressions within one system — sharing foundations (typography, color, spacing) but diverging in density, complexity, and interaction patterns.

The qual/quant unification had no precedent to follow.

Most research platforms at the time treated qualitative and quantitative research as separate products. We were designing a unified model that didn't exist anywhere else. There was no established pattern to reference. We had to build the interaction model from scratch — and we got it wrong twice before landing on a version that worked.

The first attempt was too unified — it flattened the differences between methods to the point where neither felt well-served. The second was too separated — essentially tabs within a study, which felt like the old approach with a new coat of paint. The third attempt found the balance — shared context, distinct workflows.

Data tables nearly broke us.

This sounds mundane, but tables were the most iterated component in the entire system. Researchers lived in tables. They needed sorting, filtering, bulk actions, inline editing, status visualization, export options, and column customization — all while keeping rows readable and actions discoverable.

We went through seven major iterations of the table component before reaching a version that handled the platform's demands without becoming unusable.

What the platform became

Xperiti transformed from a collection of research tools into a unified research operating system.

The platform didn't just look different. It worked differently.

Researchers could run a study — from creation through recruitment, scheduling, data collection, and incentive distribution — without leaving the study workspace. Coordinators could see operational bottlenecks at a glance. Clients could check progress without asking anyone. Participants could complete studies with clear expectations and transparent compensation.

And then Ipsos came calling

The platform was later acquired by Ipsos — one of the world's largest market research companies.

We don't claim that our redesign caused the acquisition. Product acquisitions are complex, multi-factor decisions.

But we do know this: the product that was acquired was a fundamentally different product than the one we inherited. It was more coherent, more scalable, more mature, and more enterprise-ready.

The redesign didn't just improve the experience. It helped the product tell a clearer story about what it was — and what it could become.

Reflection

This was one of the most complex product design projects we've worked on.

Not because any single screen was particularly difficult. But because the system was difficult — the interconnections, the dependencies, the competing user needs, the sheer volume of workflows that all had to feel like they belonged together.

A few things this project taught us:

Products grow faster than experiences.

Xperiti's problem wasn't bad design. It was design that hadn't kept pace with product growth. Features shipped, but the connective tissue — the navigation, the workflows, the consistency — degraded with each addition. This happens to every successful SaaS product eventually. The question is whether you address it before or after it starts hurting.

Think in workflows, not screens.

When we stopped thinking about "the scheduling page" and started thinking about "how does a researcher move a study forward," the design got dramatically better. Screens are containers. Workflows are experiences. Design the workflow first; the screens will follow.

Designing for multiple user types is designing multiple products.

You can't serve a power user and a casual participant with the same density, the same language, or the same interaction patterns. Shared foundations — yes. Shared experiences — rarely. Accepting this early saved us from the trap of one-size-fits-all design.

The best design systems grow from real problems.

We didn't design the system and then apply it. We solved real interface problems — tables, states, empty views, scheduling — and extracted the system from those solutions. The design system was a byproduct of doing the work, not a prerequisite for it.

Designing and building together changes everything.

The fact that our team contributed to frontend development didn't just improve fidelity. It improved design decisions. When you know you'll have to build what you design, you design differently — more practically, more responsibly, and with a much better understanding of what complexity actually costs.

TYPOGRAPHY: INTER

ICONS: PHOSPHOR ICONS

PRIMARY COLOR: TEAL (#009D9C)

SUPPORTING: BLUE (#2F469C) · GREEN (#17C964) · YELLOW (#F5A524) · PINK (#F31260)

TECHNOLOGY: ANGULAR