Designing a way to measure and visualize KPIs inside customer journey maps — balancing simplicity for everyday users with the power and flexibility that advanced users demanded.
Cemantica helps CX teams build and manage customer journey maps. But journey maps without data are just storytelling — users were asking for a way to attach real KPIs to journey stages: NPS scores, satisfaction ratings, volume metrics, conversion rates.
The challenge wasn't just "add a chart." Different user types had wildly different needs. A junior analyst wanted a simple sparkline. A senior CX strategist wanted multiple data series, custom chart types, and the ability to overlay benchmarks. One solution had to serve both.
Advanced users were requesting features like multiple chart types, custom color mapping, and multi-series data. But if we built for them first, we'd create a UI that scared away the 80% of users who just wanted to drop in one number and move on.
This is a classic progressive disclosure problem — and it became the design principle we kept coming back to throughout the project.
Rather than a single big research phase, we used Teresa Torres' continuous discovery framework — running short weekly interviews with active Cemantica users, focused on their actual workflows around measuring CX performance.
After each week's interviews, I ran a short synthesis session with the PM using an opportunity solution tree. We mapped user pain points to opportunity areas, which helped us avoid jumping to solutions too quickly.
The tree revealed two distinct opportunity clusters: data input friction (users struggled to get data in) and visualization flexibility (the output didn't match how they communicated KPIs internally).
"I end up exporting our journey map as a PDF and then manually pasting in the NPS data from Excel. It's embarrassing when I show it to the C-suite."
Design a KPI component that defaults to the simplest possible state — a single metric — but progressively reveals more power as users opt in, without ever making the simple path harder.
I audited six tools that handle metrics inside journey or workflow contexts: TheyDo, Smaply, Notion, monday.com, Miro, and Tableau. The goal wasn't to copy — it was to understand the solution space and identify gaps.
TheyDo had the most mature approach — inline metrics directly on journey stages — but required data to be pre-formatted in a specific way, creating input friction.
Notion showed that simple number inputs with optional chart expansion worked well for non-technical users.
None of the tools offered progressive disclosure of chart complexity — they were either too simple or too powerful. That gap became our differentiator.
I explored three distinct design directions before landing on the final approach. Each was tested with 4–5 users in moderated prototype sessions.
The final design uses a collapsible KPI row per journey stage with three states: empty/hidden, simple (single metric with auto-chart), and expanded (full chart configuration). Users move through states naturally as their needs grow.
We deliberately hid the chart type selector until a user had already added at least one data point. This reduced decision paralysis for new users while keeping the option accessible the moment it became relevant.
We also chose to auto-save on blur rather than requiring an explicit "save" action — a small detail that made the entire editing experience feel lighter and faster.
The biggest design lesson from this project: progressive disclosure only works if the "simple" state is genuinely useful on its own — not just a stripped-down version of the complex one. We had to design the simple and complex states separately, then connect them.