Ein Jahrzehnt Erfahrungen mit Apps

Karolina Schilling  Follow on Twitter
UX Designer & Consultant | ks@muppetti.de
15. Dezember 2017

Ein Jahrzehnt Erfahrungen mit Apps

Ich bin seit 2009 mit dabei, da waren Apps noch ganz frisch. Es war ein weltbewegendes Unterfangen eine Android App zu designen und es konnte sehr leicht bei der Umsetzung in einer Katastrophe münden, weil das Android Framework schlecht dokumentiert war…. und wahrscheinlich einfach, weil es in sich schlecht aufgebaut war. Bei iOS war der Einstieg deutlich einfacher, aber auch hier mussten wir – die wir die Pioniere mit Apps waren – erst unsere schmerzhaften Erfahrungen sammeln, von dem was ging und was nicht. Harte Zeiten, damals. Schöne Zeiten, heute. Lies hier meine Erfahrungen und schreibe mir gern eine Nachricht.

Von Null… und dann schick & schlank

Wenn man als Webdesigner zum nativen (also dem vom Hersteller vorgesehenen Designelementen) App Design wechselt, gibt’s ein paar Dinge, die man wissen sollte. Ich bin so jemand, ich habe mit dem Web 2005 Jahren angefangen und seit 2009 Jahren konzipiere und gestalte ich auch Apps. Dabei habe ich eine steile Lernkurve zurückgelegt.

Mit all seinen fertigen FrameWorks, OpenSource Systemen wie WordPress, Typo3, Magento etc. verwöhnt das Web mit Unmengen fertiger Features. Vieles ist Standard, ist einfach schon dabei. Bei einer App erfahre ich das noch immer nicht so. Auch, wenn der App Programmierer Libraries dazunehmen kann und fertige Module integriert, bleibt die ganze App eine hand made Anwendung. Jede Funktion, jeder Wunsch, jedes Detail kostet. Daher bin ich als Designerin angehalten, die App immer so schlank wie möglich zu denken. Schick und schlank.

Noch mehr Absprachen als in der Webentwicklung

Während im Web doch irgendwann klar ist, was alles geht und was nicht, ist es bei Apps nicht so einleuchtend. Zum Einen sind Apps so mächtig wie das Gerät. Je mehr Sensoren, Messtechnik, Hardware das Smartphone hat, desto mehr kann auch eine App. Dieses Mehr ist allerdings nicht über alle Geräte konsistent, so dass es viel anstrengender ist den kleinsten gemeinsamen Nenner zu finden als es bei Webbrowsern der Fall ist. Bei Smartphones passiert eigentlich das, was HTML 5 im Web beenden wollte: eine große Fragmentierung. Viele Geräte, viele Screens, unterschiedliche Betriebssystem-Versionen. Das heißt ganz klar: viele Absprachen, Kompromisse mit den Programmierer-Jungs & – Mädels.

Spezifisches Design vs. gestalterische Freiheit

Irgendwie etwas komisch. Bei Apps geht viel, was Designer erfreut. Farben, Transitionen, Buttons so groß wie wir wollen. Und in meiner Erfahrung sagen die Programmierer „Geht schon“ dazu. Wenn es dann zur Umsetzung kommt, wird klar, dass nicht nur ein Teufel im Details sitzt, sondern 20. Daher ziehe ich für mich das Fazit, zu Beginn mit Standard-Elementen (Navileiste, Sidebar, etc…) zu arbeiten und dem jeweiligen System gerecht zu werden und gleichzeitig der App eine eigene Anmutung zu geben. Das ist nicht leicht. Es soll nach iOS aussehen, nach Android und gleichzeitig soll es auch nach sich selbst aussehen. Daher ist die Experimentierfreudigkeit eher den Erfahrenen vorbehalten. Wenn man einsteigt, ist es sinnvoll, sich die Guidelines von Apple, Google oder Blackberry und sonstwem durchzulesen und sich daran zu halten. Mit jedem weiteren Projekt kommen Erfahrungen hinzu, was geht und was nicht. (Wobei alles geht, aber vorher nicht immer klar ist, wie viel Ar…aufriss es kostet.)

Apps sind nicht responsiv, sondern adaptiv

Was Webseiten nun endlich können und was wir als Designer selbst über das Templating handhaben, ist bei Apps den Programmierern überlassen. Das Frontend muss für die verschiedensten Gerätetypen von der Smartwatch, Smartphone über das Phablet bis zum Tablet vom App Designer konzipiert werden. Die Programmierer legen für Bereiche von Screengrößen oder Gerätetypen eigene Views an. Zum Einen wird das in einem Projekt oft vergessen. Zum Anderen nehmen es wenige Programmierer mit den Abständen und der Ästhetik so genau. Als pure Designer stehen wir daneben und können schwer eingreifen.

Prototyping

Mittlerweile gibt es für das Prototyping coole Tools. Je einfacher sie funktionieren (z.B. InVision), desto mehr basierend sie auf statischen Screens, also unseren Screendesigns. Je interaktiver die Prototyping Tools sind (z.B. Framer), desto mehr müssen wir definieren – Transitionen, Animationen. Und es gibt die Unterschiede zwischen Web-Apps und nativen Apps. InVision basiert auf einer Web-App. Das heißt, mein Kunde sieht die Screens angepasst an seine Screengröße in seinem Smartphone-Browser – das kann mitunter zu Verwirrungen führen, was die wahre Größe der Screens angeht. Framer hingegen hat eine eigene native App zum Ansehen des Prototyps und ist sowieso responsive. Dieser ist dann auf eine Screengröße festgelegt und wirkt dadurch realistischer – und funktioniert nach dem Download des Projekts offline. Bei InVision braucht mein Kunde immer Internet.

Kernnutzen

Eine App ist in ihrem Wesen etwas anderes als eine Website. Eine App ist ein in sich geschlossenes Programm, das eine Sache besonders gut kann. Webseiten sind meist Informationsträger. Das sind Apps nicht. Apps sind Helfer. Daher ist die Konzeption einer App die Konzeption einer Anwendung für einen speziellen Nutzen in einer Situation – den Kernnutzen. Bei klassischen Websites ist der Nutzen oft der Inhalt und der Imageaufbau über die Gestaltung. Durch die klare Abgrenzung der App als eigenständiges Programm und dadurch Produkt, werden wir vom Screen-Designer zum Produkt-Designer. Wir konzipieren und gestalten Software, die einen bestimmten Zweck für eine bestimmte Zielgruppe erfüllt. Bei wie vielen Image-Webseiten hatten wir diese tolle Aufgabe?

Arbeitsbereich & Zukunft

Der Designer ist immer näher am Kunden und der Zielgruppe. Deswegen ist es natürlich sinnvoll, dass er sich auf das Design konzentriert. Dennoch ermöglichten es uns Webtechniken, auch eigenständig mit einem System zu arbeiten. Das ist bei Apps anders, sofern man sich in diesem Punkt nicht fortbildet. Ich denke, dass wir App Designer in Zukunft in die Software für die App-Entwicklung reingehen und dort das Frontend bauen werden, während die Programmierer den „harten“ Code machen. Mit den neuen Versionen von xCode, den Storyboards und SWIFT ist Apple wieder einmal Vorreiter, was diesen Trend angeht und bemüht sich, Designern den Einstieg in die App-Entwicklung leicht zu machen. Tutorials und Bücher gibt’s wie Sand am Meer – der Weg ist offen.