For web applications
I stand on your user's screen. I know where everything is, and I can press it.
Your users don't read the docs; they ask. Today they ask your support, or they leave. Put me in your app and they ask me: I open the right screen, switch the language tab, type the text — and stop with my hand over Save until they say yes. I know which user I'm talking to, I see only their data, and when something on a screen needs attention, I say so before they notice.
Try it here
This is a screen of an app. Ask me to fill it in.
An ordinary form that could be in your app. I'll fill in the fields, pick the plan — and ask before I press «Save». Saving sends nothing anywhere — it's a demo.
See how I work in our own panel — after you sign up →How to set up a form like this, for developers →What happens in an app once I'm in it.
- «Take me to the invoices for March.»
I know your screens by their addresses, so I open the right one — with the filter already set, when your screen takes one in its address.
→ - «Fill in the shipping address with the one from my profile.»
I look at the screen, find the fields, write into them, and tell the user what I replaced. Tabs, dropdowns, checkboxes, sliders, lists with an «Add» button — I operate them the way a person would.
→ - «Save it.»
I don't. Not until they say so: a press that can't be undone is held and asked about, in their own words or with one tap. Or you tell me, once, that in your app I may press Save myself after I've filled a form — your call, not mine.
→ - «Why is Save greyed out?»
I read the screen and answer from it: which field is still empty, what the note beside it says. For this I touch nothing.
→ - «What should I be doing here?»
Before they ask: when your app's own check finds something on this screen — an unfinished setup, a failing import — I raise a hand in the corner with one sentence, once, and not again for as long as you set.
→
</>
I know which user I'm with — because you tell me, the way you'd tell your own API.
Your app hands me the user's own token when they log in, and I pass it along with every question I ask your API. So «show my unpaid invoices» means their invoices, and I never hold an identity I could get wrong. The token is never stored, never logged, never shown to the model.
On a shared computer, logging out wipes me clean: the conversation, the memory of who that was.
</>
What your developer does. Once.
- The same one line as on any website.
- Tell me your screens. Each screen is a short note in your panel — its address pattern (/orders/{id}), its name, and what it's for. Routes with ids are fine; I fill the id in from what the user asked.
- Mark the one button that saves. One attribute on your Save, and I know what a «commit» is on that screen. Mark a field private, and I never read it. Everything else I work out from the page itself — labels, tabs, dropdowns — and the better your screen reads for a screen reader, the better it reads for me.
- Hand me the user. One call when they log in, one when they log out.
Our own panel is built exactly this way, and you'll meet me there after you sign up: ask me to change your widget's colour, and watch.
The markup, for developers →What your support queue looks like after a month.
Fewer tickets that are really questions.
«Where is…», «how do I…» — answered on the screen, with the thing done.
New users who find their way.
Without a tour, without a call, in their own language.
A list of what confuses people.
The questions I couldn't answer from your screens, grouped — which is a list of screens to fix.
What I read on a screen is your switch
off by default, marked fields only, or everything.
What I press is your switch too
never, ask first, or save myself.
Your users' data
goes to your API under their own login, not under mine. Data and control →
Growth
For an app, it's Growth.
Screens, page actions, your own API and the raised hand come with Growth: $29 a month, 7,000 credits, 3 sites. An app with many screens and many users will want Pro.
Give your users someone on the screen with them.
