Ein Entwurf ist erst fertig, wenn er als Theme funktioniert. Wir gestalten Shopify-Interfaces so, dass Redaktion und Entwicklung damit weiterarbeiten können.
Startseite, Kategorie, Produktseite, Warenkorb und Kundenkonto als zusammenhängendes System statt als Einzelbilder. Jeder Zustand wird mitgestaltet: leer, ladend, ausverkauft, fehlerhaft.
Farben, Typo-Skala, Abstände und Komponenten liegen als Theme-Settings und CSS-Variablen im Code, nicht nur in Figma. Eine Markenänderung läuft danach über Einstellungen statt über neue Templates.
Varianten-Auswahl, Konfiguratoren, Filterung und Cart-Drawer lassen sich auf einem Standbild nicht bewerten. Wir machen sie klickbar und testen sie, bevor jemand sie baut.
Wenn Positionierung, Sortiment oder Zielgruppe nicht mehr zu dem passen, was der Shop zeigt, hilft kein Test am Button. Dann steht ein Entwurf an, kein Detail-Tuning.
Konfiguratoren, Abo-Auswahl, B2B-Registrierung oder Bundles gibt es im Standard-Theme nicht. Sie brauchen einen gestalteten Ablauf, bevor sie in Liquid und JavaScript landen.
Über Jahre entstehen fünf Button-Varianten, drei Grautöne und vier Abstandsraster. Ein Designsystem räumt das auf und macht jede spätere Änderung billiger.
Wenn jede Kampagne einen Entwickler braucht, fehlen gestaltete Bausteine. Sections und Blocks lösen das - aber nur, wenn sie vorher als System entworfen wurden.
Liegt das Design vor, geht es direkt in die Shopify Entwicklung: Theme-Architektur, Sections, Metafelder, Datenmodell und Performance. Design ist dann kein eigener Projektschritt mehr.
Willst Du an einem tragfähigen Shop die Conversion erhöhen, ist CRO der Weg: Hypothese, Test, Auswertung. Ein Redesign wäre dort das teurere Werkzeug mit unklarer Wirkung.
Wenn Nutzer aussteigen, bevor überhaupt etwas sichtbar ist, ist das kein Layout-Problem. Dann gehören Core Web Vitals und Ladeverhalten vor jeden neuen Entwurf.
Ist offen, ob Relaunch, Migration oder Teilumbau ansteht, entscheidet das die Beratung. Ein Designprojekt vor dieser Entscheidung gestaltet oft die falsche Sache.
Aktuelles Theme, Analytics, Session Recordings und Support-Anfragen ansehen. Wir wollen wissen, wo Nutzer heute hängenbleiben, bevor wir etwas Neues zeichnen.
Seitentypen, Navigation und Inhaltsbausteine festlegen. Ergebnis ist eine Liste von Sections und Blocks, die später genau so im Theme existiert.
Typo-Skala, Farbrollen, Abstände, Zustände und Komponenten definieren. Alles bekommt einen Namen, der auch im Code und in den Theme-Settings trägt.
Die Seitentypen im System durchgestalten, inklusive Sonderfälle: lange Produktnamen, fehlende Bilder, ausverkaufte Varianten, dreistellige Preise in Fremdwährung.
Kritische Flows klickbar machen und mit echten Nutzern oder dem Team durchgehen. Änderungen sind an dieser Stelle noch billig, im Theme sind sie es nicht mehr.
Designsystem, Komponenten und Sonderfälle gemeinsam mit der Entwicklung durchgehen. Danach prüfen wir die Umsetzung im echten Theme, nicht im Bildvergleich.
Leerer Warenkorb, ausverkaufte Variante, Formularfehler, Ladezustand. Was nicht gestaltet ist, wird im Code improvisiert.
Kontraste, Fokusstile, Touch-Flächen und Tastaturbedienung gehören in den Entwurf - nicht in die Nacharbeit nach dem Go-live.
Jede Section hat Grenzen: wie viel Text passt, welche Bildformate greifen, was passiert bei zu wenig Inhalt.
Ein Entwurf, der Varianten, Kollektionen und Metafelder ignoriert, wird im Theme teuer. Das Datenmodell wird mitgedacht.
Der Shop wurde am großen Bildschirm entworfen, verkauft aber überwiegend am Telefon. Dann entscheidet die kleine Ansicht über den Umsatz.
Wenn Kunden vergleichen, konfigurieren oder Maße prüfen müssen, reichen Bild und Preis nicht. Diese Entscheidung braucht eine gestaltete Struktur.
Zweitmarke, Ländershop oder B2B-Ableger sollen zusammengehören. Ein gemeinsames System ist billiger als drei parallel gepflegte Themes.
Steht ein Relaunch ohnehin an, gehört der Entwurf davor. Dieselbe Entscheidung kostet im fertigen Theme ein Vielfaches.
Wenn nicht das Aussehen drängt, sondern die Frage nach WCAG 2.2 AA und BFSG, ist ein Redesign der teure Umweg zu einem prüfbaren Befund.
Zur BarrierefreiheitFehlen Attribute, Bilder oder Bestände aus ERP und PIM, zeigt jeder Entwurf Lücken. Das ist eine Frage der Datenquelle, nicht des Layouts.
Zur SystemintegrationSprachen, Währungen, Steuerlogik und Versandregeln für ein weiteres Land entstehen nicht im Entwurf. Sie entscheiden vorher über die Struktur.
Zur InternationalisierungNicht jeder Shop braucht einen kompletten Neuentwurf - manchmal reicht ein belastbarer Blick auf das, was schon steht.
Für Shops, die eine Vermutung haben, wo es hakt, aber keine belastbare Grundlage für die nächste Entscheidung.
Endet mit einer priorisierten Liste, die Dein Team auch ohne uns abarbeiten kann.
Für Shops, bei denen Struktur, Templates und Komponenten als zusammenhängendes System neu entstehen sollen.
Endet mit einem Designsystem, aus dem die Entwicklung ohne Rückfragen bauen kann.
Für Shops mit laufenden Kampagnen, wachsendem Sortiment und regelmäßig neuen Inhalten im Theme.
Endet damit, dass neue Seiten nach Marke aussehen, ohne dass jemand von vorn gestaltet.
Ein Shopify-Entwurf trifft auf ein festes Datenmodell aus Produkten, Varianten, Kollektionen und Metafeldern. Wer dagegen gestaltet, produziert Sonderlogik im Theme. Dazu kommt der Checkout: Er ist weitgehend vorgegeben und lässt sich nur innerhalb definierter Grenzen anpassen, was Layoutideen früh einschränkt.
Das entscheidet der Zustand des Codes, nicht der Wunsch nach neuem Aussehen. Ist das Theme sauber strukturiert und nur optisch veraltet, reicht ein Redesign auf der bestehenden Basis. Sind Templates über Jahre mit Sonderfällen und App-Resten überlagert, ist ein neues Theme meist günstiger als jede Reparatur.
Ein Designsystem, das nur in Figma existiert, driftet nach dem ersten Sprint auseinander. Wir legen Farbrollen, Typo-Skala und Abstände als Theme-Settings und CSS-Variablen an. Änderungen laufen danach über den Theme-Editor und wirken überall gleichzeitig, ohne dass jemand Templates anfassen muss.
Bei allem, was mehr als ein Klick ist: ja. Varianten-Auswahl, Konfiguratoren, Filter und Checkout-Vorstufen bewerten wir im klickbaren Prototyp mit Menschen aus der Zielgruppe. Für Detailfragen an einer laufenden Seite ist ein A/B-Test aus dem CRO-Bereich der ehrlichere Weg als eine Meinungsrunde.
Als Anforderung an den Entwurf, nicht als Prüfung danach. Kontrastwerte, Fokusstile, Zielgrößen für Touch, sichtbare Beschriftungen und eine sinnvolle Überschriftenhierarchie werden im Designsystem festgelegt. Nachträglich eingebaut kostet dasselbe Ergebnis ein Vielfaches - und zwingt oft zu optischen Kompromissen. Im Zweifel entscheidet der Kontrast über das Farbkonzept, nicht umgekehrt.
Ja. Häufig übernehmen wir den Shopify-spezifischen Teil: Übersetzung der Marke in Theme-Bausteine, Zustände, Sonderfälle und die Abstimmung mit der Entwicklung. Die Markenführung bleibt dann bei Deinem Team oder Deiner Leadagentur. Wir brauchen dafür nur klare Zuständigkeiten für Entscheidungen. Alles andere führt zu Entwürfen, die niemand freigibt, und zu Diskussionen im Sprint.
Wir sehen uns Theme, Templates und Zahlen an und sagen Dir, ob ein Redesign, eine Optimierung oder erst einmal gar nichts ansteht.
Stand:
Projektstart
Antwort in der Regel innerhalb von 24h
Direkt mit Strategie/Tech-Senior sprechen
Keine Agentur-Folien, klare nächste Schritte
NICCOS
Die Seite konnte nicht geladen werden.
Bitte lade die Seite neu. Falls gerade ein Update live gegangen ist, wird damit die aktuelle Version geladen.