Die Idee: eine Social Media Plattform für Schlaumeier

Die Grundidee schlummert schon sehr lange bei uns und kursiert seit einigen Jahren im Büro. Grundsätzlich hat jeder Mensch ein Mitteilungsbedürfnis – manche mehr, manche weniger. Wir unterstützen einige unserer Kunden im Social Media / Performance Marketing. Dabei lernt man Einiges darüber, was Menschen gerne posten, liken und kommentieren – v.a. bei Facebook. Besonders gut gehen provokante Sprüche, die werden 100-fach kommentiert oder mit Emojis versehen.

Menschen wollen Recht haben

Was ist also die Idee: Wir entwickeln eine Social-Plattform für Schlaumeier, über die man Behauptungen aufstellen und darüber abstimmen lassen kann. Nach dem Motto: “Ich hab’s dir doch gesagt”. Man kann also eine Vorhersage treffen, z.B. “Donald Trump wird spätestens im Oktober 2017 nicht mehr regieren”. Die Vorhersage kann man teilen und andere Leute darüber abstimmen lassen. Ist der Tag der Wahrheit gekommen, bekommt man eine Email und weiß nun endgültig, ob man Recht hatte.

Das Team

Ich könnte jetzt lang und breit ausholen und erklären, welche Positionen man besetzen muss, um so ein Projekt umzusetzen: Zunächst einmal braucht es jemanden, der das Konzept und die User Stories ausarbeitet, sich um die graphische Gestaltung kümmert usw. Dann einen Programmierer für die logischen Parts und das Backend. Und dann einen Entwickler für das Frontend, also die Komponenten, die nachher den coolen und smarten Look der App ausmachen.

In Wirklichkeit hat sich die Teamkonstellation bei dem Projekte mit einem Fingerschnippen ergeben. Kaum habe ich die Idee vorgetragen, waren die Anderen nicht mehr zu bremsen. Und hat glücklicherweise perfekt gepasst: Doni (Backend), Andreas (Frontend) und ich (Konzept, UX / UI). Auch hier haben wir uns bewusst limitiert und das Team klein gehalten, um agil vorgehen zu können. Eine Entscheidung, die wir nicht bereut haben.

Tagebuch

Tag 1: Es geht los

Wie gesagt ist die Grundidee relativ einfach. Das Problem bei Ideen: man muss sie konkretisieren, sonst sind sie nicht umsetzbar. Wir setzen uns also an den Tisch und überlegen, was es braucht, um die Idee umzusetzen. Zunächst einmal zur Technologie: Weil immer mehr Menschen ihr Smartphone als Computer Ersatz verwenden, entwickeln wir eine rein mobile Anwendung. Knallhart reduziert: Ohne Desktop-Version, ohne Schnickschnack. Und weil die Akzeptanz bei Browseranwendungen am Höchsten ist, wird es eine Web-App. Native Apps für Android und iOS vielleicht später, aber nicht jetzt.

Knallhart reduziert: ohne Desktop-Version, ohne Schnickschnack

Dann sehen wir uns die Konkurrenz an: Was gibt es für Plattformen, die eine ähnliche Zielgruppe bedienen. Wie viele Fans haben sie bei Facebook? Wie funktionieren sie? Wie funktioniert das Marketing dahinter? Wie können wir die Zielgruppe ansprechen usw.

Die Learnings übertragen wir auf unsere Idee und fragen uns immer wieder: wie muss der Einstieg in unsere App sein, wie muss der zentrale View aussehen. Eine Idee setzt sich schließlich durch: Hot or Not hieß es vor ein paar Jahren, heute heißt es Tinder. Im Endeffekt hat der Nutzer in der Mitte ein Bild und darunter zwei Buttons, einer rot und einer grün. Damit ist das Grundkonzept für die Bedienung geboren.

Tag 2: Konzept/Wireframe

Jetzt, nachdem die Idee steht und wir eine grobe Ahnung von der Art entwickelt haben, wie der User die App verwendet, wird’s graphisch. Als Erstes starten wir mit einem Mockup, also einer Schwarz-Weiß-Skizze. Diese enthält alle Navigationselemente, Buttons und Funktionen, die wir in der App brauchen.

Das Endresultat ist ein Klickdummy. Der sieht zwar noch nicht schön aus, aber man kann die App schonmal testen, herumzeigen und erstes Feedback einholen. Wir nutzen dafür Invision. Es ist großartig, die App auf dem Smartphone mitzunehmen, darin herumzuklicken und schonmal ein erstes Gefühl dafür zu entwickeln, wie sie sich fertig anfühlt.

Mit dem Mockup werden Fragen der grundsätzlichen Bedienung der App (UX) geklärt

Bis heute haben wir uns noch nicht viele Gedanken darüber gemacht, wie wir das Kind eigentlich nennen sollten. Aber langsam wird es Zeit dafür! Bevor wir den Look & Feel der App entwickeln auf jeden Fall, weil oft der Name ja teilweise die Formsprache mit bestimmt. Also mal wieder ein Brainstorming, Domainnamen recherchiert, Wortkombinationen ausprobiert. Irgendwas Rechthaberisches muss her… Deutsch, Englisch oder irgendwas außergewöhnliches ist am Anfang noch nicht klar. Doch dann der Vorschlag: toldyou.me – und alle sind sofort dabei! Also der Name ist es….

Tag 3: Die Logik

Nachdem das Mockup steht und alle Funktionen definiert sind, machen wir uns an das Backend. Das ist der Part, von dem der Nutzer nichts mitbekommt, die Prozesse im Hintergrund. Oder – um in Bildern zu sprechen – Fahrwerk, Motor und Getriebe. Um den Lack kümmern wir uns später, jetzt müssen wir erstmal fahren lernen. Will heißen: jetzt wird der Code programmiert, der für die Berechnungen, Speichern, Facebook-Login, das Anlegen von neuen Claims, das Auto-Generieren von Bildern für Facebook, Ratings usw. zuständig ist.

Wir nutzen dafür Python Django, das hat sich schon bei anderen Projekten als Backend bewährt. Außerdem müssen die Views für das Frontend definiert und alles soweit vorbereitet werden, dass man die Seite nachher “schön” machen kann. Das Resultat sieht zwar noch ziemlich rudimentär aus, kann aber im Grunde schon alles, was wir brauchen. Also man kann Claims lesen, top oder flop klicken, sich mit Facebook einloggen und die Results sehen. Passt also erstmal. Wir sind für’s Erste zufrieden!

Tag 4: Alles eine Frage der Styles

Ich habe es ja oben schon erwähnt: bisher ist der Look noch sehr rudimentär. Aber immerhin haben wir schon einen coolen Namen – das ist was, auf dem wir aufbauen können. toldyou, I told you, Ich hab’s doch gesagt…. im Prinzip geht es um’s Rechthaben. Und um Kontroversen, also gegensätzliche Meinungen. Was wir brauchen ist ein fresher, nicht zu schüchterner Look. Rot als Grundfarbe ist aggressiv, das passt schonmal. Wir haben sie aber um ein paar Grad abgeschwächt und minimal pink eingefärbt. Perfekt. Das Aggressive unterstreichen wir mit einem Blitz als Erkennungsmerkmal. Und jetzt entwickeln wir noch eine Farbpalette, recherchieren verschiedene Schriftarten und:

Voila! Der Look steht.

Anschließend machen wir uns an den Style der App. Wir arbeiten dafür mit Sketch. Wir arbeiten jetzt alle Views graphisch aus, für die wir vorher das Mockup erstellt haben. Was dabei ziemlich smart ist: wir können die Views nach und nach im Invision-Klickdummy austauschen und so testen, ob die Buttons groß genug sind, die Auflösung passt usw. Und so kommen wir nach und nach zu einem User Interface für toldyou.me.

Neben den offensichtlichen Views, also denen in der App, warten aber noch einige andere stilistische Herausforderungen auf uns. Zum Beispiel brauchen wir eine Style-Definition für die Bilder, die Nutzer bei Facebook Sharen können. Und wir müssen uns die Logik überlegen für die Ergebnisse, wenn jemand einen Claim bewertet hat. Das ist insofern kompliziert, weil wir uns jeden Fall überlegen müssen, der auftreten kann. Nur ein Beispiel: wenn jemand mit dem roten “No” Button einen Claim bewertet hat, sieht er die Statistik für die anderen Nutzer auch in roter Farbe. Das macht es für ihn intuitiver.

Mit dem Invision-Prototyp kann man sich in der „App“ herumklicken, noch bevor die erste Codezeile programmiert ist

Als letztes stellen wir alle Grafikdateien in Zeplin bereit. Das ist ein Tool, das die Zusammenarbeit zwischen Designern und Programmierern verbessert. Alle Designelemente, Farben, Schriften, Maße usw. können direkt dort eingesehen und heruntergeladen werden – wenn man mag, sogar als CSS.

Tag 5: Das Frontend programmieren

Was bis jetzt nur als Bilder und Klickdummy existiert, muss jetzt echt und wahrhaftig programmiert werden. Diesen Teil nennt man Frontend Entwicklung, es geht also darum, der App ein Gesicht zu verpassen. Gottseidank haben wir uns aufgrund der selbst auferlegten 10-Tage Limitierung auch beim User Interface stark limitiert. Insgesamt umfasst die App 7 Views. Außerdem haben wir den radikalen Ansatz gewählt, nur eine mobile Version der App zu programmieren. Kommt ein User von einem Desktop-Computer auf die Website, bekommt einer eine Nachricht:

“Sorry! Only for Mobile.”

Radikal reduziert: toldyou.me funktioniert nur auf dem Smartphone

Für das Frontend nutzen wir bewusst kein Framework und keine Libraries außer jQuery, um die Seite möglichst schlank zu halten. Wir verwenden nur 1 Schriftart in verschiedenen Schnitten und die Hintergründe werden dynamisch aus Vektordateien generiert. Insgesamt kommen wir so auf nur 300 kb Dateigröße. Das ist auch wichtig, da Performance zu den wichtigsten Faktoren zählt, wenn es nachher um die Vermarktung der App geht.

Maximal minimal: die App ist nur 300KB groß

Nachdem die ersten Views fertig sind, fangen wir schonmal mit den ersten Tests an. Dabei fällt uns eine gewichtige Sache auf, die wir bisher nicht bedacht hatten. Wir sind alle euphorisch dabei, testweise Behauptungen ins System zu klopfen. “In 3 months I will buy my first Tesla”… “In 30 minutes I will buy something to eat” … usw. Das System soll ja offen sein, so dass alle User eigene Claims aufstellen können.

Das Problem: Niemanden interessiert, was ein “Irgendjemand” tut oder tun wird. Also es wird leicht sein, Nutzern eine Meinung zu Donald Trump oder zur Erderwärmung zu entlocken. Aber wer soll sich dafür interessieren, was Vera O. zum Mittagessen hatte. Das stellt unser gesamtes Konzept in Frage. Außerdem haben wir noch ein zweites Problem: erlauben wir es den Nutzern, eigenen Content einzustellen, müssen wir auch gewährleisten, dass keine illegalen, sexuellen oder andere unerwünschte Inhalte auftauchen. Und auch wird es schwierig sein, ein gewisses Qualitätslevel zu halten.

Noch weiter reduzieren: Was uns ausbremst, wird gestrichen.

Wir halten also Kriegsrat und beschließen: erstmal gibt es keinen User Generated Content. Wenn wir diese komplexe Problemstellung jetzt angehen, können wir niemals den selbst-gesteckten 10-Tage Zeitplan halten. Es ist eine pragmatische und radikale Entscheidung – aber sie ist notwendig! Das wird uns im weiteren Projektverlauf immer mehr klar. Die Lösung: Wir denken uns also selbst coole Claims aus. Die Funktion zum Selber-Publizieren ziehen wir vielleicht in einer nächsten Version nach, wenn das Produkt angenommen wird.

Tag 6: Jetzt müssen wir uns Inhalte ausdenken!

Gesagt – getan. Wir machen uns also daran, uns die ersten Inhalte für die App auszudenken. Was könnte die Leute interessieren? Uns fallen spontan 5 Themengebiete ein: Politik, Promis, Futurismus, Sport und Filme. Also wälzen wir Internetforen, Blogs und Newspages und recherchieren… recherchieren, bis uns die Köpfe rauchen! Wer hätte gedacht, dass es so anstrengend ist, sich ein paar Statements auszudenken.

Einige Beispiel-Behauptungen:

• At least on July, 2050 beaming becomes reality.
• Until 2060 living on the moon will be in posse.
• Until Sep, 2040 cars will be replaced by flying cars.
• No later than 1st Dec, 2030 every household will have a contriver.
• Until 2029 living on the mars will be possible.
• Until 2020 the number of the global population will climb up to 8 billion.
• At least in 2027 human cloning will be licit.
• No later than Aug, 2035 pets will be able to speak.
• At least in 2057 Germany will be at the seaside because of global warming.
• At least in 2028 the Berlin airport will be completed.
• Until 2025 the antarctic will shrink by half.

Parallel arbeiten wir noch an verschiedenen Details der App. Zum Beispiel was die Datumsformatierung angeht: Wir haben Claims, die sich nur auf ein Jahr beziehen, z.B. “In 2022 wird es fliegende Autos geben”. Andere Claims müssen da schon spezifischer sein, z.B. “Spätestens am 27. September 2017 wird Donald Trump nicht mehr im Amt sein”. Wichtig ist, dass diese Funktion sauber programmiert ist, bevor wir anfangen, die mühsam recherchierten Behauptungen ins System einzupflegen. Es beginnt ein Rennen mit der Zeit… das wir knapp gewinnen. Exakt um 17 Uhr ist beides fertig – wir haben 50 Claims aufgestellt und das Backend fertig programmiert. Wir können also anfangen, das System damit zu füttern.

Tag 7-9: Testen, testen, testen

Jetzt – nachdem alles fertig ist – geht es an’s Testen. Dieser Part ist der, der am meisten in Softwareprojekten unterschätzt wird. Von Kunden heißt es meistens: es muss halt funktionieren. Und natürlich erwarten wir, dass alles einwandfrei funktioniert.

Der Image-generator sorgt dafür, dass automatisch Bilder im perfekten Bild/Text-Verhältnis für Facebook erzeugt werden

Ich habe mal einen Artikel über Microsoft gelesen. Dort hieß es, dass im Team auf jeden Entwickler ein Tester kommt. Ich weiß nicht, ob das immer noch aktuell ist. Allerdings kann ich aus Erfahrung sagen, dass das Verhältnis bei uns mindestens ⅓ Testen zu ⅔ Programmieren ist. Bei diesem Projekt ist das nicht anders. Wir testen auf Android und auf iOS im Facebook Browser. Wir testen alle Navigationselemente, wir testen alle erdenklichen User Stories: ein Nutzer klickt auf einen Facebook-Beitrag, kommt dann in die App, ist aber noch nicht eingeloggt. Er macht das Selbe, ist aber schon eingeloggt. Er klickt den Daumen hoch, danach shared er die Ergebnisse bei Facebook. Und so weiter… Und es treten an den unerwartetsten Stellen Fehler auf. Das Absurde: Behebt man einen Fehler an einer Stelle, tritt manchmal an einer anderen Stelle ein anderer Fehler auf. Behebt man diesen wiederum, tritt ein anderes Problem auf.

Etwa 1/3 des Aufwands entfällt auf Testen

Obwohl es sich hier um ein überschaubares Projekt handelt ist der Aufwand im Testen und Bugfixing immens. Immer wieder Tasks in github schreiben, Andere, die auf “to test” stehen kontrollieren, schließen oder wieder kommentieren. Das geht so 3 Tage lang und wir bezweifeln irgendwann, ob wir es noch in unserer selbst gesetzten 10-Tage Frist hinbekommen. Aber schließlich klappt es: wir sind fleißig, hart und irgendwann sagt die Bugliste: 0 Tasks left – cool!

Tag 10: Wir sind online!

Endlich: wir sind fertig! Doch: Moment! Wie bzw. wo launchen wir die Seite jetzt eigentlich? Nein, Spaß beiseite…. die Marketingstrategie haben wir uns natürlich schon vorher überlegt. Wir wollen über Facebook eine Community aufbauen und so Traffic auf die Seite bringen. Wie schon bei vielen anderen Projekten vorher. Trotzdem müssen wir erstmal noch die Facebook Page aufsetzen und mit den ersten Inhalten füllen. Dann setzen wir Buffer auf und schreiben die ersten Beiträge. Wir wollen verschiedenen Claims aus der App nehmen und mit witzigen Sprüchen auf der Facebook Seite verbreiten.

Ein letztes Mal rauchen die Köpfe: wir brauchen jetzt ein paar witzige Sprüche und Emojis, die zu den Claims passen. Und schließlich: Enter! Der erste Claim ist raus, wir sind online! Und stolz 😀

We made it!

Fazit

Kurz gesagt: Ja, es ist absolut möglich, in 10 Tagen einen MVP zu entwickeln. Was es hierzu braucht ist knallharter Pragmatismus und ein Fokus auf die wesentlichen und notwendigsten Kernfunktionen. Wir haben den Rotstift angesetzt, wo immer wir konnten und haben uns bei jeder Funktion gefragt: braucht es das unbedingt?

Der zweite wesentliche Aspekt ist die Erfahrung: wir haben uns in vorherigen Social Community Projekten Handwerkszeug angeeignet, welches hier essentiell notwendig war. Ohne Selbstlob möchte ich behaupten, dass das Projekt ansonsten niemals in der Zeit und Qualität umsetzbar gewesen wäre.

Allerdings trügt der Name, was den Aufwand angeht: In Wirklichkeit waren es in Summe nicht 10, sondern ca. 20 Personentage. Obwohl nicht das ganze Team gleichzeitig und Vollzeit daran gearbeitet haben waren 3 Personen ziemlich gut mit dem Projekt ausgelastet.