Produkte bauen, die Menschen wirklich nutzen
Die meisten Produkte scheitern nicht an schlechtem Code. Sie scheitern, weil sie ein Problem lösen, das niemandem wirklich wehtut. Gute Technik rettet kein falsches Produkt, und deshalb passiert die wichtigste Arbeit oft, bevor jemand einen Editor öffnet.
Beginnen Sie mit einer Person und einem Moment
Ein vages Ziel wie „Teams bei der Zusammenarbeit helfen“ gibt Ihnen nichts zum Testen. „Eine Teamleitung will vor dem Montagsmeeting wissen, was feststeckt“ gibt Ihnen eine Person, einen Moment und einen Weg, um zu erkennen, ob Sie geholfen haben. Schreiben Sie den Satz auf. Wenn das nicht gelingt, sind Sie noch nicht bereit, Screens zu entwerfen.
Machen Sie die erste Version unbequem klein
Jede Funktion in Version eins ist eine Vermutung, und jede Vermutung verzögert den Moment, in dem Sie erfahren, ob Sie richtig lagen. Ein guter Test für jeden Punkt auf der Liste: Was würde kaputtgehen, wenn Sie ihn streichen? Lautet die Antwort „nichts, aber es würde sich unfertig anfühlen“, kann er warten.
Achten Sie darauf, was Menschen tun, nicht was sie sagen
In Interviews sind Menschen großzügig, in der Nutzung ehrlich. Zehn Minuten, in denen Sie jemandem beim Ausprobieren zusehen, lehren Sie mehr als eine lange Liste von Funktionswünschen. Achten Sie darauf, wo jemand zögert, was übersehen wird und was jemand versucht, das Sie nie eingeplant hatten.
Eine kurze Checkliste vor dem Bauen
- Können Sie die Person und den Moment benennen, denen Sie helfen?
- Was tut sie heute stattdessen, und warum reicht das nicht?
- Was ist die kleinste Version, die ihr noch helfen würde?
- Woran erkennen Sie innerhalb von Wochen, ob es funktioniert hat?
Nichts davon ist glamourös, aber genau das unterscheidet ein Produkt, das Menschen immer wieder öffnen, von einem, das sie einmal ausprobieren. Der Code bleibt sehr wichtig. Am meisten zählt er nur, wenn er auf das richtige Problem zielt.
