"Mobile First ist zu klein gedacht", mit dieser steilen These stellt sich Alexander Käppler (Foto) gegen das oft anzutreffende Dogma, eine digitale Anwendung müsse heute zwingend Smartphone-gerecht aufgesetzt werden. Deutlich wichtiger sei der Gedanke "Context First", auf die Anwendungssituation komme es an. Im Rahmen der Online B2B Conference, die am Dienstag digital veranstaltet wurde, erläuterte der Berater der UX-Agentur Diconium seinen Standpunkt an zwei griffigen Cases.

Wie ist die Anwendungssituation des Nutzers?

Im ersten Case ging es um eine Anwendung, mit der Züchter, Tierärzte, Ernährungsberater und Haustierbesitzer die richtige Dosierung von Nahrungsmittelergänzungsstoffen für das Futter von Haustieren berechnen können. Durchaus eine komplexe Sache, bei mehreren tausend verschiedenen Inhaltsstoffen, die zum Teil Wechselwirkungen haben und auch auf den Gesundheitszustand des Tieres genau abgestimmt werden müssen. 

Die ursprünglich aufgesetzte Lösung, im Grunde eine riesige Excel-Liste, wurde als zu kompliziert verworfen, zudem konnten Wechselwirkungen nicht optimal ausgeschlossen werden. Nach längerer Beratung schied auch eine Smartphone-basierte Lösung aus. Käppler erklärt, wie die Entscheidung zustande kam: "Entscheidend ist, in welcher Situation sich der Anwender befindet, wenn er die Anwendung nutzt. Ein Ernährungsberater sitzt die meiste Zeit am Schreibtisch, vor sich den Rechner. Es wäre völlig sinnlos, ein solches komplexes Produkt auf das kleine Display eines Smartphones zu zwängen."

Sogar ein Haustierbesitzer, der bei der Zubereitung des Futters für seinen Liebling Hilfe braucht, würde die in diesem Moment kein Smartphone in die Hand nehmen wollen, denn er hat schmutzige Finger. Käppler und sein Team entschieden sich für eine Desktop-Lösung. Der Experte ist sich sicher: "Mit einer Smartphone-Lösung wären wir vor die Wand gefahren."

Testen in der Praxis ist durch nichts zu ersetzen

Das zweite Projekt, das Käppler auf der Online B2B vorstellte, war eher ein Lehrstück für agile Programmierung. Geplant war eine Anwendung, mit der ein Nutzer sich Lebensmittel merken kann, die er sich gekauft hat - und die ihm dann gut geschmeckt haben. Im Test ging es um verschiedene Sektsorten. Wie kann man sich, wenn man im Laden vor dem Regal steht, an den Sekt erinnern, den man vor zwei Monaten hatte und der so lecker war?

"Ein Brainstorming in der Agentur", so erinnert sich Käppler, "brachte eine lange Liste an Features, die man aus anderen Shopping-Apps kennt und von denen wir glaubten, dass wir sie auch alle brauchen würden." Stattdessen wurde ein "Minimum Viable Product" gebaut, eine App die nur die allernötigsten Grundfunktionen beherrschte. Damit gingen dann die Mitarbeiter auf Einkaufstour und fanden schnell die Funktionen heraus, die sie wirklich benötigten. Einen EAN-Codeleser zum Beispiel, mit dem man schnell überprüfen konnte, ob man den Sekt, den man im Supermarkt in der Hand hält, schon einmal getrunken hat.

Wichtig in dem Zusammenhang, so Käppler, seien dabei Grundsätze der agilen Programmierung

• Schnell bauen
  
• Schnell veröffentlichen
• Schnell testen
• Schnell verbessern
  

Vor allem im Praxistest zeige sich oft, dass eine Anwendung anders genutzt werde als am Reißbrett geplant.

Das dringende Plädoyer des Experten lautet: "Eine Customer Journey beginnt oft nicht auf einem Smartphone-Bildschirm, und oft endet sie dort auch nicht." Entscheidend sei es, sich die Situation genau zu vergegenwärtigen, in der ein Nutzer eine Anwendung nutzt - und dann danach zu überlegen, wie genau man die Anwendung umsetzt.