Jedes Mal, wenn ein Unternehmen mit einem Rebrand an den Start geht, gibt es den obligatorischen „Wir haben wir es gemacht“ Blogpost dazu. Uber hat es getan, AirBnB hat es getan und wir haben es getan.

post-it-notes
Ja, dies sind tatsächlich einige unserer gut aussehenden Mitarbeiter, die Post-its in unser Büro kleben.

Normalerweise springen diese Posts direkt von „gut aussehenden Leuten, die Post-It-Zettel an eine Glasscheibe kleben“ zu „hier enthüllen wir es der ahnungslosen Öffentlichkeit“ und überspringen komplett den eigentlich schwierigen Teil – jede einzelne Seite der Unternehmenswebsite durchzugehen und aus der alten Marke eine neue zu machen.

Wenn du Engineering Manager bei einem Start-up bist, ist die Chance recht hoch, dass du noch nie einen Rebrand machen musstest (da die durchschnittliche Beschäftigungsdauer eines Engineering Managers kürzer ist, als die Lebensdauer einer Marke). Dies gilt umso mehr, wenn du in der San Francisco Bay Area arbeitest, da es bei visuellen Stilen keine Vesting Cliff gibt. Also lass uns dir erzählen, wie wir unseren Rebrand gemacht haben und dann in ein paar konkrete Tipps eintauchen, wie du deinen machen kannst.

Unser Zeitplan

Um die Geschichte nicht allzu lang werden zu lassen, haben wir den Zeitplan auf das Wesentliche gekürzt, auf die Zeit, in der das Engineering-Team beteiligt war. Es wurde auch vor und nach dieser Zeit viel harte Arbeit in die Marke und das Marketing gesteckt, aber aus unserer Perspektive lief das Projekt sechs Monate und in drei davon wurde der Großteil der Arbeit erledigt.

  • Oktober: Uns wird gesagt, dass es zu einem Rebrand kommen wird und dieser möglichst vor Ende des Jahres erledigt sein soll.
  • November: Das neue Design wird festgelegt und ein entsprechender Style-Guide zusammengestellt; ein Zeitplan wird skizziert mit dem Ziel, im Februar mit dem Rollout zu beginnen.
  • Dezember: Die Arbeit in der App beginnt; wir konvertieren ganz alte Seiten zu Asimov (unserem Komponentensystem), wenn sie schon in Asimov sind, konvertieren wir sie zur neuen Marke.
  • Januar: Programmieren, programmieren, programmieren, programmieren! Seiten und Produkte löschen, die nicht wichtig waren. Zeitplan aktualisieren und Deadline für März setzen.
  • Februar: Das ganze Unternehmen hilft beim QA und die Entwicklung geht weiter.
  • März: Rollout, PR, Asset-Scaffolding abbauen.
von bo_rad

Der Rebrand war ein großer Erfolg. Wir haben einen gleichzeitigen Rollout für 4 Produkte an dem Tag durchgeführt, an dem wir es auch geplant hatten. Wir haben zum ersten Mal, seit Gründung des Unternehmens, einen übereinstimmenden Look auf jeder einzelnen Seite der Website erreicht.

Und als Sahnehäubchen obendrauf konnten wir mindestens 150.000 Zeilen Code entfernen, da wir das Produkt gestrafft und jede Menge Marketing Content in unser neues CMS verschoben haben.

Wähle deine Build-and-Release-Strategie

Man kann im Wesentlichen eine von drei Strategien für das Erstellen und den Rollout des neuen Looks wählen:

  1. Alles auf einmal: jede Feature-Entwicklung stoppen, alles umgestalten und mit einem großen Knall ausliefern.
  2. Nebenbei: ein Team aus Front-End-Engineers zusammenstellen, die neben ihren eigentlichen Aufgaben am Rebrand arbeiten, dann alles mit einem großen Knall ausliefern.
  3. Später fertigstellen: alle wichtigen Marketingseiten und Front-of-Funnel-Abläufe rebranden und alles andere aufschieben, bis sie ganz automatisch neu gemacht werden müssen.

Ich kann von keinem Ansatz sagen, dass er der beste ist, aber hier sind ein paar Vor- und Nachteile von jedem.

„Alles auf einmal„ Strategie

Vorteil: fokussiert, bringt das Team zusammen,  weniger Überarbeitung durch Feature-Freeze, günstigeres vorläufiges Scaffolding.

Nachteil: teuer, weniger effizient durch Mitarbeit von Nicht-Spezialisten, steht dem BAU Roadmap im Weg.

„Nebenbei“ Strategie

Vorteil: sich auf Spezialisten verlassen ist effizienter

Nachteil: hohes Risiko, dass der BAU & Rebrand Zeitplan sich gegenseitig im Weg stehen oder überarbeitet werden müssen oder beides, Design wird ohne Budgetdruck zu aufgeblasen

„Später fertigstellen“ Strategie

Vorteil: schnellster & günstigster Launch aufgrund des reduzierten Umfangs.

Nachteil: schlechtes UX, da die Kunden zwischen altem und neuem Design wechseln. Viel Glück dabei, es noch vor dem nächsten Redesign fertigzustellen.

fish
von bo_rad

Für uns war die „Alles auf einmal“- Strategie die richtige Wahl. Wir haben so viel Vorarbeit wie möglich unter dem „Nebenbei“- Modell erledigt, aber wir haben alle an einem Strang gezogen, um die Produkte von einer Marke zur anderen umzustellen.

Wir haben diesen Ansatz aus mehreren Gründen gewählt:

  • Eine uneinheitliche UX mit unterschiedlichem Erscheinungsbild untergräbt die Glaubhaftigkeit deiner Marke. Wir können den Kunden nicht sagen, Design ist ein essenzieller Teil des Unternehmens, wenn wir es nicht vorleben.
  • Unser ganzes Engineering-Team ist voll bei der Sache und wenn alle im selben Boot sitzen, ist dies eine gute Möglichkeit, sich gegenseitig kennenzulernen.
  • Die durchschnittliche Länge der Projekte auf unserer Roadmap war kürzer als die Zeit, die wir für einen Rebrand veranschlagt hatten, und jedes Projekt, das zeitgleich zum Rebrand durchgeführt wird, setzt dich dem Risiko teurer Nachbesserungen und der Gefahr überhöhter Kosten aus.
  • Obwohl 99designs.com sich als einheitliche Seite präsentiert, besteht sie aus verschiedenen Produkten in unterschiedlichen Codebasen unterschiedlicher Sprachen und Größen. Es vereinfacht sowohl unseren Feature-Flag-Code als auch unsere Mitarbeiterplanung.
Homepage wireframe
Mockup-Design der Homepage

Hier sind ein paar andere Situationen, in denen eine bestimmte Strategie passen würde:

  • „Später fertigstellen“: Wenn wir ein paar Nummern größer wären. Es hat einen Grund, dass Google noch nicht zu 100% auf Material Design umgestellt ist. Es gibt zu viele Leute, die für ein einzelnes Projekt einen zu großen Bereich abdecken, als dass man es handhaben könnte.
  • Nebenbei“ ist eine gute Wahl für ein kleineres, monolithisches Team oder Codebase in einer Delivery-Umgebung. In diesen Fällen ist die gleichzeitige Entwicklung nicht zu schwer zu handhaben und was zählt, ist die Effizienz.
  • „Alles auf einmal“ passt besser zu einem kleineren Team, wenn man eher auf Big-Bang-Deployment setzt (was für Web-Teams immer seltener wird, aber bei mobilen Apps normal ist).

Technische Erwägungen

Content-Semantische Namensgebung

Der beste Tipp aus technischer Sicht, um ein zukünftiges Rebrand oder Redesign günstiger oder einfacher zu gestalten, ist, eine Art komponentenbasiertes Framework für dein CSS oder HTML zu wählen. Wir nutzen ein internes Framework namens Asimov, um CSS-Komponenten zwischen Apps zu teilen und BEM für unsere Namens- und Strukturregeln. Ich habe in der Vergangenheit auch schon erfolgreich SMACSS verwendet. Dieser Post über BEM und SMACSS ist eine super Anleitung, welche die beiden Methoden vergleicht.

Indem wir uns für den „Alles auf einmal“-Ansatz entschieden, haben wir uns grob auf einen festen Rahmen (z. B. wie viele Seiten wir überarbeiten werden, nämlich alle) und ein festes Budget (nicht genau, aber wir wussten, dass wir mehr als beim letzten Rebrand 2016 wollten) festgelegt. Der einzig wirkliche Hebel, an dem wir ansetzen mussten, war die „Tiefe“ des Redesigns.

von alvianism

Um das alles zu ermöglichen, wollten wir es dort, wo es möglich war, bei einem CSS-Redesign belassen. Die wichtigsten Marketingseiten, die ein radikales Redesign benötigten, wurden einfach komplett neu in unserem CMS erstellt, mit komplett getrennten Codepfaden. Alles andere bekam lediglich eine neue Oberfläche mit neuen CSS und Assets.

Diese Option – nur ein bedeutendes, oberflächliches Redesign durchzuführen – war uns nur deshalb möglich, weil wir Jahre damit verbracht haben, Stück für Stück auf ein neues Komponentensystem umzustellen. In den Fällen, wo das Redesign einige Änderungen benötigte, haben wir einen Weg gefunden, mithilfe von Backporting die strukturellen Veränderungen in unsere alte Marke einzupflegen, sie wie üblich in die Produktion übernommen und dann den Rebrand an den Komponenten vorgenommen.  

Unsere Disziplin mit BEM half uns auf zwei Arten. Die erste ist, dass der Schwerpunkt in BEM, die Kaskade so klein wie möglich zu halten, es wesentlich sicherer gemacht hat, weitreichende visuelle Veränderungen vorzunehmen, ohne Angst vor einem Rückschritt im Stil haben zu müssen. Der zweite ist, dass wir uns dadurch, dass wir uns darauf konzentriert haben, Komponenten nach ihrem Zweck zu benennen, jegliche Schwierigkeiten erspart haben. .button–primary und .button–secondary gewähren dir wesentlich mehr Flexibilität als .big-green-button und .little-greyed-button.

rebrand-so-many-buttons
Wir hatten so viele verschiedene Buttons!

Build, Deployment und Feature Flipping

Ein weiterer technischer Tipp, den ich geben würde ist, dein Scaffolding nicht zu vergolden. Bei 99designs haben wir eine relativ schnörkellose Continuous-Delivery-Pipeline – ein Entwicklungsprozess im GitHub Flow Style – danach laufen alle Master durch eine Buildkite-Pipeline, welche auf AWS aufbaut und es dort bereitstellt. Wir deployen jedes unserer Produkte mehrmals am Tag und wenn etwas noch nicht ganz fertig für die Öffentlichkeit ist, verbergen wir es hinter einem Feature Flip. Unsere Lösung passte ziemlich gut zu der Art unserer täglichen Arbeit, aber reichte nicht, um alles auf jeder Seite für jedes Produkt gleichzeitig zu ändern.

flip-design

Ursprünglich haben wir versucht, unser Feature-Flipping-System zu verallgemeinern, um größere Veränderungen handhaben zu können und es auf eine höhere Ebene im Stack zu heben, damit es alle Produkte durchzieht. Wenn man betrachtet, wie oft wir das getan haben (z. B. nur dieses eine Mal), hielt diese Lösung keiner Kosten-Nutzen-Analyse stand. Während deine tägliche Front-End-Arbeit riesige Auswirkungen auf die Effizienz des Rebrands hat, hat das Tooling für ein weitreichendes Redesign so gut wie keinen Nutzen für den Rest des Produktzyklus.  

Wir entschieden uns stattdessen dafür, die denkbar einfachste Sache zu erstellen: Wir übermittelten ununterbrochen einzelne Codebasen an den HTLM-Layer und kompilierten und lieferten zwei verschiedene Asset-Stacks. Dies band uns auch an die „oberflächliche” Rebrand Strategie. Du solltest die Entscheidung, wie du den Build-and-Release umsetzt, zeitgleich mit der Entscheidung deiner Management Strategie treffen, da jede ein paar Kompromisse mit sich bringt. Da wir wussten, dass wir andere Projekte, die das Back-End betreffen, pausieren und alle Entwickler sich auf den Rebrand konzentrieren konnten, mussten wir nur minimale Schutzmaßnahmen ergreifen, um gleichzeitige Arbeiten voneinander abzugrenzen.

Wie der Twin-Asset-Plan funktionierte, war beinahe beschämend einfach: Das Scaffolding ging über ein paar Tage rauf und wir entfernten es hinterher wieder genau so leicht. Bevor wir uns auf diesen Ansatz festlegten, führten wir einen Test-Rebrand mit unseren Asset-Prototypen durch und gestalteten alles in Comic Sans. Es war großartig.

Wir nutzten auch die Vorteile von Buildkite Parallel Steps, um einen zweiten Asset-Build auf unsere Codebase zu legen, welches dann alle Dateien, die Arbeiten zum Rebrand enthielten, auf die bereits vorhandenen Assets gelegt hat, haben sie gebündelt und in einen separaten Ordner Ordner zusammen mit unserem Webcode deployt. Dann legten wir einen kleinen Shim über unseren Asset-Path-Helper, der zwischen Asset-Ordner und Asset-Reskin wechselt, basierend auf einem Cookie, den die Mitarbeiter setzen konnten. Dieser Cookie wurde durch einen Button gesetzt, der von Fiona Tays Vortrag über die Entwicklung von Airbnb inspiriert wurde.

Als letztes erstellten wir ein Widget in unserem Mitarbeiter-UI (welches auf jeder Seite zu sehen ist), das jeden Nutzer wissen ließ, ob eine Seite bereit für „QA“ ist. Jedes mal, wenn ein Entwickler mit einer Seite fertig war, hinterließ er irgendwo ein unsichtbares Element.

Wenn dein Start-up wie unseres ist, hast du in den letzten Jahren auf agile, stufenweise, fortlaufende Art entwickelt. Was bedeutet, dass du längst vergessen hast, wie es ist, ein monatelanges, geheimes Projekt, das in einem großen Knall ausgeliefert wird, zu steuern.

von kazoe

Viele deiner täglichen Prozesse werden dich nicht innerhalb deines Budgets zum anvisierten Ziel bringen, aber wenn du versuchst, komplett zum Wasserfallmodell zurückzukehren, wirst du feststellen, dass du nicht die nötige Infrastruktur hast (meist um den QA-Prozess herum), um es sicher durchzuführen. Das Beste, was du machen kannst, ist, die Techniken zu vermischen. Ich gehe mal schnell durch ein paar Tipps zum Prozess, die auf unserer Erfahrung beruhen.

Du solltest eine Gantt Chart haben, welche alle großen Arbeitsmittel und ihre Abhängigkeiten verfolgt. Wir haben einfach eine Google-Tabelle benutzt: Reihen waren „Seiten“ in all unseren Projekten oder querlaufenden Aufgaben, Spalten waren Werktage, in den Zellen stand, wer was macht. Die Abschätzung war sehr leicht. Wir nahmen anfangs einfach eine beliebige Anzahl an Tagen pro Seite und dann, in der Mitte des Projekts – als wir echte Daten hatten – ermittelten wir, wie viel Arbeit wir in welcher Zeit im Durchschnitt erledigt hatten, um eine aktualisierte Prognose für die tatsächliche Zeit zu erhalten.

Deadlines sind für Rebrands nicht willkürlich. Du bringst dein Unternehmen quasi wieder neu raus und alle Presse- und Marketingaufgaben rechtzeitig fertig zu haben, kostet Zeit. Fühl dich nicht dazu verpflichtet, die Deadline zu früh zu legen, aber wenn du dich dem Ende des Rebrands näherst, müssen deine Schätzungen bindend werden, damit deine Marketingpartner erfolgreich sein können. Stell sicher, so viele Risiken und komplizierte Aufgaben wie möglich an den Anfang zu legen, um in den letzten Wochen keine böse Überraschung zu erleben.

Das Design implementieren. Planung vs. Überarbeitung.

Für die wichtigsten Seiten, wie unsere Homepage oder unsere Contest-Entry-Seite, entschieden wir uns, für traditionelle Designer Mockups, welche die Entwickler dann implementierten, aber für die meisten unserer Seiten, haben wir es anders gemacht. Der Entwickler wandte die neuen Stile aus unserem Styleguide an und schickte sie dann den UX-Entwicklern für ein kurzes Review.

Ursprüngliches Design des Projekts

Die Nachbesserung der Entwickler mag überflüssig erscheinen, aber wenn man das Gesamtbild betrachtet, erspart es eine Menge Aufwand. Wir ersparten uns Design-Comps, die nie benötigt wurden (da die initiale Conversion gut genug war), und konzentrierten unsere Bemühungen auf die Seiten, die es nötig hatten.

Zusätzlich zu der Wahl zwischen zwei unterschiedlichen Iterationsschleifen hatten wir täglich ein Meeting mit allen Entwicklern, welches mindestens eine Stunde dauerte. In diesem Meeting schaute sich jeder an, was an dem Tag geschafft wurde, und sah, welche Probleme es gab und ob man gegebenenfalls etwas überarbeiten musste. Durch verschiedene Feedback-Mechanismen konnten wir nicht nur die Marke weiterentwickeln, sondern auch sicherstellen, dass alles einheitlich war.

Wie sagt man? „Vergeude niemals einen Rebrand.“ Es ist ein großartige Möglichkeit, das Team näher zusammenzubringen. Alle haben das gleiche Ziel und aufgrund der übergreifenden Arbeit bekommt jeder die Chance, mit Leuten zusammenzuarbeiten, mit denen sie bei ihrer Arbeit normalerweise nichts zu tun haben.

Was haben wir gelernt?

Der 99designs Rebrand war ein großer Erfolg, gemessen an dem, was uns wichtig ist. Dennoch haben wir viel gelernt (wie zu erwarten). Es gibt zwei Dinge, die ich rückblickend anders gemacht hätte:

zen-music
Design von PANG3STU

Als erstes würde ich mehr vorab testen, bevor die Führungsetage alles absegnet. All unsere frühen Designs basierten auf Comps. Comps die auf wunderschönen Apple Retina Displays entworfen wurden. Wir haben die fertigen Seiten erst sehr spät auf einem durchschnittlichen Windows Laptop betrachtet. Zwischen einigen unserer Farbabstufungen und Schriftarten, die wir gewählt hatten, mussten wir Überarbeitungen durchführen, um die Lesbarkeit zu verbessern. Es hat nicht all zu viel Zeit gekostet, aber verglichen mit den Kosten eines stinknormalen Laptops und ein paar HTML-Mockups war es doch ein bisschen ärgerlich.

Das Zweite ist, SEO-Erwägungen schon früher in die Mockup-Phase einzubringen. Es ist sehr verlockend, schnell etwas zeigen zu wollen. Umso mehr, wenn du in der Designbranche bist und das Design im Vordergrund steht. Aus reiner User-Sicht ist das natürlich eine tolle Sache, aber der Googlebot benötigt Worte, um zu wissen, was deine Marke eigentlich macht. Und wenn google es nicht weiß, werden es auch deine Kunden nicht wissen. Es wäre so leicht (am Anfang des Projekts), deine aktuellen Seiten zu vergleichen, während der Googlebot sich die Texte aus deinen neuen Designs zieht. Wenn der Unterschied in Umfang oder Inhalt besonders drastisch ist, musst du dir die potenziellen Auswirkungen genauer ansehen.

Es ist einfach zu viel. Lass es mich zusammenfassen.

Puh, ein bisschen mehr als 2000 Wörter. Ich bin ziemlich sicher, dass ich seit der Uni nicht mehr so viel geschrieben habe.

Der Rebrand eines lange existierenden Unternehmens ist ein großes Unterfangen und jeder Versuch, es kurz und knapp zusammenzufassen, wäre eine allzu starke Vereinfachung. Aber ich versuch es trotzdem:

  • Nutze einen guten, modularen CSS Framework für alltägliche Arbeiten, um dir das Leben zu erleichtern, wenn es soweit ist.
  • Bewahre eine gute Balance zwischen agiler Softwareentwicklung & Wasserfallmodell.
  • Wähle eine Build-Strategie und Scaffolding, die sich gegenseitig unterstützen.
  • Mach die schweren und riskanten Dinge zuerst.
Wenn du noch Tipps zum Thema Rebrand hast oder wir auf etwas näher eingehen sollen, sag es uns in den Kommentaren.