Folge 5: Prototyping für Alexa Skills – Wie man Ideen einfach abtestet

Wie kann man schnell und ohne großes Risiko Ideen für Alexa Skills abtesten? Wir stellen dazu 2 Methoden vor und schauen uns an welche Vorteile die Methoden jeweils haben.


 

Bleibe auf dem Laufenden zum Thema VoiceDesign

Du kannst diesen Podcast über iTunes, Stitcher oder Soundcloud abonnieren.
Oder trage Dich in den Newsletter ein und ich informiere Dich einmal im Monat über alle neuen Folgen, interessante Texte von anderen Seiten und alles, was sonst noch relevant ist.


 

Hallo und herzlich Willkommen zur heutigen Ausgabe von One Skill A Day. Dem Podcast rund um Voice Design. Mein Name ist Alexander Kamphorst. Schön, dass Du heute dabei bist.

Wir wollen uns dieses Mal mit Prototyping für Alexa Skills beschäftigen. Mit Prototypen können wir Ideen für neue Skills kostengünstig und mit wenig Risiko an möglichen Nutzern testen. Damit erhalten wir frühzeitig Feedback ob eine Idee funktionieren kann und ob wir bestimmte Bedürfnisse oder relevante Features übersehen haben.

Prototyping kann man auf unterschiedlichen Wegen machen. Bereits wenn Du versuchst eine Ideen jemand anderem zu erzählen, ist es eine Form von Prototyping. Du probierst die Idee, die bisher nur in Deinem Kopf vorkommt durch die gesprochene Sprache zu präzisieren und zu vermitteln. Das ist also im Prinzip die gröbste Form des Prototypings. Von da an kann man immer präzisere und klarere Modelle der Ideen entwickeln.
Wir haben in den letzten Wochen für unsere Projekte unterschiedliche Methoden ausprobiert und ganz gute Learnings daraus ziehen können.

Ich möchte Dir daher heute 2 Möglichkeiten vorstellen, wie Du Deine Ideen noch feiner abtesten kannst und deutlich besseres Feedback erhälst. Im Prinzip geht es nämlich immer darum den späteren Service so anschaulich wie möglich zu demonstrieren. Umso besser sich ein Nutzer in die spätere Situation und den zugehörigen Service reinversetzen kann, desto eher ist er in der Lage, Feedback zu geben mit dem wir arbeiten können.

Die erste Möglichkeit, die ich Dir vorstellen möchte, wird heute auch schon für die Entwicklung von Webseiten oder Apps genutzt. In diesen Bereichen ist die Methode als Paper Prototyping bekannt. Bei einer App für das iPhone oder für Android bastelt man beispielsweise einfache Scribbles. Also grobe Zeichnungen der späteren Screens. Mit diesen Scribbles gehen wir zu potentiellen Nutzern und legen ihnen die Scribbles einzelnd vor. Wir spielen dann die Nutzung der App durch. Der User kann ganz einfach auf einen bestimmten Bereich des Scribbles zeigen, zum Beispiel einen Button. Wir zeigen ihm darauf hin dann den nächsten Screen. So kann man im Prinzip den gesamten Umfang einer App mit ein paar groben Zeichnungen durchspielen. Ohne auch nur eine Zeile Code geschrieben zu haben oder ein Design angefertigt zu haben. Das ist also deutlich schneller und deutlich kostengünstiger als wenn man erst was produziert oder was programmiert um es dann später beim Nutzer abzutesten.

Dieses Prinzip haben wir mal auf die Entwicklung von Skills umgelegt. Wir haben uns gefragt wie man mit Stift und Papier einen Skill so simulieren kann, dass potentielle Nutzer ihn quasi auf Papier ausprobieren können.
Was uns dabei besonders interessiert hat, ist, ob der User Flow so funktioniert wie wir uns das vorgestellt haben.
Um das zu testen, haben wir den Nutzer mit den Informationen ausgestattet, die er auch bekommt, wenn er den Skill in der Alexa App erstmalig aktiviert. Wir haben also 2 bis 3 Beispiel Utterances auf Karten geschrieben und sie ihm vorgelegt. Er hat uns daraufhin eine der Karten gegeben und hat dafür eine Folge-Karte zurück bekommen. Diese Karte stellt quasi die Antwort von Alexa beziehungsweise von unserem Skill dar. Damit haben wir einmal den Frage und Antwort Zyklus durchgespielt
Zur Antwort-Karte bekommt der Nutzer dann noch weitere Karten. Diese stellen seine nächsten möglichen Spracheingaben dar. Und so geht es ein wenig hin und her und der Nutzer kann sich durch den gesamten Verlauf einer Interaktion mit unserem Skill durchspielen.
Am besten funktioniert dieser Ansatz, wenn man unterschiedlich farbige Kärtchen für Nutzer-Aussage und Skill-Antworten nimmt. Alles, was der Nutzer so sagen kann haben wir auf gründe Kärtchen geschrieben. Alles was vom Skill als Antwort zurück kommt haben wir auch gelbe Kärtchen gemacht. Damit ist auch eine visuelle Unterstützung gegeben, die es dem Tester leichter macht den Sprachflow zu verstehen.

Insgesamt hat das für sehr frühe Abtestungen recht gut funktioniert. Wir konnten so ermitteln ob die grundsätzliche Idee verstanden wird und einen Mehrwert liefern würde.
Aber diese Methode hat doch einige Probleme. Denn im Gegensatz zu einer App wo man klickt und scrollt, ist bei einem Sprachskill eben die Stimme vorhanden. Und damit die Unendlichkeit von sprachlichen Aussagen des Nutzers. In einer App gibt es 1 oder 2 oder 3 Buttons und das war es. Die Möglichkeiten sind eingeschränkt. Bei einem Skill kann der Nutzer erstmal sagen, was er will und der Skill muss das verstehen und weiterverarbeiten.
Wenn wir also die Fragen und Antworten auf Zettel schreiben, dann stellen diese Zettel unsere Annahmen dar. Es sind die Dinge, von denen wir glauben, dass Nutzer sie fragen würden oder wie Nutzer unseren Skill nutzen würden.

Tatsächlich muss das aber nicht viel mit der späteren Nutzung zu tun haben. Wir brauchen also auch eine Methode mit der wir besser verstehen, wie Nutzer unseren Skill benutzen werden. Das fängt schon bei den Sample Utterances an. Also bei den Beispieläußerungen die Nutzer dem Skill sagen werden. Wir haben uns daher die Frage gestellt: Wie können wir auf natürliche Weise verstehen, wie der Nutzer unseren Skill benutzen wird?

Wir haben da relativ viel rumprobiert und haben da alle möglichen skurrilen Testszenarien entworfen. Am Ende war vieles davon aber völlig für die Tonne. Wir haben aber dann doch noch einen sehr spannende Weg gefunden, wie man den Testnutzer dazu bringt möglichst natürlich eine Idee abzutesten. Und wir können so jetzt viele Probleme frühzeitig erkennen und vor der eigentlichen Skill-Entwicklung bestimmte Parameter anpassen.
Intern nennen wir diese Methode Teletest. Klingt so ähnlich wie der gute alte Teletext auf dem Fernseher. Hat aber nix damit zu tun. Wer einen besseren Namens-Vorschlag für diese Methode hat, wir nehmen gerne Vorschläge entgegen.
Auf jeden Fall ist die Methode denkbar simple gestrickt: Wir schreiben uns alle relevanten Sätze und Antworten, die unser Skill nach unserer Meinung haben sollte auf einen Zettel. Denn in dieser Methode sind wir selber der Skill. Es ist ein wenig wie ganz früher, Anfang des 20. Jahrhunderts, als auf Jahrmärkten die Schausteller meinten sie hätten eine Wundermaschine. Und die würde vollautomatisch allerhand Dinge tun. Zum Beispiel Schach spielen. Natürlich gab es damals noch keine Computer und dergleichen und am Ende war es so, dass in diese Holzmaschinen ein Mensch saß und die Bewegungen von Hand durchgeführt hat. Er hat also zum Beispiel die Schachfiguren bewegt. Für Außenstehende, die nicht wussten, dass da jemand in der Holzbox sitzt, sah es magisch aus.

Das gleiche Prinzip nutzen wir auch, nur dass es weniger magisch daher kommt. Was wir aktuell machen um einen Skill frühzeitig zu testen und seinen Funktionsumfang zu modellieren ist, dass wir unsere Testpersonen anrufen. Über Telefon, über Skype oder Slack oder Google Hangout. Das ist im Prinzip egal.

Der Nutzer kann dann ganz normal wie er es auch mit dem Amazon Echo machen würde anfangen zu reden. Also einen Skill starten, eine Frage stellen oder sonstwas. Um es ihm etwas leichter zu machen, bekommt er von uns vorab wieder eine kurze Beschreibung des Skills sowie 2 Beispieläußerungen. Was auch immer er nun sagt, wir antworten ihm mit den Dingen, die wir vorher auf unseren Zettel geschrieben haben. Der Tester bekommt also direktes Feedback auf alles, was er sagt und kann so den Skill sehr simpel ausprobieren und nachträglich auch Feedback geben.
Das wirklich spannende an dieser Methode ist dabei, dass man von Anfang an die Unberechenbarkeit des Nutzers erlebt. Zwar gibt man ihm ein paar Beispieläußerungen an die Hand. Aber wir haben die Erfahrung gemacht, dass der Nutzer sehr schnell darüber hinaus geht und einfach mal alles mögliche ausprobiert. Zuerst sind die Tester meist etwas schüchtern. Denn natürlich ist es schon irgendwie komisch wenn man weiß, dass da eine lebende Person ist und man sich vorstellen soll, dass es eigentlich ein Computer ist. Das geht uns tatsächlich auch so. Man muss sich schon eben auf diese Rolle einstellen und auch ein wenig die Scham überwinden.
Aber danach ergeben sich extrem spannende Interaktionen und Konversationen. Denn sobald ein Nutzer über die Standard-Sätze hinausgeht, müssen auch wir oftmals improvisieren. Wir probieren auf jede Frage oder Anweisung des Nutzers eine passende Antwort zu geben. Manchmal klappt das ganz gut und manchmal geht das mächtig daneben. Das ist dann Teil des Learings.
Denn über diese Form der Interaktion lernen wir extrem viel: Zum einen welche Sample Utterances ein Nutzer für bestimmte Intentionen nutzen würde. Wir schreiben so weit es geht die Aussagen der Nutzer gleich mit. Dazu nehmen wir meisten die Sessions mit Genehmigung des Nutzers aber auch auf. Dann kann man nachträglich nochmal nachhören was der Tester genau gesagt hat.
Daneben hilft dieses freie Fragen des Testers auch neue Nutzungsszenarien des Skills herauszufinden. Denn wenn ein Skill mehr können soll als lediglich eine Lampe an und aus zu machen, dann ist es oftmals schwierig die relevanten Intentionen vorab zu kennen. Genau dafür ist diese Methode ideal. Die Tester gehen extrem schnell einen Schritt weiter und probieren Dinge aus. Und das sind meistens jene Dinge, die ihnen als erstes in den Kopf kommen. Wir merken hier immer wieder, dass sich dann schnell Intentionen von unterschiedlichen Nutzern decken und können so die Fähigkeiten des Skills neu modellieren.

Insgesamt also eine sehr einfache und spannende Art eine Skill-Idee frühzeitig abzutesten. Man muss sich kurz an das Setting und die Improvisation gewöhnen, aber dann kann man extrem viele Learnings aus dieser Nummer herausziehen.
Für uns ist das aktuell der beste Weg potentielle Nutzer frühzeitig in die Entwicklung eines Skills einzubinden und unsere Vorstellungen mit denen der Nutzer-Wirklichkeit gegenzuchecken.

Was wir nun gerade überlegen ist, ob wir für alle Skill Entwickler einen Rahmen schaffen könnten, wo man gemeinsam sehr einfach Skill Ideen abtesten könnte. Denn manchmal ist es gar nicht so einfach geeignete Tester zu finden und die eigenen Freunden sind auch nur bedingt gute Tester. Die sind oftmals zu voreingenommen und geben zu gutes oder zu schlechtes Feedback.
Daher mal meine Frage an alle Hörer da draußen: Wäre so etwas spannend für Euch? Würdet Ihr so einen Rahmen nutzen?
Wir könnten uns zum Beispiel einen Slack Channel vorstellen. Slack werden die meisten kennen. Es ist ein Tool um in Teams und Gruppen bestmöglich zu kommunzieren. Jeder, der eine Skill Idee abtesten möchte, kann die relevanten Infos in den Channel posten und direkt über Slack mit anderen Leuten telefonieren und so den Test durchführen.
Ich könnte mir das sehr gut vorstellen und bin da mal gespannt auf Euer Feedback. Schreibt mir gerne eine E-Mail mit Eurer Meinung an podcast@oneskilladay.de oder auch auf Twitter.

So. Wir haben uns heute angeschaut wie man mit Hausmitteln sehr schnell und effizient Ideen für Skills abtestet und relevantes Feedback einsammelt um den eigenen Skills deutlich besser zu machen. Wir haben uns dazu Paper Prototyping angeschaut und danach eine Methode die wir erstmal Teletest genannt haben. Ich glaube, das sind sehr gute Möglichkeiten vor dem Start der teuren Entwicklung den eigenen Skill signifikant besser und relevanter für die Zielgruppe zu machen und viel über die zukünftigen Nutzer und ihre Bedürfnisse zu erfahren.

Ich hoffe, dass Ihr etwas mitnehmen konntet und freue mich wie gesagt über Feedback dazu ob so eine Art Slack Channel für Dich nützlich wäre.
Wenn diese Folge Dir interessante Inhalte oder eine neue Sichtweise geben könnte, dann würde ich mich freuen, wenn Du mir auf iTunes oder Soundcloud eine Bewertung hinterlässt.
Ansonsten sind alle Infos zum Podcast sowie das Transkript dieser Folge wie immer unter www.oneskilladay.de zu finden.
Ich hoffe wir hören uns bald wieder.
Bis dahin… auf Wiedersehen!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.