Warum sich das kleinere Projekt zu beschreiben lohnt
Öffentliche Produktgeschichten behalten meist die großen Zahlen und verlieren alles, was davor kam. CUTE lohnt sich gerade deshalb, weil es früher entstand, kleiner war und von zwei Personen gebaut wurde. Es zeigt die Bedingungen, unter denen die spätere Erfahrung erworben wurde.
Der erhaltene Eintrag weist es als Casual-, Trivia- und Wortspiel aus, veröffentlicht im Dezember 2018. Ein archivierter Dienst schätzte es später auf rund 250.000 Spieler im Monat, doch das ist eine Schätzung eines Dritten und keine Zahl aus unserer eigenen Analytik.
Das Spiel selbst ist offline, und es sind nur wenige Screenshots erhalten. Hier geht es deshalb um das Produkt und unsere Arbeitsweise statt um eine detaillierte Führung, die aus einem lückenhaften Archiv rekonstruiert wurde.
Zu zweit ist der Umfang die Strategie
Ein kleines Team ist nicht einfach eine langsamere Ausgabe eines großen. Es trägt ein anderes Risiko. Dieselben zwei Personen, die eine Funktion bauen, testen sie auch, veröffentlichen sie, lesen die Zahlen, beantworten die E-Mails, wenn sie kaputtgeht, und entscheiden, was als Nächstes kommt.
Deshalb zählt mehr, was eine Funktion im Unterhalt kostet, als was sie im Bau kostet. Etwas, das an einem Tag hinzugefügt ist, aber einen dauerhaften Strom an Inhalten, Moderation oder Support erzeugt, ist meist ein schlechtes Geschäft. Es überlebt die Fassung, deren gesamte Oberfläche in das Team passt, das Sie wirklich haben.
Facebook Instant Games gab uns einen Hebel, den wir nicht selbst hätten bauen können: Es lief im Browser, kümmerte sich um Identität, saß mitten in Gesprächen und brauchte keine Installation. Richtig war, sich darauf zu stützen und das Spiel klein genug zu halten, dass jeder von uns beiden es ohne Zögern ändern konnte.
Halten Sie die Entscheidungen im selben Raum
Zu zweit haben Anforderungen keinen Platz, durch Dokumente und Besprechungen zu wandern, was ein Vorteil ist, solange die Schleife ehrlich bleibt: etwas bemerken, sich auf die kleinste nützliche Änderung einigen, sie veröffentlichen, nachsehen, was passiert ist.
Die Falle ist, Prozess durch Erinnerung zu ersetzen. Auch zwei Personen brauchen Einigkeit darüber, welche Zahl wichtig ist, Notizen dazu, was sich in einer Version geändert hat, die Fähigkeit, zweimal gleich zu deployen, und eine kurze Liste ihrer aktuellen Wetten. So viel Struktur macht schneller, weil sie verhindert, dieselbe Entscheidung erneut zu treffen.
Das hilfreiche Werkzeug ist langweilig. Automatische Builds, eine Checkliste vor dem Livegang, eine Fehlermeldung und ein paar Kennzahlen, denen Sie trauen, bringen mehr als eine interne Plattform, die selbst zur Wartungsaufgabe wird.
Entwerfen für jemanden, der sich nicht festgelegt hat
Ein Spieler, der Ihr Spiel aus einem Facebook-Beitrag geöffnet hat, hat weit weniger investiert als jemand, der einen App-Store durchsucht und auf einen Download gewartet hat. Das ist die Chance, und es ist zugleich die Einschränkung: Sie haben viel weniger Geduld zu verbrauchen.
Halten Sie den Download klein, machen Sie die erste Handlung offensichtlich, und geben Sie dem Spieler etwas Lohnendes, bevor Sie um Berechtigungen, ein Teilen oder einen Absatz Erklärung bitten. Soziale Funktionen kommen deutlich besser an, sobald jemand versteht, was verschickt wird und warum es seinen Freund interessieren sollte.
Das ist Gestaltung und Technik zugleich. Ein langsamer erster Bildschirm verändert den Trichter, und ein schweres Ressourcenpaket entscheidet still, welche Telefone und welche Länder überhaupt mitspielen können. Auf so einer Plattform gehört die Dateigröße zum Empfang.
Alles, was die Plattform gab, konnte sie auch nehmen
Die Plattform erledigte Arbeit, die zwei Personen vernünftigerweise nicht hätten nachbauen können. Sie kontrollierte zugleich Prüfung, Auffindbarkeit, die Funktionsweise der Identität und das, was wir Spielern schicken durften. Das sind keine Verwaltungsdetails: Sie entscheiden, was Sie bauen können und wer bleibt.
Es lohnt sich, diese Abhängigkeit sichtbar zu halten. Schreiben Sie Ihre Annahmen auf, bündeln Sie plattformspezifischen Code, wo es geht, und wissen Sie, welche Ausfälle das Spiel spielbar lassen. Vor allem: Verwechseln Sie die Reichweite der Plattform nicht mit einer Beziehung zu Ihren Spielern, die Ihnen gehört.
CUTE und alles, was danach kam, profitierte enorm von Facebooks Distribution. Dass heute nichts davon online ist, ist die andere Hälfte dieses Satzes.
Archivieren Sie, bevor die Plattform es für Sie tut
Das Unangenehme daran, Jahre später einen Rückblick zu schreiben, ist nicht, den Code zu finden. Es ist, zu rekonstruieren, was die Spieler tatsächlich sahen: die Bildschirme, den Text im Store, das Erscheinungsdatum, die veröffentlichten Sprachen, was die Zahlen bedeuteten und warum eine bestimmte Entscheidung fiel.
Ein bescheidenes Archiv genügt. Sechs Dinge, festgehalten, solange das Produkt noch lebt:
- Aussagekräftige Bildschirme und eine kurze Aufnahme des Produkts im Einsatz.
- Die Zahlen, die Sie öffentlich nennen würden, mit ihrem Zeitraum.
- Wer im Team war und wofür jede Person zuständig war.
- Die Architektur, auf einer von außen nachvollziehbaren Ebene.
- Den Store-Eintrag, das Erscheinungsdatum und die veröffentlichten Sprachen.
- Einen Absatz dazu, warum es endete.
Das reicht reichlich für eine spätere Fallstudie, ohne irgendetwas Privates über Kunden oder Spieler preiszugeben.
Die dünne öffentliche Spur von CUTE gehört heute zu seiner Lehre. Veröffentlichen zählt, aber genug aufzubewahren, um zu erklären, was man veröffentlicht hat, ist ebenfalls Produktarbeit.
