Aus dem Archiv

So führen Ausschreibungen zum Erfolg

Uhr
von Zahida Huber, Lead User Experience bei Liip

Es gibt viele Herausforderungen in einem Webprojekt. Eine der schwierigsten ist aus Sicht einer Digitalagentur, das richtige Produkt zu bauen. Eine Lösung, die von den Kunden und Kundinnen auch wirklich geschätzt und genutzt wird und gleichzeitig die Businessziele des Unternehmens erreicht.

Als Digitalagentur erhalten wir häufig Ausschreibungen oder ein Request for Proposals (RFP) mit fertig formulierten Lösungen und detaillierten Spezifikationen. Die Unternehmen, die diese RFPs gemacht haben, investieren dann viel Zeit, Geld und Effort in ein Webprojekt, gehen online und sehen erst danach, ob sie ihre Ziele überhaupt erreichen. Oft werden Produkte nicht in dem Ausmass benutzt, wie sich das Auftraggeber und Auftraggeberinnen gewünscht haben. Aber woran liegt das? Und was können Unternehmen schon vor dem RFP tun, um das zu verhindern?

 

Bauen wir erst mal ein Spielzeug für Bären

Bären? Ja genau, Bären. Stellen Sie sich einfach mal vor, Sie wären nicht verantwortlich für ein Webprojekt, sondern Sie müssten ein Spielzeug für Bären entwickeln. Wie würden Sie da vorgehen? Ich nehme an, dass die meisten von Ihnen keine Lösung im Kopf haben und es eher unklar wäre, was dieses Spielzeug können muss oder wie es aussehen soll. Wie spielen denn Bären eigentlich? Was würde funktionieren: etwas, das sich bewegt, etwas, das Töne von sich gibt oder etwas zum Raufklettern? Sie befragen wohl erst mal Experten, lesen Fachliteratur und gehen sicher auch Bären beobachten, um ihr Verhalten zu studieren. Das gibt Ihnen eine bessere Vorstellung davon, was funktionieren könnte. Bevor Sie viel Geld investieren, bauen Sie bestimmt noch ein Testspielzeug und entlassen es bei einer Gruppe freundlicher Bären in die Wildnis. Erst wenn es wirklich funktioniert und die Bären damit spielen, sind Sie sich sicher, dass es sich lohnt, dieses Spielzeug zu produzieren (inspiriert von Lucy Spence’s Designing for Bears).

 

Forschen, beobachten und testen

Wenn Sie also etwas für Bären produzieren, dann ist Ihnen klar, dass Sie wahrscheinlich keine Ahnung haben. Dass Sie forschen, beobachten und testen müssen, um etwas zu bauen, das funktioniert. Wenn Sie etwas für Menschen produzieren, dann ist das oft ganz anders. Es geht uns allen so. Wir nehmen an, wir sind wie alle anderen Menschen auch. Und alle anderen Menschen sind wie wir. Daher denken wir zu wissen, was andere Menschen brauchen und wollen. Daher fühlen wir uns sicher, eine Lösung vorzuschlagen. Die meisten RFPs, die wir bei Liip erhalten, bestehen daher aus fertig formulierten Lösungen. Zudem sind sie meist ohne direkten Kontakt zu den Menschen entstanden, für die das Produkt eigentlich gebaut wird. Damit ist das Risiko sehr gross, dass etwas gebaut wird, was am Ende gar nicht den Bedürfnissen der Nutzerinnen und Nutzer entspricht. Was können Sie stattdessen anders machen?

 

Die richtigen Fragen stellen

Als Designerin habe ich einen ganzen Katalog an Fragen, die ich den Unternehmen stelle, um den Auftrag umfassend zu verstehen und eine sinnvolle Lösung vorschlagen zu können. Die wirkungsvollsten Fragen habe ich gelernt durch den Lean Business Model Canvas:

  • Wer sind die User?

  • Was sind die Top-3-Probleme, die wir für sie lösen wollen?

  • Was ist der Nutzen, den die Unternehmung daraus ziehen will?

 

Erstaunlich häufig können Unternehmen diese Fragen nicht alle aus dem Stehgreif beantworten. Denn sie haben die Kundinnen und Kunden ja noch nicht befragt. Ihr Fokus lag primär auf der Lösung. Aber ein erfolgreiches Produkt besteht nicht nur aus der Lösung, es besteht aus dem ganzen Geschäftsmodell. Nur wenn alle Teile funktionieren, wird das Produkt erfolgreich sein. Wenn Sie sich also nur schon einigermassen sicher sein wollen, dann müssen die Risiko­aspekte des Geschäftsmodells zuerst getestet werden.

 

Ein relevantes Problem für die User lösen?

Die Lösung ist selten der riskanteste Aspekt. Bauen kann man heute fast alles. Viel kritischer ist die Frage, welches Problem Sie überhaupt lösen wollen und wie real und relevant es für die Nutzerinnen und Nutzer ist. Häufig trifft man einfach Annahmen darüber, was sie wollen und brauchen. Aber stimmen diese Annahmen? Es braucht nicht viel, um das schon früh zu validieren. Sie interviewen zehn potenzielle Nutzerinnen und Nutzer des Produktes und stellen ihnen die Top-3-Probleme vor, die Sie für sie lösen wollen. Existieren diese Probleme für die Interviewten oder eher nicht? Sind sie dringend? Welche Lösungen gibt es heute? Sie lassen die Befragten beschreiben und beobachten die Reaktionen. Das kann ganz schön hart sein. Manchmal sind die Reaktionen sehr verhalten. Es braucht also etwas Mut. Sie müssen bereit sein, sich einzugestehen, dass das Produkt vielleicht gar kein Bedürfnis ist. Sie können aber auch erleben, dass die Augen der Interviewten leuchten und dass sie als Erstes davon hören wollen, wenn das Produkt rauskommt. Dann sind Sie auf dem richtigen Weg und das Risiko, dass Sie ein Produkt bauen, das niemand will, ist schon viel kleiner. Zehn Nutzerinnen und Nutzer sind schnell gefunden und interviewt. Das braucht weder viel Zeitaufwand noch grosse Kosten, aber der Nutzen aus diesen Einsichten hat oft einen grossen Einfluss auf das Endprodukt.

 

Der kleinste Nutzen, der unser Projekt zum Erfolg macht?

Häufig sind Ziele für ein Webprojekt eher vage formuliert und schlecht messbar. Es ist schwierig, klare Zahlen festzulegen. Aber bevor Sie eine Menge Zeit und Geld investieren, sollten Sie doch festlegen, was der kleinste Nutzen ist, der das Projekt zum Erfolg macht. In klar messbaren Zahlen, zum Beispiel: "Wir wollen 10 Millionen in 3 Jahren verdienen." "Unsere Mitarbeiter sollen 200 Stunden Arbeitszeit pro Monat einsparen." Oder: "5000 Personen sollen diesen Artikel lesen." Wenn Sie diese Ziele offen diskutieren, sehen Sie schnell, ob diese realistisch sind. Manchmal sind sie es nicht. Es kommt auch vor, dass Projekte in diesem Stadium fallen gelassen werden, dann haben Sie nicht unnötig Geld ausgegeben. Wenn die Ziele aber realistisch sind, dann haben Sie ein weiteres Risiko reduziert. Und Sie haben sehr viel Fokus dazugewonnen. Je klarer die Ziele sind, desto klarer ist auch, was gebaut werden muss.

 

Funktioniert die Lösung?

Wir erhalten von Unternehmen oft eine lange Liste von Funktionalitäten. Häufig ist aber unklar, was davon wirklich benötigt wird und den Nutzerinnen und Nutzern echten Mehrwert bringt. Es lohnt sich, schon vor dem RFP einen Prototyp zu bauen und zu testen. Er muss nur ein minimales Set an Funktionalitäten enthalten und kann sehr einfach gehalten sein. Sie fragen potenzielle Nutzerinnen und Nutzer, welche Funktionalitäten besonders nützlich waren, worauf sie verzichten könnten und was noch fehlt, um das Problem für sie zu lösen. So lernen Sie, zu unterscheiden, was wirklich funktioniert und benötigt wird, und was weglassen werden kann. Die lange Liste von Funktionalitäten verkürzt sich und Sie haben mehr Gewissheit, etwas zu bauen, das auch funktioniert.

 

Erforschen und erfahren statt voraussetzen

Um ein Produkt zu bauen, das die Nutzerinnen und Nutzer lieben, beginnen Sie am besten mit der Haltung, dass Sie keine Ahnung haben und genauso wenig über sie wissen wie über Bären. Anstatt Annahmen zu treffen, was User brauchen und wollen, beobachten und erforschen Sie sie. Im Idealfall im gesamten Prozess, von der ersten Idee bis zum Go-live und darüber hinaus.

Um einen gut vorbereiteten RFP abzugeben, empfehle ich Ihnen also folgendes Vorgehen (am besten bereits in Zusammenarbeit mit einer Digitalagentur):

  • Den Lean Business Model Canvas ausfüllen

  • Die riskantesten Aspekte des Canvas identifizieren und testen

  • Testen, ob die User das Produkt wollen
    10 Interviews mit potenziellen Nutzerinnen und Nutzern führen

    Top 3 Probleme vorstellen, die das Produkt löst: Sind diese Probleme real und relevant für die Nutzerinnen und Nutzer? Wie lösen Nutzerinnen und Nutzer diese Probleme heute?

  • Testen, ob die Unternehmensziele erreicht werden können
    Ein minimales Erfolgskriterium festlegen: Das kleinste Resultat, welches Ihr Produkt in 3 Jahren zum Erfolg macht

    Messbare Zahlen festlegen

    Prüfen, ob die Anforderungen realistisch sind

  • Testen ob die Lösung funktioniert
    Einen einfachen Prototypen bauen und mit potenziellen Usern testen: Welche Funktionalitäten sind nützlich? Was fehlt noch? Minimales Feature-Set identifizieren?

 

Das klingt nach viel Aufwand, aber das meiste lässt sich auch mit einfachen Mitteln und in kurzer Zeit umsetzen. Und je früher Sie lernen, ob Sie Ihre Ziele erreichen, desto besser, oder?

Webcode
DPF8_195723