Survey Engine
Build survey creation into the platform — so a CS team never leaves to ask a question.
Gainsight is a customer-success platform: its job is reducing churn and growing accounts. I was asked to design survey creation directly into it — living inside Salesforce — so teams never have to leave the tool to ask their customers a question. This walks the thinking and the full survey lifecycle I designed.
A question, not a backlog.
No wireframes to inherit, no research repository, no existing surface to bolt onto. Just a business question — and the expectation that I could reason my way from there to a design.
Every handoff out is a seam.
Surveys — NPS, CSAT, health checks — are core to customer success: the feedback loop that tells a team where a relationship actually stands. Today, running one means leaving the tool your customer data lives in. If you’re the platform CS teams live in all day, sending them to a separate vendor is a real seam — friction at every handoff, and a real reason for their attention and their data to leave your product.
The single source of truth
Customer relationships, health scores, and account data — all in one place.
A separate tool, by hand
Stand it up, manage it, and pull results back manually — every handoff a place the source of truth quietly falls apart.
Scoped to stay buildable.
I set the goal deliberately narrow so it stayed buildable rather than aspirational. Not reinvent SurveyMonkey. Not own the category. Close the loop — so users never leave to create and maintain surveys.
Stand up
Start a new survey from inside the platform.
Distribute
Publish to the right participants.
Revise
Change questions, logic, and drafts in place.
Retire
Close surveys cleanly to a closed tab.
…for multiple surveys — a portfolio and its lifecycles, not a single form. Scoped to what a first version needs, not what would be nice to show off.
I checked my own premise first.
The working hypothesis was straightforward — and I want to be honest about the weakness in it, because interrogating it became the most useful part of the project. So the first real move wasn’t design. It was talking to a few current users to confirm the need and pressure-test which capabilities actually mattered, rather than designing to a wish list I’d invented.
Borrow the patterns users already carry.
I studied SurveyMonkey and other established engines — not to copy, but to learn the conventions people already expect, so anything I put inside Gainsight would feel native instead of foreign. Meeting people at the patterns they know is the cheapest usability win available.
Question types
The vocabulary people already reach for.
Build → distribute
The two-step flow users expect.
Edit & version
Revise without starting over.
Manage many
Several live surveys at once.
Guiding principle → create, send, edit, and remove multiple surveys.
The hard part wasn’t the survey. It was the platform.
Gainsight lived inside Salesforce — its own structure, components, and rules about what you can and can’t do. Before I could draw a single screen I had to learn where the feature could sit and what the platform would actually let me build. I had functional requirements from the Product Owner — the what. The how was on me. So I worked through Salesforce’s own developer documentation and designed from what was real.
Functional requirements — the what.
The how — in Apex + Lightning.
How the concept came together.
Judgment up front, production last — each step earned the next.
The survey lifecycle, mapped.
With the premise checked, the patterns borrowed, and the platform’s real capabilities mapped, the concept resolved into a sitemap. You enter the Survey Engine once — Active, Drafts, and Closedare views inside it, each with its own set of actions. Duplicating a survey drops a copy into Drafts. This is what makes “create, send, edit, and remove multiple surveys” legible as an actual interface rather than a description.
From sketch to wireframe — the survey homepage
The Salesforce-hosted survey homepage — one list with Active / Drafts / Closed tabs and tab-contextual row actions, built up from the hand-sketch sheet.
Wireframe first. Then Salesforce Lightning.
Each step of the lifecycle, shown twice: the low-fidelity wireframe that proved the flow, and the same screen realized in Salesforce Lightning — the platform’s own global bar, page header, cards, and status pills. Designing where the data already lives is the whole point.
Creating a survey — the settings that scope it: name, unique ID, start and end dates, a description, a thank-you message, a redirect. The wireframe proved the flow; the Lightning version realizes it as a standard record page with the platform’s own global bar, header, inputs, and actions.
The builder: reorderable questions, inline answers, and branching logic. In Lightning it becomes the platform’s global bar and page header, a status path from draft to published, and questions as Lightning cards — designing where the customer data already lives.
The wireframe builds the participant list from filtered contacts; Lightning realizes it as a standard list view with row selection straight from Salesforce contact data, a publish status, and an email template — no export required, because the audience is already in the platform.
One list, three tabs, and a guarded close action. The Lightning version realizes it as a standard list view with status pills, row-level actions, and a real confirmation dialog — the whole portfolio of surveys in one native place.
The loop the whole feature exists to close. This screen was scoped as the next step rather than drawn at the time, so it’s shown as a concept: a headline NPS score, a response-rate read, the promoter/passive/detractor split, a trend, and verbatim comments — read natively, so answers land where the customer’s account data already lives instead of a vendor’s dashboard. Values shown are illustrative.
Two things stuck with me.
Design inside a platform you don’t control.
Achieving a new capability within Salesforce’s boundaries is a very different muscle from a greenfield canvas — and the more valuable one to have.
Distrust the “obviously useful” feature.
It’s easy to fall in love with a feature and skip asking whether it’s wanted. Catching that in my own hypothesis made the concept stronger for being suspicious of itself.
A one-sentence business question, turned into a scoped, constraint-aware concept — designed to live natively inside Salesforce.
The value was the thinking and the constraint work: taking a broad prompt and turning it into something a team could pick up and build — create, send, edit, and remove multiple surveys, without ever leaving the platform. The full survey lifecycle, wireframed and then realized in Salesforce Lightning.
Honest framing: this was an interview design exercise, so there’s no launch or metric. The intended measure, had it shipped, was feature adoption — did teams create surveys here instead of leaving for a vendor.