6sense · Research
/
2025
A heuristic audit that changed what got fixed first; Phase 1 raised export completion 7%.
Result
Phase 1 raised export completion 7% month-over-month, and the design team adopted the audit framework.
Company
6sense · Research
Year
2025
Role
Product Designer III · UX research · with PM and engineering · 4 weeks
In short
Problem: exporting contacts was one of the most frequent workflows for sales development reps (BDRs) at 6sense, and the most complained about: 3,000+ export queries from customer-facing teams over three years.
What I did: stopped the cycle of one-off patches, mapped the export flow end to end, audited it against usability heuristics, and traced 70+ defects to five root causes.
The hard call: I argued against shipping the most-requested fix first, because it depended on data that engineering couldn't yet guarantee.
Result: Phase 1 raised export completion 7% month-over-month. The design team adopted my audit framework for other legacy workflows.
The situation
The same complaints came through the same internal help channel for three years, from different people. Earlier fixes had patched individual symptoms, so the workflow itself stayed broken. Three problems kept coming back:
Unclear CRM status. Users couldn't tell whether their data had synced or been lost.
Silent delays. Exports failed in the background with no progress or feedback.
Errors with no way out. Error messages didn't say how to fix the problem or retry.
When one request repeats for three years, it isn't a copy problem. I proposed pausing feature patches and treating export as a system to diagnose.
In Image: Anonymised wall of export queries.
Discovery: six methods, one question each
Jobs-to-be-done tracking: what is the BDR actually trying to finish?
Jobs mapping: which step inside that job breaks?
Persona-first mapping: what can they see at that moment?
Heuristic analysis: which usability principle is broken, and where?
Affinity mapping: do the 70+ defects share a cause?
Impact–effort matrix: what can we responsibly ship first?
The export job, step by step
I split export into four jobs and recorded what each one needed and where it failed.
Select. Goal: choose the right contacts or accounts. Failure: users couldn't see what was already in their CRM. Needed: show whether data already exists before exporting.
Configure. Goal: pick a destination and confirm what will be sent. Failure: “export”, “download” and “sync” were used for the same thing. Needed: one vocabulary across the product.
Export. Goal: push records into the destination tool. Failure: no progress or partial-success states while it ran. Needed: live, persistent export status.
Verify. Goal: confirm records landed and fix failures. Failure: no way to recover or retry. Needed: error details with a retry path, right where the error appears.
In Image: The jobs-to-be-done map across Select, Configure, Export and Verify
Heuristic evaluation: 70+ defects, five root causes
I audited the full flow against Nielsen Norman Group's usability heuristics, then grouped the 70+ defects by cause.
No CRM or sales engagement data visibility. Cost: duplicate records in the CRM. Principle: make system state explicit. Decision: Phase 2, because it needs data signals.
Inconsistent vocabulary. Cost: users unsure what an action will do. Principle: one name per action. Decision: Phase 1, shipped.
No recovery model. Cost: an error with no next step. Principle: every failure pairs with an action. Decision: Phase 1, shipped.
No progress visibility. Cost: repeated work and lost trust. Principle: always show where you are. Decision: Phase 2, because it needs per-record status.
Unpredictable custom components. Cost: the flow behaved unlike the rest of the platform. Principle: match platform patterns. Decision: Phase 1, using the standard design system.
In Image: Pain points and open questions per stage
Phase 1: shipped fixes
One consistent vocabulary for export actions across every flow.
CSV selections kept, so users don't lose their choices.
Error messages that explain what went wrong and offer a next step.
Standard design system tables and controls in place of custom ones built only for export. More rework up front, but predictable behaviour, lower build risk and patterns that match the rest of the platform.
Phase 2: the planned redesign
Phase 2 is a single cart-style export interface, planned for Q4 2026 to Q1 2027 and not yet shipped. It's built on one principle: users should never have to guess what will happen, what is happening, or what happened.
Select records, with CRM and sales engagement presence shown inline.
Review the destination and duplicate status before exporting.
Export with live progress.
Review success, partial success and failures per record.
Retry or resolve only the failed records.
Why I didn't ship the most-requested fix first
The most-requested fix was a bulk, cart-style export. It would have been the most visible win. But it needed reliable signals about which records already existed in the CRM or sales engagement tool, and platform-level bulk export, and engineering couldn't yet guarantee either.
Shipping that interface first would have looked clearer while staying unreliable. So I plotted every pain point on an impact–effort matrix and mapped what data is received, provided and shared across CRM, sales engagement tools and CSV. The quick wins were the items with no data dependency.
The trade-off I accepted: Phase 1 would not solve bulk export. In return, we could cut friction straight away without introducing a new interaction that depended on unreliable data.
In Image: Impact–effort matrix with quick wins highlighted & dependency map across CRM, sales engagement tools and CSV
Results
Export completion rose 7% month-over-month after Phase 1.
The audit framework spread. The design team adopted the jobs-to-be-done and heuristic method for auditing other legacy workflows.
Phase 2 is on the roadmap. PM and engineering agreed the data dependencies it needs.
Measurement is in place. We shipped tracking for export completions, partial failures, recovery actions and export-related support contacts, so later phases can be measured properly.
What I'd do differently
I'd set baselines for export success and support contacts before release. Without them, a single month-over-month comparison is the strongest evidence I have for Phase 1, and I'd want a cleaner before-and-after for Phase 2.
What I learned
Moving fast doesn't mean shipping the most visible idea first. The right call was to separate fixes we could trust from a redesign that depended on problems not yet solved.
