Revamp / UX design B2B SaaS

Redesigning Engagespot's setup to cut support tickets 85%

Engagespot gives developers email, SMS, push, and chat notifications through a single API. When setup overtook everything else as the leading cause of support tickets, I led the research and redesign that turned a technical, engineer-only flow into something both developers and non-technical PMs could complete on their own.

Role
UX Designer, Research
Duration
3 months
Team
Founders, Eng, PM
Tools
Figma, Notion
Drop hero screenshot here — dashboard or key before/after screen
01 — Impact

Fewer errors, fewer tickets, more people using what they'd paid for

Errors, ticket volume, and feature adoption all moved in the same quarter — evidence that the redesign fixed the actual bottleneck, not just its symptoms.

0%
User setup errors
↓ from 46%
0+/mo
Support ticket volume
↓ from 800+/mo
0%
Feature adoption
↑ from 40%
Business result — the redesign helped onboard Jio and Accenture as clients, and contributed to Engagespot securing funding from Techstars.
02 — UX Research

Finding the real problem before designing the fix

Support tickets don't explain themselves. Before touching a single screen, I needed to know whether Engagespot had a UI problem or something the interface alone couldn't fix — and whether solving it was worth the engineering time it would take.

Research approach
What

A focused generative research sprint — workshops and interviews with internal teams and power users, mapped against how they actually set up, sent, and monitored notifications.

Why

To surface real pain points and their cost in time, errors, and drop-offs — not a wishlist of feature requests.

How

Stakeholder interviews across developers, PM, and support; a six-competitor scan; and a full pass through a quarter of support tickets and error logs.

Who

2–3 engineers (backend and frontend), 1–2 support and CS reps, and 2 customer developers already integrated with Engagespot.

Method & synthesis

I ran discovery workshops with product, engineering, and support, then sat down individually with the customers most likely to churn. In parallel, I read every ticket tagged setup or integration from the previous quarter. The pattern showed up fast: friction wasn't spread evenly across the product — it clustered almost entirely in the first ten minutes after signup.

Key findings

From developers

  • No clear "start here" moment after signup
  • Setup broke most often at the API key / HMAC step
  • No way to see, at a glance, which channels were live or where to add a provider
  • Templates were repetitive and demanded more dev time than they should have

From product & support

  • Setup, channels, and templates were the top three drivers of support tickets
  • PMs and CS staff found the interface too technical to self-serve
  • No single place to see what was sent, what failed, and why
  • Friction was UX and information architecture, not missing functionality — with real appetite for guided onboarding
The reframe — the fastest path to activation wasn't more features. It was removing friction from the first ten minutes after signup.
Competitive landscape

I benchmarked Engagespot against six notification infrastructure products — SuprSend, Novu, Knock, Courier, Raven, and MagicBell — across 15 dimensions, from onboarding and accessibility to dashboard customization and documentation quality.

  • Dark mode, theming, and multi-channel support had become baseline expectations, not differentiators
  • Infrastructure-heavy tools optimized for routing and workflows; interface-heavy tools optimized for inbox UX — almost none did both well
  • Most competitors read as either enterprise-heavy or too technical for a non-developer to self-serve — Engagespot's opening
SuprSendNovuKnockCourierRavenMagicBell
Who I was designing for
Backend Developer · SaaS startup

Dev John

Friction
Cluttered interface, unclear documentation, integrations that broke mid-setup
Cost
Every broken integration meant lost development time chasing a problem the product should have surfaced itself
Needs
One reliable view of channel health — what's live, what's missing, what's broken
"When I open the app, I want one clear view of all channels... so I can quickly add or fix a channel without chasing the infra team."
Project Manager · SaaS startup

PM Priya

Friction
An interface built for engineers, not the people managing the product day to day
Cost
Every notification change meant opening a ticket and waiting on engineering's backlog
Needs
A guided path she could complete herself, with visible confirmation nothing broke
"I'm not a developer. I just need a clear, step-by-step checklist... without asking engineering every time."
03 — Team & my role

Sole UX designer, embedded end to end

The only designer on a team of founders, engineers, a PM, and support. My scope covered:

  • Discovery — ticket analysis, interviews, workshops
  • Design — IA, flows, UI, design system
  • Validation — usability testing, iteration, instrumentation
04 — Constraints & roadblocks

What I was designing around

  • An engineer-led UI with inconsistent patterns — a full rebuild wasn't an option on this timeline
  • Discoverability, not missing functionality, was driving most of the support load
  • Competitors already shipped dark mode and multi-channel support — the redesign had to clear that bar, not just fix onboarding
SuprSendNovuKnockCourierMagicBell
05 — Key decisions

Three calls that shaped the redesign

01

Break setup into a guided four-step flow with a single primary action at each step — fewer choices, faster decisions — replacing one dense settings page.

02

Regroup channels into "Configured" and "Not added," matching how users already sorted them mentally, instead of one undifferentiated list.

03

Prioritize setup and discoverability over new features. The research pointed to friction, not a capability gap.

06 — Design solution

How the redesign came together

Three phases, in the order the project actually unfolded — click through to follow the arc from research to a validated design.

Ticket data, error logs, and interviews across developers, PMs, and support reps all pointed the same direction: setup broke most often at the API key/HMAC step, there was no clear "start here" after signup, and templates ate up more dev time than they should have. A six-competitor scan confirmed the bar Engagespot had to clear — dark mode, theming, and multi-channel support were no longer differentiators, they were table stakes.

Drop research synthesis / sticky-note board screenshot here
Vision

Replace the wall-of-text settings page with a guided flow that always surfaces one obvious next action.

Action

Rebuilt Getting Started as a four-step flow, and regrouped Channels into Configured and Not added for at-a-glance health.

Drop before/after screens here — settings page & channels page

Usability testing validated the direction — participants called out the step-by-step flow and the Configured/Not added grouping as clear wins, and described the darker UI as modern and comfortable to work in for long sessions. What didn't land, like the template-canvas interaction, fed straight into the next iteration.

Drop usability test screenshot / annotated feedback here
What people said
"I'm still blind, I have to dig through the entire call." "Setup broke midway and I lost the afternoon." "I just need one clear checklist." "One view of what's live and what's broken."
07 — Outcome
The redesign didn't just quiet the support queue — it became a credibility asset for the business at a pivotal moment. Engagespot onboarded Jio and Accenture as clients, and secured funding from Techstars during this period.
28%
User errors
120+/mo
Support tickets
76%
Feature usage
08 — Learnings & growth

What this project changed about how I work

1

The fix was never a feature gap — it was discoverability and sequencing. The biggest single lever turned out to be reducing how many decisions a user had to make at each step.

2

Ticket and error-log data made a far stronger case for prioritization than opinions in the room — worth building that habit into the start of every project, not just this one.

3

A design system pays off twice: once in this redesign's consistency, and again in how much faster the parallel Design System project was able to ship afterward.

Next case study

Speed Up the Development Process — the design system that made this redesign faster to ship

Let's talk, maybe?

Want to talk about design, ideas, tech, coffee, building — or just anything in general? Feel free to hit me up!

Send message