Impact

Streamlined, error free data import for a new self-serve version of a robust platform

Summary

ChartHop is a powerful HR platform that lets teams visualize and analyze their organization over time — tracking headcount changes, running planning scenarios in a sandbox, and promoting them to reality when ready. When leadership asked us to build a self-serve, freemium version, the business case was obvious: let prospects try it without going through sales, reduce pressure on CX teams, and open up a self-qualifying lead pipeline.

I joined as the first design hire — brought in by my former Design VP — and my first task was to lead design for this initiative.

Problem/Context

ChartHop’s power came with real complexity. Getting even a small customer up and running took weeks — sometimes months — of hands-on work from implementation, support, sales, and engineering. Almost all users needed ongoing help to use even core features. Making this self-serve wasn’t just a UX challenge; it required rethinking the entire onboarding process.

My PM partner and I ran discovery before touching any designs: collaborative service blueprinting sessions in Miro, interviews with internal SMEs (across CX, sales, support, and implementation), and conversations with users across various company sizes and industries. We dug into support tickets, feature requests, and the existing system itself alongside engineering.

We quickly zeroed in on the biggest stumbling block: data import. We’d identified the “wow moment” as the first time a user sees their own org chart — but to get there, they had to get their data in first. The experience was rough:

• The CSV importer was confusing; HR system syncs were even harder to set up without help.
• Errors were opaque and unpredictable — sometimes failing silently, sometimes with robotic system messages that gave users no clue what to fix.
• Records with issues were often skipped without notice, leading to mysteriously incomplete org charts.
• Import duration was completely unpredictable — seconds or hours, with no indication of which.

The system had been designed to protect itself from bad data — not to support the user. That was fine when a trained team was doing the import. It wasn’t going to work for self-serve.

The Solution

Two backend areas needed deeper investigation before I could design confidently.

On performance, we ran engineering spikes to find where we could improve speed. Where we couldn’t, we shifted to managing expectations: a friendly indeterminate progress animation instead of a confusing step-by-step tracker, plus an email notification for anything running over 10 seconds, knowing users would have moved on.

On errors, I did a full audit of backend error messages, identified which ones could surface to users, and developed handling recommendations for each — workshopped with PM, engineering, and design.

I worked to build alignment on our approach early by putting together some high level flows with mini wireframes to facilitate discussion of where we should put more burden on the user or on the platform.

At this stage, I built out shared principles — not for a slide deck, but practical enough that an engineer or PM or designer could use them to make a call without pulling me in. We landed on four principles we would use going forward:

An example of “Handle errors gracefully and empower users to resolve them”: column mapping

Previously, if the column header label didn’t exactly match what our system expected, we would reject the column. To get the data in, the user would need to open their source spreadsheet, relabel the column, then reimport. 

To streamline user workflow & avoid errors, we introduced some new functionality:

• Added common header aliases so auto-matching was smarter (based on patterns I’d spotted in real customer data)
• When auto-matching failed and we couldn’t make a guess, we’d prompt them to choose a column in their spreadsheet to map to the ChartHop field
• Because we often saw errors around unexpected date format, we made a best guess at understanding their date format but allowed them to choose their date format in context rather than making them edit sheet & reimport

Tradeoffs

A couple examples to illustrate tradeoffs & constraints.

First, my PM partner and I advocated hard for a demo environment — pre-loaded with realistic data, so users could explore the system without friction and import their own data when ready. I mapped out the first-run user flow to visually show just how much the data import step would slow people down. The founder/CEO/CTO was unmoved, he believed the wow moment only landed with a customer’s own data. We couldn’t change his mind, so we shifted to making the import experience as smooth as possible — and added an example spreadsheet as a workaround for users who hit a wall.

We saw meaningful drop-off at the import stage during alpha and beta and into GA. If I were doing this again, I’d push harder for the demo path earlier.

Second, I’d sketched a data preview experience that included an interactive org chart — users could see their org before committing and drag-and-drop to fix issues. Engineering estimated it was too expensive for MVP; we cut it to tabular preview. It shipped solid, but I still wonder if the org chart preview would have improved the experience.

Final designs

Ask Me More

About this epic and our process, the next epic (syncing data from HR systems), the broader self-serve initiative (including tackling a nebulous mandate, service design, lightweight automated on-boarding, etc.), or how I embrace standards & principles to align and empower product teams.

Possibly also of interest, how a robust alpha including first time user experience “ride alongs” built empathy for users and helped us squash bugs early  and iterate on design & implementation rapidly.