An empty workspace is not a starting point
Xano lets people build a backend without managing infrastructure. But removing code does not remove the concepts. A new user still has to understand how a database, an API, and the logic behind it fit together.
Research identified the function stack as an intimidating hurdle. Tutorials and documentation helped, but the product still needed to help people form a working mental model in context. The challenge was not just getting through signup; it was getting to something that actually worked.
The existing signup involved seven screens and ten clicks. After that effort, users could still arrive in a workspace without a clear next action. I treated first value as both a comprehension problem and an activation problem.
Teach through a real use case
I led a redesign spanning signup, welcome, empty states, and the dashboard. The value introduction explained the product in plain language; feature tours introduced databases and APIs where they were relevant.
Instead of assuming a blank canvas would invite exploration, I designed a tutorial widget and a script mapped to product screens. The goal was a real use case that connected individual tasks to an outcome, not a tour of every feature.
The tradeoff was guidance without turning first use into a course. Short, contextual explanations and optional paths let people learn while building rather than postponing the work until they understood the whole platform.
Give people a clear next step
A quick-start task list broke “build a backend” into actions someone could recognize: create a table, create an API, and test an endpoint. The redesigned dashboard and empty states gave those tasks a home.
The payoff was not a completed checklist for its own sake. It was the first working API request: a point where a user could see that the pieces they had configured actually worked together.
Measure where people get stuck
I partnered with analytics and product to establish funnel dashboards and clearer event definitions. The data team built dashboards; I helped define what we needed to learn and connected the measurement to product decisions.
I also proposed a four-question prioritization framework: does it affect revenue or paid conversion, does it improve adoption or activation, who does it serve, and what effort does it require? The team adopted the simpler framework over an abstract weighted score.
Onboarding was a concrete application of that approach. We could name the behavior we wanted to change, design toward it, and review what happened after release. That made product judgment discussable rather than a matter of competing feature preferences.
Less drop-off. A faster first working request.
Signup drop-off fell from 32% to 6.8%. Median time to first API hit fell from over four hours to 23 minutes. Together, these measures describe a clearer path from signup to a working backend.
The organizational contribution was a repeatable way to connect design work to product behavior: define the outcome, make the path understandable, and return to the evidence after launch.
Observed before-and-after results. Drop-off uses the 90-day baseline comparison; the API-hit timing window is not specified. These comparisons do not isolate the redesign’s effect.
Simplify the path, not the product’s meaning
A low-code product still asks people to reason about technical systems. The design task is to give them a way into that reasoning, not conceal the concepts until they become a surprise.
Activation and retention answer different questions. These results showed a stronger path into the product. They did not establish whether the same people kept building over time; that requires a separate follow-up.