Data Cloud stands as Salesforce's fastest-growing product at present. It serves to consolidate all customer data into a singular repository, harmonizing its presentation, and organizing customer profiles in alignment with the company's strategic objectives.

Our research team found that the majority of customers wanted one unified Data Cloud across their various Salesforce orgs. The current model forced users to log in and out of separate orgs, reconcile data manually, and operate without a single source of truth.

The core opportunity: enable bi-directional connections between Salesforce orgs and Data Cloud — so harmonized data can flow back to where it's needed, eliminating the need for separate Data Cloud orgs entirely.

This project spans two distinct Salesforce environments and four different user types: the Data Cloud admin and general user operating within the Data Cloud org, and the Salesforce org admin and general user in connected orgs like Sales Cloud and Service Cloud. Each group has different levels of technical fluency, different goals, and different mental models for what "data" means in their day-to-day work.

The discussion for Data Cloud One began with many cross-functional meetings introducing what this feature needed to do across all Salesforce orgs. My product managers brought me the requirements and we dug into frontline issues together before any design work began.

I grounded ideation in three "How Might We" statements to guide design across all 15 flows delivered by end of 2024:

• How can we teach users about the new Remote Data Cloud concept?
• How can we simplify the connection creation process?
• How can we keep users informed about their connections for better data management?

For each flow, after requirements were introduced on day 1, I drafted flowcharts to serve as the blueprint for the official screen-by-screen experience. Here are the two iterations of flowcharts for one example flow — a Data Cloud Admin setting up a Companion Connection:

Once the flowcharts were approved, I moved into lo-fi wireframes — reviewed and iterated with the PM and engineers around days 2 and 3. From there, designs escalated to mid-fi for leadership review by day 3, and into mid/hi-fi by day 5. Continuing with the Companion Connection example:

After completing the lo-fi and mid-fi designs, I recruited internal and external users for research interviews to validate our direction and surface pain points before finalizing the hi-fi. The research surfaced clear patterns around how customers were experiencing — and struggling with — the flows we designed.

After all flows were complete, I recruited internal and external users to test the main end-to-end flows. I collected all feedback in FigJam — first organized by person, then color-coded by positive and negative sentiment — and synthesized it into themes.

The approved design was implemented into one of Data Cloud's newest breakthrough features: Data Cloud One. The final Companion Connection flow incorporated changes to terminology, step-by-step guidance, multiple entry points for creating new connections, and clearer status indicators throughout.

Below is a walkthrough of the finalized "Creating a Companion Connection" flow:

Salesforce Data 360 is a suite of data products that helps businesses bring together all their customer data — from CRMs, marketing tools, support systems, and more — into one place. Think of it as a single source of truth for everything you know about your customers, built to power smarter decisions and more personalized experiences across Salesforce.

Within Data 360, Identity Resolution is the feature that figures out when multiple records are actually the same person. For example, "Jane Smith" in your CRM and "j.smith@company.com" in your email tool might be the same Jane — Identity Resolution matches them and merges them into one unified profile. The cleaner the merge, the more accurate the customer picture your teams work from.

Identity Resolution is a powerful feature — but getting it to actually work requires a significant amount of upfront configuration. Users have to set up matching rules, define ruleset priorities, configure reconciliation settings, and tune thresholds — all before they see a single merged profile. The setup process is tedious, technical, and unforgiving. One misconfigured rule can cascade into thousands of bad merges.

The irony: all that configuration effort is supposed to produce better results. But in practice, the weight of setup overwhelms the experience. Users spend so much energy getting the system configured that by the time they see outputs, they're too burned out to properly evaluate them. The results — the whole point — get lost under the burden of the setup.

And this wasn't just an Identity Resolution problem. Across the entire Data 360 suite, teams were hearing the same thing: the platform was powerful but hard to get into. Setup was steep, discovery was confusing, and the path from "I want to do X" to "X is done" was too long. Recognizing this as a platform-wide issue, a large cross-functional team was formed — with different UX designers, researchers, PMs, and engineers each owning a different part of Data 360 — to tackle this together under a single strategic initiative called "Ease of Use."

The primary user for Identity Resolution is the Data Systems Architect — a technically fluent role that sits at the intersection of data engineering and business strategy. They're responsible for designing and maintaining the data infrastructure that the rest of the organization depends on.

Across the Ease of Use initiative, the UX research team conducted broad discovery research spanning the entire Data 360 platform. The findings painted a consistent picture: users were capable and motivated, but the product was putting up unnecessary walls. Identity Resolution surfaced some of the most acute friction points in the entire suite.

With research in hand, the Ease of Use team came together for an onsite. The goal: align on a shared design philosophy before anyone started ideating. Two key frameworks emerged that would guide every designer's work going forward.

Ideation began at the platform level. Each designer on the Ease of Use team brought initial concepts for how the entire Data 360 experience could be reimagined — visualizing the end-to-end flow from a user's perspective. Below are the initial concepts for the full D360 experience, followed by a Figma Make walkthrough showing the interactive vision.

After presenting the big-picture concepts as a team, each designer received feedback and narrowed focus to their own product area. For me, that meant taking the broader D360 vision and translating it specifically into Identity Resolution. Below is the feedback that shaped the direction of my IR concepts.

With the long-term vision validated, I partnered with my IR PM and the engineering team to work backwards from it — figuring out what was feasible for the next release. This meant having honest conversations about technical constraints, API readiness, and scope, then translating the vision into a release plan that made real, meaningful progress without overpromising.

Below is a walkthrough of the final design prototype for the Identity Resolution enhancements — showing the full experience from setup through results.

When Data Cloud unifies a customer record, it can aggregate hundreds of attributes from dozens of source systems — purchase history, support tickets, email engagement, web behavior, demographic data, and more. In theory, this creates an incredibly rich picture of each customer.

In practice, all of that data was presented in a single, undifferentiated list. My team owned the Customer Profile Explorer — the UI surface where Data Cloud users view and investigate individual unified customer records.

The existing profile view presented every attribute in a flat list — hundreds of fields with no hierarchy or context. Users investigating a customer record had to scroll endlessly and held no mental model for where important information lived.

The goal: design an exploration experience that surfaces what matters without hiding what's needed.

Before redesigning anything, I needed to know what users were actually looking for when they opened a profile — and why. I ran a 2-week diary study with 6 power users across customer success, marketing, and sales ops roles, asking them to log every profile visit with a brief note on their goal.

The finding was striking: despite hundreds of available fields, the actual lookup behavior was highly concentrated. Almost every session was driven by one of the same 6 questions.

The diary study revealed a clear tension: most users needed fast access to a small set of fields, but a subset of power users (data engineers, analysts) needed to access the full attribute set regularly for deep investigation. A design that served only one group would fail the other.

The design challenge became: how do you build a single interface that feels fast and scannable for the majority, while remaining complete and navigable for the few who need everything?

I explored 3 structural approaches: a tabbed interface (attributes by category), a search-first model (find-by-typing), and a progressive disclosure model (summary header + full explorer beneath). I prototyped each at lo-fi and presented them in a team design critique before testing externally.

The progressive disclosure model won internally and in early customer feedback — it was the only approach that felt fast for quick lookups without sacrificing depth for power users.

Our primary success metric was simple: can users find a specific attribute faster? I built a hi-fi prototype of the progressive disclosure model and ran moderated usability testing (n=6) with the same profiles used in the diary study as test stimuli.

The results exceeded expectations: median time-to-find dropped from 40 seconds to 8 seconds — a 5× improvement. All 6 participants also correctly used the pinning mechanic without instruction.

The final design introduces a smart summary header — the 6 most universally accessed attribute groups surfaced above the fold in scannable cards. Below, a full attribute explorer with category grouping and inline search handles the power-user depth case. A pin icon on any attribute lets users customize their summary header.

Currently in Beta with a cohort of early-access customers. Full outcome metrics — task success rate, time-to-find, session engagement — will be added post-GA. The project is on track to ship to GA in Q2 2025.

Beta is the beginning. Here's what I'd carry forward — and the highest-priority follow-on investments.

Salesforce Data Cloud is a complex, multi-capability platform used by four distinct user personas: Data Engineers who build pipelines, Marketers who build segments and campaigns, Admins who configure the platform, and Analysts who investigate data and build reports.

My team owned the Application Home — the first screen every user sees when they log in. At the time I picked this project up, it was a static "recents" list that hadn't been intentionally designed. It was the product's first impression, and it was making a bad one.

Data Cloud's home page was a static list of recent items — identical for every user, every role, every day. There was no guidance for new users, no prioritization for returning ones, and no signal about what needed attention.

With a rapidly growing user base spanning 4 distinct roles with nearly zero task overlap, we needed a home that actually understood who was looking at it.

Before running any interviews, I partnered with our researcher and the data analytics team to pull FullStory session recordings and behavioral data across 400+ sessions. We specifically looked for: what users did on the home page (or didn't), how long they spent there, and what their first navigation action was.

This gave us a quantitative baseline before we introduced any interview bias. Then we ran 10 in-depth interviews segmented by role — separately mapping new user onboarding behavior and returning user daily patterns.

The research revealed two distinct problems that the home page needed to solve simultaneously: a first-session wayfinding problem (new users had no idea where to start) and a returning-user efficiency problem (experienced users wanted to jump straight to what needed attention).

I facilitated a design principles session with the PM and tech lead to formally name these as two co-equal design targets — which then became the criteria against which we evaluated every concept direction.

I explored 3 structural directions: a fully personalized home (user-configurable modules), a role-aware home (system-assigned layout based on assigned role), and a universal home with a priority zone + role-specific quick actions. Each had meaningful trade-offs between implementation complexity and user value.

Customer concept tests (n=8, 2 per role) pointed clearly to the third direction — users didn't want to configure anything, but they did want relevant quick actions and alerts surfaced without manual setup.

I built two prototype variants — one showing the new user onboarding state, one showing the returning user daily view — and ran role-segmented usability testing (n=8, 2 per role). The key test questions: does the onboarding state help new users find their first meaningful action? Does the daily view surface the right priorities?

Both scenarios passed the primary success criteria. The one significant finding: the alert zone was initially dismissed as decorative. We increased visual weight and added an unread count badge — post-iteration, all participants engaged with it.

The final design introduces a three-zone layout: a priority zone at the top (alerts, stale segments, items requiring attention), a role-specific quick-action row below it, and a recent activity feed at the bottom. New users see an onboarding checklist in place of the priority zone until they've completed initial setup.

Designs completed and handed off to engineering. GA target Q2 2025. Success metrics: home page engagement rate, time-to-first-action for new users, and 30-day retention by role. Full outcome data will be added post-launch.

The role-aware home is v1. Here's what I'd carry forward — and the highest-priority evolutions once we have post-launch usage data.

Salesforce Data Cloud sits at the center of data unification — ingesting records from CRMs, data warehouses, marketing tools, behavioral platforms, and more, and turning them into unified customer profiles. Its position as the hub makes data quality critical: anything that enters the pipeline dirty flows straight into the profiles, segments, and campaigns that the rest of the business depends on.

What made this project uniquely valuable is what the team calls Last Mile Visibility — Data Cloud doesn't just store data, it sees how data is actually used. Whether it's for segmentation, activation, personalization, reporting, or Agentforce, the platform has direct insight into which datasets are high-impact downstream. That means we don't need to run quality checks on petabytes of data — we can intelligently focus on the datasets that matter most.

Data quality work traditionally follows four phases: Discovery → Design → Execution → Monitoring. My team owned building a product surface to support this entire lifecycle — powered by AI agents at every phase — from profiling data as it enters the pipeline all the way through real-time anomaly alerting. This was the largest-scope project in my portfolio and my first time designing a fully greenfield product surface.

Data quality failures were discovered too late — typically by business users when their segments or reports produced unexpected results. By the time an engineer was alerted, the root cause was hours old, the bad data had already propagated downstream, and the investigation had to work backwards from symptoms to cause.

There was no proactive monitoring surface. Admins had no way to know something was wrong until someone else did. And even when issues were identified, there was no clear path to remediation — no guidance on what failed, why, or how to fix it.

Beyond detection, there was a deeper problem: admins didn't even know what "good" looked like for their data. Without a way to profile data as it entered the pipeline, there was no baseline to measure against. Rules were created reactively — after something broke — rather than proactively based on what the data actually needed.

Discovery started with understanding not just the monitoring problem, but the entire data quality lifecycle admins work through. We partnered with our PM and UX research team to map how customers currently manage data quality — from the moment data enters the pipeline to how they respond when something goes wrong.

We ran expert interviews with DC Admins and data engineers, and complemented those with competitive analysis of tools like Monte Carlo, dbt, Informatica DQ, and Databricks — understanding the mental models engineers bring in from the broader DQ ecosystem. A key insight was that most DQ tools work in isolation from where data is actually used. Data Cloud had a rare advantage: we could see the last mile — which datasets were feeding active segments, campaigns, and agent workflows — and focus quality efforts precisely there.

The PRD defined the product scope as a four-phase DQ lifecycle. Each phase had its own design challenges, user types, and interaction patterns — and they had to feel like a connected system, not four separate tools bolted together.

A key insight from discovery: DC Admins are skeptical of monitoring tools. They've used systems that produce noisy alerts, misleadingly simple scores, or dashboards that look good but don't help them act. Any solution had to feel credible, configurable, and actionable — not a vanity dashboard.

This shaped how I approached the DQ Agent specifically. Rather than a chatbot that answers questions on demand, the agent needed to proactively surface insights — telling admins what they should know about their datasets without them having to ask. The flip side: the agent couldn't be too prescriptive or interrupt constantly. Finding that balance drove most of the ideation.

Currently running concept validation sessions with enterprise DC Admins — presenting hi-fi prototypes and testing across three core scenarios drawn directly from the PRD use cases:

• Use Case 1 — Discovery: Can the admin understand the health of a dataset before using it downstream, without running manual queries?
• Use Case 4 — Monitoring: When an anomaly is detected (e.g. a 30%+ drop in completeness score or unexpected volume spike), can the admin identify what's affected and take action?
• Use Case 5 — Remediation: When an issue is assigned to a Data Steward, is the path to resolution clear — and does the AI suggestion actually help?

Early signals: the catalog-integrated DQ score view and the agent-driven rule recommendations are landing well. The lineage visualization density is still too high — iterating on progressive disclosure within the lineage panel before finalizing.

The current design centers on two integrated surfaces: the DQ view in the Data Catalog — where data quality scores, profiling insights, and rule recommendations surface per-object — and the Observability Monitor — where real-time anomaly alerts for the 5 tracked metrics (Freshness, Distribution, Volume, Schema, Lineage) are surfaced with severity scoring, timestamps, and AI-suggested remediation steps.

Third-party tool integration is a first-class concern: admins using existing DQ solutions like Informatica DQ, Talend, Monte Carlo, or Collibra can ingest their scores and observability metrics directly into Data Cloud via API, with results surfaced inline in the Catalog alongside native scores.

Still in active iteration — the lineage visualization, alert threshold configuration UI, and the collaborative request flow between business users and admins for rule creation are the three areas under most active refinement.

Currently iterating on lineage visualization density and alert threshold configuration. Alpha planned for Q2 2025 with a cohort of 3 enterprise customers. This is the largest-scope project in my current portfolio — full case study and outcome metrics will be published post-Alpha.

Still in progress — but these are the learnings already taking shape, and the capabilities this foundation will enable as the product matures.