Removing the Barrier to Entry: Designing a Self-Serve Survey Platform
The question wasn't whether to build it. It was how to do it without compromising the quality of the output, or overwhelming users who had never run a structured relationship survey before.
Verity's self-serve platform launched to a small group of beta clients, giving smaller businesses direct access to a relationship intelligence tool that was previously out of their reach. Clients could independently create, schedule and manage surveys - a process that had previously required significant consultant involvement at every stage.
Measured against the criterion that shaped every decision - could a client complete the lifecycle without five internal teams stepping in - the result was close, not complete. Two gaps stayed open by design, not oversight, with the team's full knowledge.
I owned ~85% of discovery and design, from research through to handoff, over 12–16 weeks.
Verity's core product measures business relationship health through structured surveys for mid-sized to enterprise clients. It worked well - but the cost model reflected the manual effort behind it. Every survey ran through five internal teams: product delivery, insights, consultants, CRMs, and finance.
Smaller businesses wanted in, but the price point - a direct consequence of that labour - was a consistent barrier to entry.
Five internal teams touched every survey. If self-serve worked, a client would complete the whole lifecycle without any of them stepping in. That became the test for every decision that followed.
I needed to find out where the complexity actually lived - and whether it was necessary, or just habit. Four methods, four specific unknowns:
Stakeholder interviews - what's complex vs. unexamined habit. Surfaced that product delivery managers were fire-fighting, not adding value.
As-is journey mapping - where handoffs and information loss actually happen.
Heuristic evaluation - what a trained operator tolerates that an independent user won't.
Concept testing (Userbrain, unmoderated) - pressure-test direction before committing design time.
Internal usability testing with the product delivery team became a critical input later - more on that below.
Throughout, we ran stakeholder check-ins every 2–3 weeks. This surfaced constraints early - the credit purchasing limitation, for example, was visible long before it could've become a launch-week surprise.
Drawing the line: what users could own
Every decision came down to one test: could a client complete this themselves, or did it quietly need one of the five teams to step in?
The core survey creation journey - names, dates, questions, accounts, contacts, scheduling - passed that test cleanly. Structured multi-step flow, persistent progress tracker, contextual guidance, playbook links for anyone who needed more.
Signatory management couldn't be fully self-served - platform limitation. We minimised it instead of leaving it as friction: signatory info is captured upfront at onboarding, so the email request is a rare exception, not a routine step.
Credit purchasing was a harder constraint - no card payments (CEO/CFO call), manual Salesforce process. Clients request, get invoiced, credits applied. Finance still touches every top-up: the one place the five-team boundary didn't fully hold.
In hindsight, a 24-hour+ wait deserved more attention. I don't think we exhausted what was possible within the constraint. That's what I'd revisit.
Accounts & Contacts: instinct vs. evidence
The biggest design challenge wasn't a screen - it was a decision about what the product could do, made under pressure, and ultimately reversed.
If a user couldn't fix a missing contact mid-flow, the real outcome wasn't "they finish later." It was "they email someone internal." That's the exact failure mode self-serve was built to eliminate.
In testing, users routinely hit this: reach the accounts step, realise a contact's missing, want to fix it without losing their place.
The developer's position: a dedicated Accounts & Contacts page already existed, the flow was well-structured, returning wouldn't take much effort. Reasonable - but it understated the real cost. Nothing saved until the flow completed, so "returning to the relevant step" meant starting it over, not resuming it.
My pushback: pulling someone out of an active task - even briefly - compounds friction. I proposed saving as a draft instead. Declined on technical and deadline grounds.
So I tested it. Unmoderated sessions through Userbrain on the existing flow. People tried to fix it inline first, every time - only leaving when there was no other option.
We agreed to revisit with the PM, who was on leave. Weeks later, two things happened independently: the product delivery team's internal usability testing found the same pattern unprompted, and the CEO, testing the platform himself, separately flagged the need for draft-saving.
Outcome: in-process contact editing shipped. Draft saving went to the backlog.
The instinct was right from the beginning. What changed the outcome wasn't a louder argument - it was evidence.
Two things I'd approach differently
Onboarding - contextual help and playbooks existed from the start. ProductFruits was a long-discussed idea this project finally used, implemented late by my manager. Would've benefited from being planned in from day one.
The Credits Journey - the team's call to ship with this gap open was right, given the constraints. But I don't think we explored the full range of what was possible within them. That's what I'd go back to.
This project was an exercise in constraint - technological, commercial, organisational. The most valuable skill it tested wasn't visual or structural, it was knowing when to hold a position and when to let evidence do the work.
Good design advocacy isn't about being right. It's about being able to prove it.
Thanks for reading