Fallstudie
Tamaras Wunder
Aus einer Website für Häkelarbeiten wurde eine Dachmarke mit zwei Bereichen — bei laufendem Betrieb, mit bestehenden Kunden und ohne dass eine Bestellung verloren ging.
- Art
- Kundenprojekt
- Bereiche
- Web · UI/UX · Hosting
- Umfang
- Neue Marke, zweiter Geschäftsbereich, Gästebuch, Verwaltung
- Besonders
- Umbau bei laufendem Shop
-
01
AusgangslageDie bestehende Website trug einen Namen, der nur für einen Teil des Geschäfts stand: Handarbeiten. Inzwischen war ein zweiter Bereich dazugekommen, der dort nicht vorkam — mit anderen Kunden, anderen Erwartungen und anderem Ablauf. Dazu lief ein Shop mit echten Bestellungen, der auf keinen Fall ausfallen durfte.
-
02
Die AufgabeEine Dachmarke, unter der beide Bereiche Platz haben, ohne dass einer wie ein Anhängsel wirkt. Dazu ein neuer Auftritt, eine Möglichkeit für Kundinnen, ihre Ergebnisse zu zeigen, und eine Verwaltung, die die Inhaberin ohne technische Kenntnisse bedienen kann.
- Zwei gleichwertige Bereiche unter einem Dach
- Der bestehende Shop bleibt, inklusive Bestellungen und Kundenkonten
- Ein Gästebuch mit Fotos — moderiert, nichts erscheint ungeprüft
- Alles bedienbar ohne Entwickler
-
03
Die UmsetzungZuerst ein Design-System, das beide Bereiche trägt, dann die neuen Seiten, dann das Gästebuch mit Moderation und Foto-Aufbereitung. Der Shop wurde nicht neu gebaut, sondern an den neuen Auftritt angeglichen — er funktionierte, und was funktioniert und Geld verdient, baut man nicht aus Prinzip neu. Vor dem Umschalten lief die ganze Seite in einer lokalen Kopie mit eigener Testdatenbank.
-
04
Der UmzugLivegang und Domainwechsel liefen über ein Skript, das zuerst einen Trockenlauf macht und zeigt, was sich ändern würde. Danach wurde von außen nachgeprüft — und zwar jede Weiterleitung mit ihrem ganzen Ziel, nicht nur mit dem Statuscode. Genau darauf beruhte der einzige Fehler, der nach dem Livegang auftrat.
Architektur
Wie es aufgebaut ist.
Bewusst schlicht: ein klassischer Webserver, keine Abhängigkeit von einem Baukasten, keine monatliche Gebühr für eine Technik, die man nicht wechseln kann.
-
01
HTML, CSS, JavaScript
Seiten
Die öffentlichen Seiten liegen als fertige Dateien auf dem Server. Nichts muss bei jedem Besuch berechnet werden — das ist schnell und fällt nicht aus, wenn gerade viel los ist.
-
02
Eigenes CSS-Fundament
Design-System
Farben, Schriften, Abstände und Bausteine an einer Stelle. Dadurch ziehen Shop, Kundenkonto und Verwaltung automatisch mit, wenn sich etwas an der Marke ändert.
-
03
PHP
Schnittstellen
Für alles, was Daten braucht: Bestellungen, Gästebuch-Einsendungen, Kontaktformular, Moderation. Jede prüft Herkunft und Häufigkeit der Anfrage, bevor sie etwas annimmt.
-
04
MySQL
Daten
Produkte, Bestellungen, Kundenkonten und die Gästebuch-Beiträge. Fotos liegen als Dateien daneben, nicht in der Datenbank — das war eine bewusste Korrektur.
-
05
Zahlungsdienstleister
Bezahlung
Angebunden über einen etablierten Zahlungsdienstleister. Zahlungsdaten laufen nie über die eigene Seite und werden dort auch nicht gespeichert.
-
06
Eigene Oberfläche
Verwaltung
Ein eigener Bereich für die Inhaberin: Produkte pflegen, Bestellungen sehen, Gästebuch-Beiträge freigeben oder ablehnen. Gebaut für jemanden, der keine Technik lernen will.
Entscheidungen
Warum es so gebaut ist.
Vier Entscheidungen, die den Unterschied gemacht haben.
-
01
Der Shop wurde nicht neu gebaut
Er funktionierte, und an ihm hingen echte Bestellungen und Kundenkonten. Statt eines Neubaus bekam er den neuen Auftritt übergestülpt. Ein Neuaufbau hätte besser ausgesehen und ein echtes Risiko für laufende Bestellungen bedeutet — das war es nicht wert.
-
02
Das Gästebuch ist moderiert
Fotos und Texte von Kundinnen erscheinen erst nach Freigabe. Ein offenes Gästebuch im Netz wird irgendsicher missbraucht, und dann steht es im Namen der Inhaberin da. Die Freigabe kostet sie ein paar Sekunden pro Beitrag und erspart ihr das Risiko ganz.
-
03
Bilder gehören als Dateien auf den Server
Ursprünglich lagen die Produktbilder in der Datenbank. Das ließ die Daten auf das Hundertfache anwachsen und machte das Speichern in der Verwaltung spürbar langsam. Nach der Umstellung auf Dateien war beides behoben. Eine Entscheidung, die am Anfang bequem wirkt und sich später rächt — ein guter Grund, sie früh zu treffen.
-
04
Jede Veränderung erst im Trockenlauf
Der Server ist nicht versioniert, ein Fehler dort ist nicht mit einem Befehl zurückzunehmen. Deshalb zeigt das Werkzeug zuerst, was es ändern würde, und lädt erst auf ausdrückliche Anweisung wirklich hoch. Dazu eine Prüfung der Weiterleitungen vorab.
Was dabei herauskam
Die Seite ist live, beide Bereiche haben ihren Platz, und die Inhaberin pflegt ihre Inhalte selbst.
- Zwei Geschäftsbereiche unter einer Marke, keiner wirkt wie ein Anhängsel
- Der Shop lief während des gesamten Umbaus weiter
- Kundinnen zeigen ihre Ergebnisse — moderiert, ohne Risiko
- Produkte, Bestellungen und Beiträge pflegt die Inhaberin ohne uns
- Domainwechsel ohne verlorene Adressen: die alte leitet dauerhaft um
Was wir daraus mitnehmen
Nach dem Livegang zeigte eine Unterseite auf eine kaputte Adresse — der Rauchtest hatte nur geprüft, ob eine Weiterleitung stattfindet, nicht wohin. Seitdem prüfen wir bei jeder Weiterleitung das ganze Ziel. Ein Test, der nur das Naheliegende prüft, gibt Sicherheit, die es nicht gibt.
Kontakt
Eine Website, die mitwachsen soll?
Ob neuer Bereich, neue Marke oder Umbau im laufenden Betrieb — beschreib dein Vorhaben, wir sagen dir ehrlich, was sinnvoll ist.