Enterprise Survey Builder

My role

I co-designed the foundations of the Survey Builder with 3 other designers over 8 months, from stakeholder buy-in to its GA launch. My main contributions were navigation, patterns for CRUD inside the builder, and the styling panel.

Opportunity: Unifying the customer feedback loop

Brands typically use separate tools for unsolicited feedback (social media, review sites) and solicited feedback (surveys). Sprinklr Insights was already handling the unsolicited side. An enterprise survey tool that integrates with the existing system would bring everything together.

Users

Our main users were customer experience program managers (who define brand strategies and survey goals) and implementation teams (who actually build and distribute surveys). Brand sizes vary wildly, so these roles can look very different depending on the organization.

Layout

I built on my work from Agent Console Builder to define the layout for this survey builder.

Navigation follows the typical survey workflow

Enterprise surveys have tons of controls and configurations for each question

One of the main challenges here was to design a pattern to show all the actions that could be taken on a survey question upfront. I noticed that these actions were often scattered and hard to discover in competing products.

Persistent control bar to keep settings visible upfront

I wanted to make these discoverable without jarring modals or jumping between screens. Looking at competitors, most scattered these tools across different menus or buried them behind right-clicks. I landed on a persistent control bar under every question. The trade-off is visual density, but it puts key information upfront.

I grouped the actions into two categories: Actions that enhance a question (collaborate, logic, suggestions) and actions that manage a question as an object (duplicate, lock move, delete). This reduces cognitive load for the user and makes the bar easily scannable.

This bar has scaled well. Our icon button system already supported notification badges, so we can now surface alerts about new comments and best practices right where users need them.

Styling panel

For the styling panel, I started by collecting real surveys from my inbox and asking colleagues to do the same. I reverse-engineered three heavily branded surveys to understand what controls we'd need.

Organized by element, not by property

A key decision was how to organize the panel. Competitors often use a mixed approach: some property-based sections (colors, typography) and some element-based sections (buttons, header). This creates a "hybrid mess" where users have to hunt across multiple sections to style a single element.

We chose element-based organization (Questions, Buttons, Headers, etc.). When users think "I need to style the button," they look for button settings, not color settings. This matches how they already build surveys: focusing on one component at a time.

Styling panel layout and progressive disclosure

Impact

Reflections

• This was my first time doing foundational work on a new product initiative (NPI) at this scale. I also led design meetings and supported team members whenever our principal designer was out of office. It pushed me to get more comfortable making decisions and unblocking others.
• I'd invest more in functional prototypes, especially for something like the Styling Panel, instead of relying on static screens to define specs. Tools like Figma Make, Cursor, and Claude Code make this much quicker now.