Für Webanwendungen
Ich stehe auf dem Bildschirm Ihrer Nutzer. Ich weiß, wo alles ist, und ich kann es drücken.
Ihre Nutzer lesen keine Doku, sie fragen. Heute fragen sie Ihren Support – oder sie springen ab. Bauen Sie mich in Ihre App ein, dann fragen sie mich: Ich öffne den richtigen Bildschirm, wechsle den Sprach-Tab, tippe den Text ein – und halte die Hand über „Speichern“, bis sie Ja sagen. Ich weiß, mit welchem Nutzer ich spreche, sehe nur dessen Daten, und wenn auf einem Bildschirm etwas Aufmerksamkeit braucht, sage ich es, bevor es ihnen auffällt.
Hier ausprobieren
Das hier ist der Bildschirm einer App. Bitten Sie mich, ihn auszufüllen.
Ein gewöhnliches Formular, wie es in Ihrer App vorkommen könnte. Ich fülle die Felder aus, wähle den Tarif – und frage, bevor ich „Speichern“ drücke. Beim Speichern wird nichts gesendet – das ist eine Demo.
So arbeite ich in unserem eigenen Panel – nach der Registrierung →So richten Sie ein Formular wie dieses ein — für Entwickler →Was in einer App passiert, sobald ich drin bin.
- „Bring mich zu den Rechnungen vom März.“
Ich kenne Ihre Bildschirme an ihren Adressen und öffne deshalb den richtigen – mit bereits gesetztem Filter, wenn Ihr Bildschirm einen in der Adresse annimmt.
→ - „Trag die Lieferadresse aus meinem Profil ein.“
Ich sehe mir den Bildschirm an, finde die Felder, schreibe hinein und sage dem Nutzer, was ich ersetzt habe. Tabs, Dropdowns, Checkboxen, Schieberegler, Listen mit einem „Hinzufügen“-Button – ich bediene sie so, wie es ein Mensch tun würde.
→ - „Speichere es.“
Tue ich nicht. Nicht, bevor der Nutzer es sagt: Einen Klick, der sich nicht rückgängig machen lässt, halte ich zurück und frage nach – der Nutzer antwortet mit eigenen Worten oder mit einem Tippen. Oder Sie sagen mir einmal, dass ich in Ihrer App nach dem Ausfüllen eines Formulars selbst auf Speichern drücken darf – Ihre Entscheidung, nicht meine.
→ - „Warum ist Speichern ausgegraut?“
Ich lese den Bildschirm und antworte daraus: welches Feld noch leer ist, was der Hinweis daneben sagt. Dafür fasse ich nichts an.
→ - „Was sollte ich hier tun?“
Schon bevor der Nutzer fragt: Wenn die eigene Prüfung Ihrer App auf diesem Bildschirm etwas findet – eine unfertige Einrichtung, einen fehlgeschlagenen Import –, hebe ich in der Ecke die Hand, mit einem Satz, einmal, und danach so lange nicht wieder, wie Sie es festlegen.
→
</>
Ich weiß, bei welchem Nutzer ich bin – weil Sie es mir sagen, genauso wie Ihrer eigenen API.
Ihre App übergibt mir beim Login das eigene Token des Nutzers, und ich reiche es bei jeder Anfrage an Ihre API mit. „Zeig meine offenen Rechnungen“ meint also seine Rechnungen, und ich verwalte nie selbst eine Identität, bei der ich mich irren könnte. Das Token wird nie gespeichert, nie protokolliert und nie dem Modell gezeigt.
Auf einem gemeinsam genutzten Rechner lösche ich beim Abmelden alles: die Unterhaltung und die Erinnerung daran, wer das war.
</>
Was Ihr Entwickler tut. Einmal.
- Dieselbe eine Zeile wie auf jeder Website.
- Nennen Sie mir Ihre Bildschirme. Jeder Bildschirm ist eine kurze Notiz in Ihrem Panel – sein Adressmuster (/orders/{id}), sein Name und sein Zweck. Routen mit IDs sind kein Problem; die ID setze ich aus der Anfrage des Nutzers ein.
- Markieren Sie den einen Button, der speichert. Ein Attribut an Ihrem Speichern-Button, und ich weiß, was auf diesem Bildschirm ein „Commit“ ist. Markieren Sie ein Feld als privat, und ich lese es nie. Alles andere erschließe ich aus der Seite selbst – Labels, Tabs, Dropdowns –, und je besser ein Screenreader Ihren Bildschirm lesen kann, desto besser kann ich es auch.
- Übergeben Sie mir den Nutzer. Ein Aufruf beim Login, einer beim Logout.
Unser eigenes Panel ist genau so gebaut, und dort lernen Sie mich nach der Anmeldung kennen: Bitten Sie mich, die Farbe Ihres Widgets zu ändern, und sehen Sie zu.
Das Markup für Entwickler →So sieht Ihre Support-Warteschlange nach einem Monat aus.
Weniger Tickets, die eigentlich Fragen sind.
„Wo finde ich …“, „wie mache ich …“ – beantwortet direkt auf dem Bildschirm, und erledigt ist es auch gleich.
Neue Nutzer, die sich zurechtfinden.
Ohne Tour, ohne Anruf, in ihrer eigenen Sprache.
Eine Liste dessen, was Nutzer verwirrt.
Die Fragen, die ich anhand Ihrer Bildschirme nicht beantworten konnte, nach Themen gruppiert – das ist zugleich eine Liste der Bildschirme, die Sie überarbeiten sollten.
Was ich auf einem Bildschirm lese, bestimmen Sie
standardmäßig aus, nur markierte Felder oder alles.
Was ich drücke, bestimmen Sie ebenfalls
nie, erst fragen oder selbst speichern.
Die Daten Ihrer Nutzer
gehen mit deren eigenem Login an Ihre API, nicht mit meinem. Daten und Kontrolle →
Growth
Für eine App passt Growth.
Bildschirme, Seitenaktionen, Ihre eigene API und die erhobene Hand sind im Tarif Growth enthalten: $29 im Monat, 7.000 Credits, 3 Websites. Eine App mit vielen Bildschirmen und vielen Nutzern braucht eher Pro.
Geben Sie Ihren Nutzern jemanden an die Seite – direkt auf dem Bildschirm.
