„Eine App ist keine Webseite!“
Oft wird Wissen aus der Web-Entwicklung auf die Konzeption von Apps übertragen. Eine App funktioniert jedoch ganz anders als eine Webseite: Sie wird nicht mit HTML/PHP gebaut, sondern nativ programmiert. Das heißt, dass der Programmcode einer App auf ein bestimmtes Betriebssystem (z.B. iOS oder Android) zugeschnitten ist.
Der Vorteil? – Die Hardware der Geräte kann mit genutzt werden. So kann zum Beispiel in einer App auf den GPS-Sensor oder die Kamera des Gerätes zugegriffen werden, was weitaus mehr Möglichkeiten liefert, als die Nutzung einer Internetseite.
„Mehrwert ist mehr Wert!“
Bevor mit der eigentlichen Konzeption einer App begonnen wird, sollte man sich darüber Gedanken machen, welchen Mehrwert die App dem Endnutzer bieten soll. Dazu ist es sinnvoll, aktuelle Prozesse eines “Problems” festzustellen. Im zweiten Schritt macht man sich Gedanken, wie dieser Prozess durch eine App für den Nutzer optimiert werden kann. Hat ein Kunde zum Beispiel eine Internetseite mit einem Foto-Upload, muss der Nutzer mit seiner Kamera oder seinem Smartphone ein Foto schießen, es an den Computer anschließen, das Foto kopieren und über die Internetseite hochladen. Wird der Foto-Upload in einer App ermöglicht, kann der Nutzer die Kamera über die App öffnen und das Foto direkt hochladen.
Daneben ist es sinnvoll, vor der Konzeption Zielgruppen (Personas) zu definieren, um den zukünftigen Nutzern eine optimale User Experience zu bieten. Auch wenn verschiedene Apps ähnliche Funktionen bieten, können sie sich je nach Zielgruppe sehr unterscheiden.
„Besprochen ist besprochen.“
Das Grobkonzept einer App sollte zu Beginn der Konzeptionsphase möglichst mit allen relevanten Projektbeteiligten erstellt und durchgesprochen werden. So ist sichergestellt, dass alle Beteiligten stets das selbe Endergebnis vor Augen haben. Während der Kunde seine Wünsche äußert und von einem Projektmanager betreut und beraten wird, sollten auch Entwickler bei Besprechungen dabei sein, um von Anfang an zu wissen, was später programmiert werden soll.
Bevor die Entwickler anfangen eine Funktion zu implementieren, werden vom Projektmanager und/oder vom Kunden sogenannte User Stories definiert. Diese werden so formuliert, dass der Kern der Funktion klar hervorgeht, die Entwickler aber trotzdem noch genug Freiraum haben, die Funktion je nach Technologie so umsetzen können, dass die Erwartungen des Nutzers in der Funktion selbst, der Usability und der User Experience erfüllt werden.
„Content ist King! – auch für uns Entwickler”
Ein weiterer wichtiger Punkt, der vorher geklärt werden muss, ist die Herkunft der Daten, die später in der App angezeigt werden sollen. Oftmals sind Dienstleister hier vom Kunden abhängig, der die benötigten Texte und Bilder selbst anliefert. Liegen die Inhalte bereits zu Beginn oder einem frühen Stadium der Entwicklung vor, kann effizienter gearbeitet werden, da sich die Bilder und Texte des Kunden oft anders verhalten als Platzhalter-Bilder und Texte, die ggf. erst einmal verwendet werden müssen. Oft sind dann im Nachhinein noch Anpassungen nötig.
Des Weiteren muss vorab geklärt werden, ob die App eine Schnittstelle braucht, um die benötigten Daten anzuzeigen. Ist dies der Fall, muss das Zusammenspiel von App und API geklärt und der Entwicklungs-Vorlauf für die API eingeplant werden. Damit wird verhindert, dass die App-Entwickler ihre Arbeit unterbrechen müssen oder Funktionen bereits ohne die API implementieren müssen.
Hardware
Auch wenn eine native App Hardware-Funktionen wie eine Internetverbindung oder GPS nutzen kann, muss immer bedacht werden, dass es passieren kann, dass diese Hardware nicht zur Verfügung steht – entweder weil das Endgerät diese Hardware-Funktion gar nicht bietet (besonders bei Android sind bestimmte Hardware-Funktionen nicht in jedem Gerät gewährleistet), weil der Nutzer des Gerätes diese Funktionen gerade deaktiviert hat oder weil die Funktion im Moment nicht erreichbar ist (kein WLAN verfügbar etc.).
