Equally AI · 2023
Turning a spike in support tickets into a journey people could finish alone
A no-code path to accessibility fixes, rebuilt around what the numbers said people were actually trying to do — and where they consistently gave up.
Role
Product Designer — quantitative analysis, journey design, interaction design
Team
1 designer (me), 1 PM, 4 engineers, customer success lead
Timeline
About 3 months
Tools
Figma, FigJam, Google Analytics, Hotjar, Notion
Headline result
23% increase in engagement
What I did
- Built the funnel and event analysis that framed the problem
- Mapped the current and proposed journeys with customer success
- Designed the rule-building interaction model and empty states
- Prototyped and tested the revised first-run experience
Context
Flowy was Equally AI's answer to a real gap: fixing accessibility issues often required a developer, and most of our customers did not have one available on the timeline they needed. Flowy let a non-developer apply fixes through a visual interface instead of a pull request.
The feature existed. It was not being used. This was not a discovery project with the luxury of open-ended research — I had three months, an existing product, and a lot of behavioural data nobody had properly read.
Reading the numbers first
I started quantitative because the sample was already there. I mapped every event in the Flowy funnel against the support tickets from the same period and looked for the places where the two disagreed.
What the data showed
- A steep drop between opening Flowy and creating a first rule — people arrived, looked, and left.
- Of those who created a rule, a large share never published it. The canvas was being used as a sketchpad, not a tool.
- Session recordings showed repeated hovering over node types with no click: people could not predict what a node would do before committing to it.
- The tickets clustered on one question — “will this break my site?” — which no screen in the flow answered.
I then ran five short calls with customers from the drop-off cohort to put language to the numbers. The recurring sentiment was not confusion about the interface. It was fear of consequence. They were being asked to change a live site with no way to see what would happen.
The reframe
“The blocker wasn't capability, it was consequence. People understood what to build; they didn't know what it would do to their site.”
That moved the work away from “make the canvas easier” — the obvious brief — and toward preview, reversibility and staged commitment. It also meant the fix was mostly journey design, not visual design, which is a harder sell in a review and the reason I brought the funnel chart to every one.
Explorations
- 01
Templates first
Open Flowy onto a set of pre-built rules for the most common violation patterns rather than a blank canvas. Cheap to build, directly addressed the empty-state cliff.
- 02
Live preview panel
Show the affected elements on a rendered version of the user's own page as the rule is built. The strongest answer to the fear, and the most expensive — I scoped it to a static before/after view for v1.
- 03
Staged publishing
Draft, preview, publish, with a visible one-click revert and a plain-language summary of scope: 'this affects 14 elements on 3 pages'.
I rejected a fourth option — a guided wizard replacing the canvas entirely — because it would have solved the first-run problem while destroying the ceiling for the power users who were, at that point, our only successful cohort.
Design decisions, and why
Flowy opens on templates, never on an empty canvas.
WhyThe largest single drop was at first sight of the blank state. A template makes the first action editing something rather than inventing something.
Every rule shows its blast radius before publish.
Why'Affects 14 elements across 3 pages' is the sentence the support tickets were asking for, in the place where the anxiety happens.
Publishing is a distinct, staged step with a persistent revert.
WhyReversibility converts an irreversible decision into a cheap experiment, which is what unblocked the cautious majority.
Node types are explained on hover, before selection.
WhyThe recordings showed hesitation at exactly that moment. Explaining after the click was too late.
The Figma layer
- A node component with variants per type and state, wired so the canvas mockups could be assembled quickly for testing rather than drawn by hand.
- Auto layout on the rule summary so long, real-world rule names were designed for at the widest realistic case.
- An interactive prototype covering the whole staged flow — template, edit, preview, publish, revert — which is what we tested, because the fear we were designing against only appears when the flow is continuous.
Testing and iteration
Six unmoderated tests on the prototype. The blast-radius summary worked immediately — participants read it aloud unprompted. The revert control did not: placed in a toast, it disappeared before anyone felt the need for it. Moving it to a persistent bar on the published rule fixed the confidence gap in the follow-up round.
Outcome
23%
increase in user engagement
Templates
replaced the empty canvas as the entry point
0 → staged
publish flow with visible revert
Reflection
The lesson I carry from this one is that a well-read funnel is a research method, not a reporting exercise. Five short calls on top of the data got me further than five weeks of open discovery would have.
I would fight harder for the live preview. The static before/after was the right v1 compromise, but the real answer to 'will this break my site' is showing the site.