muppetti AppDesign

Tipps & Tools für AppDesigner

Vom Web- zum AppDesigner, Teil 2

Apps machen als Webdesigner?

Apps machen als Webdesigner?

Wenn man als Webdesigner zum nativen(!) AppDesign wechselt, gibt’s ein paar Dinge, die man wissen sollte. Ich bin so jemand, ich habe mit dem Web vor fast 10 Jahren angefangen und seit 7 Jahren konzipiere und gestalte ich auch Apps. Dabei habe ich eine steile Lernkurve zurückgelegt. Und das ist mein persönliches Fazit:

Von Null. 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 empfinde ich das nicht so. Auch, wenn der App-Programmierer Libraries dazunehmen kann und auch 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.

Mehr Absprachen.Während im Web doch irgendwann klar war, 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 App-Programmierern.

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, 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, nach Windows 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 und Windows 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 AppDesigner 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 schon 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. AppCooker, Pixate), desto mehr müssen wir definieren. 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. AppCooker hingegen hat eine eigene native App (App Taster) zum Ansehen des Prototyps. 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. Der Designer ist immer näher am Kunden und auch 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. Und dann bekommen wir auch mehr Eigenständigkeit zurück!

Nächster Artikel, Teil 3: Aufgaben des AppDesigners in einem mittelgroßen App Projekt.