Wie das im Kickoff aussieht
Wir hatten zum Beispiel ein Unternehmen, das neben dem neuen Gesamtauftritt auch eine App wollte, und statt über Plattformen und Zeitpläne zu reden, haben wir gemeinsam erstmal genauer hingeschaut. Was soll die App eigentlich lösen? Für wen genau? Und braucht es dafür wirklich eine App? Am Ende war die Antwort Nein, eine gute Website reicht.
Das ist keine besonders heldenhafte Geschichte, und genau deshalb erzähle ich sie: Niemand im Raum war schlauer als die anderen, die Frage war bis dahin nur nie gestellt worden, weil die App irgendwann in einer Präsentation gelandet war und seitdem einfach dazugehörte. So etwas passiert in ziemlich vielen Projekten, und weil es meistens erst beim Bauen auffällt, hängen dann schon Zeitplan, Budget und ein paar Erwartungen daran.
Die Nielsen Norman Group argumentiert seit Jahren in dieselbe Richtung, nämlich dass eine App sich vor allem dann lohnt, wenn der Anwendungsfall wirklich mobil ist und oft wiederholt wird, und dass eine gut gemachte Website sonst der günstigere und robustere Weg ist. Es gibt aber eben auch den anderen Fall, in dem eine App genau richtig ist: In unserer Arbeit an der BVB-App war nie die Frage, ob es sie braucht, sondern nur, was sie können muss.
Warum wir das überhaupt fragen dürfen
Ich glaube, genau solche Fragen sind ein wichtiger Teil unserer Arbeit als Agentur. Wir kommen von außen rein und wissen erstmal ziemlich wenig, und das ist auch gut so. Denn dadurch fragen wir auch bei Dingen nochmal nach, die eigentlich längst klar scheinen, und in einem Unternehmen macht das nach ein paar Monaten niemand mehr, weil die Entscheidung dort inzwischen zum Inventar gehört.
Das ist übrigens kein Misstrauen gegenüber der Idee und erst recht keine Ausrede, um weniger zu bauen. Eine Agentur, die alles nickt, was im Briefing steht, verdient kurzfristig mehr und liefert am Ende ein Produkt, über das sich niemand traut zu sagen, dass es keiner benutzt. Deswegen steht die Frage bei uns am Anfang und nicht in der Retrospektive.
Und sie hat einen angenehmen Nebeneffekt, den wir bei Silberpuls inzwischen fest einplanen: Sobald jemand sie einmal ordentlich beantwortet hat, ist die Entscheidung im Team begründet und nicht mehr nur vorhanden, und das hilft später bei jeder Diskussion darüber, was in die erste Version gehört und was erst in die zweite.
Gerade bei KI
Gerade bei KI finde ich das ziemlich relevant, weil technisch plötzlich sehr viel geht und man entsprechend schnell bei Fragen landet wie: Können wir KI hier einbauen? Können wir das automatisieren? Können wir dieses Feature bauen? Kann man alles fragen, und die Antwort lautet inzwischen fast immer ja.
Aber vorher würde ich wahrscheinlich einmal die nervige Frage stellen: Braucht es das? Denn ein Assistent, der auf einer Seite sitzt, auf der die Leute eigentlich nur eine Telefonnummer suchen, ist kein Fortschritt, sondern ein zusätzliches Fenster, das man wegklicken muss. Unsere KI-Prinzipien fangen deshalb nicht bei den Modellen an, sondern bei der Frage, welches Problem das Ding lösen soll.
Das Ehrliche daran ist, dass die Antwort auch hier oft Ja lautet, nur eben für etwas anderes als gedacht: Aus dem Chatfenster wird dann eine bessere Suche, sauberere Daten oder ein Formular, das die Hälfte der Felder von allein ausfüllt. Das fällt anschließend niemandem als KI auf, obwohl genau dort der Nutzen sitzt, und ehrlich gesagt ist das auch der Teil, den wir am liebsten bauen.
Was das für euer nächstes Projekt heißt
Wenn ihr ein Projekt startet, dann schreibt zu jedem großen Baustein einen Satz dazu, welches Problem er löst und für wen genau. Überall da, wo dieser Satz nicht zustande kommt, habt ihr entweder das Problem noch nicht verstanden oder braucht den Baustein eben nicht, und beides wisst ihr besser vor dem Angebot als hinterher im dritten Sprint.
Das Zweite ist unbequemer: Fragt bei den Dingen nach, die alle für geklärt halten. Die App, das Portal, der Login, die zweite Plattform für den Innendienst. In Webprojekten ist das oft der Posten, der den Zeitplan trägt, und wenn er fällt, wird der Rest besser statt kleiner.
Und wenn ihr schon live seid, hilft ein Blick auf die Nutzung mehr als jede Diskussion. Ein UX Audit zeigt ziemlich schnell, welche Bereiche wirklich benutzt werden, und es ist erstaunlich, wie oft das teuerste Feature im Produkt das einsamste ist.
