Gainsighta design exercise
Survey Engine · design exercise

Gainsight

Build survey creation into the platform — so users stop leaving for an outside vendor.

A broad interview prompt — add survey creation to the customer-success platform — that I turned into a scoped, constraint-aware concept. The interesting work wasn’t the survey UI; it was interrogating my own assumption and designing only what the underlying platform could really build.

the survey lifecycle
1Create2Design3Distribute4Close
UX designCompetitive analysisWireframingPlatform-constraint researchGainsight · design exercise
01Addressing the assumption

I caught the untested bet inside my own hypothesis.

The easy version of this exercise is to assume you know what users want and start drawing. Instead I named the assumption baked into my hypothesis — that people wanted to build surveys in-platform at all — and grounded the concept by talking to real users before designing, so the feature answered a real need rather than a guessed one.

02The real constraint

Reading Salesforce developer docs — as a designer.

The platform sat on Salesforce, so the constraint was concrete: design only what the platform could actually build. I read the developer documentation as a designer would read a style guide — to learn the real edges — so the concept was buildable, not a fantasy that would collapse on handoff.

Constraint-aware from the start beats beautiful-but-impossible every time.
03The designs

The whole survey lifecycle, not just a builder.

I scoped the concept to the full arc a survey actually travels, because a create screen alone isn’t a feature — it’s a demo.

01

Create

Start a survey from scratch or a pattern.

02

Design & preview

Build the questions and see them as a respondent would.

03

Distribute & publish

Get it out to the right audience.

04

Drafts

The in-between state real work actually lives in.

05

Close

Ending a survey cleanly, not just abandoning it.

From sketch to wireframe — the survey homepage

sketch — drafts tab
sketch — drafts tab
wireframe — drafts (row actions)
salesforce⌂   Surveys   Contacts   Reports   ⌕
Surveys
ActiveDraftsClosed⊕ Create New
Title ▽
Description ▽
Actions ▽
Title
WIP-test
⚙ ▾
Title
WIP-tosp
⚙ ▾
Title
WIP-test 3
⚙ ▾
Design
Edit
Publish
Delete
Preview
Title
WIP-test 4
⚙ ▾
Title
WIP-test 5
⚙ ▾
Drafts-tab actions: Design · Edit · Publish · Delete · Preview
sketch — active tab
sketch — active tab
wireframe — active (dates + response rate)
salesforce⌂   Surveys   Contacts   Reports   ⌕
Surveys
ActiveDraftsClosed⊕ Create New
Title ▽
Start date ▽
End date ▽
Response rate
Actions
Title
1/1/2014
1/2/2014
1/100 (1%)
⚙ ▾
Title
1/1/2014
1/2/2014
50/100 (50%)
⚙ ▾
Title
1/2/2014
1/3/2014
25/100 (25%)
⚙ ▾
Title
1/2/2014
1/3/2014
1/7 (14%)
⚙ ▾
Title
1/2/2014
1/4/2014
3/10 (30%)
⚙ ▾
Title
1/2/2014
1/5/2014
1/1 (100%)
⚙ ▾
Row menu is contextual to the tab · sortable by clicking a header

My hand sketches on the wireframe-sketch sheet, and the clean coded wireframes built from them — the Salesforce-hosted survey homepage, with tab-contextual row actions.

Where it landed & what it taught me

The strongest concept is one you already know can be built.

The output was a scoped, constraint-aware survey-engine concept covering the full lifecycle — grounded in real user input and in the platform’s genuine capabilities. Reading the developer docs as a designer is a habit I’ve kept: it’s the fastest way to make sure a design can actually ship.

Honest framing: this was an interview design exercise, so there’s no launch or metric — the intended success measure (feature adoption) was hypothetical.