Womit beginnt ein wirklich gutes Projekt?
In den vorherigen Teilen sind wir zu einer wichtigen Erkenntnis gekommen - wir entwerfen keine Website nur, weil ein Unternehmen „eine neue Website“ benötigt.
Wir entwerfen ein Werkzeug, das ein konkretes Problem lösen soll.
Manchmal ist das Problem schwacher Verkauf. Manchmal eine zu geringe Anzahl von Anfragen. Manchmal finden Kunden keine Informationen. Ein anderes Mal beantworten Vertriebsmitarbeiter täglich dieselben Fragen, weil die Website grundlegende Informationen nicht vermittelt. Es kommt auch vor, dass ein Unternehmen einfach gewachsen ist und die bisherige Website nicht mehr seiner tatsächlichen Größe entspricht.
Deshalb sollte der erste Schritt nicht Photoshop, Figma oder die Wahl eines Frameworks sein.
Der erste Schritt sollte ein Gespräch sein.
Zuerst lernen wir das Geschäft kennen
Ein guter UX-Designer muss nicht in jeder Branche, für die er gestaltet, Experte werden. Er muss jedoch das Geschäft des Kunden ausreichend gut verstehen, um zu wissen, welche Probleme gelöst werden sollen.
Deshalb fragen wir nach Dingen, die anfangs vielleicht nicht direkt mit Design verbunden erscheinen;
- Woher kommen die Kunden?
- Warum entscheiden sie sich gerade für dieses Unternehmen?
- Warum gehen sie wieder?
- Was fragen sie am häufigsten vor dem Kauf?
- Wie sieht der Verkaufsprozess aus?
- Wer ist für die Bearbeitung von Anfragen zuständig?
- Was passiert mit einem Lead, nachdem das Formular abgeschickt wurde?
- Welche Produkte sind am wichtigsten?
- Welche Dienstleistungen haben das größte Potenzial?
- Will das Unternehmen die Anzahl der Anfragen, den Bestellwert, die Kundenanzahl erhöhen oder vor allem sein Image verbessern?
Erst die Antworten auf solche Fragen erlauben zu bestimmen, was wir eigentlich entwerfen sollten.
Discovery – bevor das erste Mockup entsteht
In digitalen Projekten wird häufig der Begriff Discovery verwendet.
Das ist die Phase, in der Problem, Nutzer, Geschäftsziele, Einschränkungen und technologische Möglichkeiten vor Beginn des eigentlichen Designs und der Entwicklung erforscht werden.
Das ist keine „Zeitverschwendung vor Arbeitsbeginn“. In einem gut geführten Projekt soll Discovery das Risiko verringern, etwas zu bauen, das zwar gut aussieht, aber kein echtes Problem löst.
Wir können zum Beispiel entdecken, dass der Kunde gar keine neue Website braucht.
Vielleicht braucht er eine bessere Informationsarchitektur.
Oder eine Vereinfachung des Kaufprozesses.
Oder die Integration der Website mit dem CRM.
Oder die Automatisierung der Anfragebearbeitung.
Oder eine völlig andere Art, das Angebot zu präsentieren.
Und genau deshalb lohnt es sich manchmal, vor der Produktion innezuhalten.
UX beginnt nicht mit dem Aussehen
UX, also User Experience, bedeutet die Erfahrung des Nutzers bei der Nutzung eines Produkts oder einer Dienstleistung.
Bei einer Website umfasst das weit mehr als das Aussehen der Oberfläche.
Es ist auch:
- Art der Navigation auf der Seite,
- die Leichtigkeit, Informationen zu finden,
- Verständlichkeit der Botschaften,
- der Kaufprozess,
- Formulare,
- Inhalts-Hierarchie,
- Geschwindigkeit der Aufgabenbewältigung,
- Reaktion des Systems auf Nutzeraktionen,
- Barrierefreiheit,
- Gefühl von Sicherheit und Vertrauen.
Deshalb beginnt UX schon bevor jemand den ersten Bildschirm zeichnet.
Zuerst muss verstanden werden, was der Nutzer zu erreichen versucht.
User Flow – also: Auf welchem Weg kommt der Nutzer zum Ziel?
Eines der grundlegenden Werkzeuge im UX-Design ist der User Flow. Das ist die Beschreibung des Pfades, den ein Nutzer durchläuft, um eine bestimmte Aufgabe zu erledigen.
Beispielsweise im Shop könnte das so aussehen: Werbung → Produktseite → Variantenwahl → Warenkorb → Lieferung → Zahlung → Bestellbestätigung.
Bei einem Dienstleister: Google → Leistungsseite → Referenzen → Testimonials → Formular → Kontakt zum Vertriebsmitarbeiter.
Beim Hersteller: Suche → Produkt → technische Daten → Dokumentation → Angebotsanfrage.
Jeder dieser Pfade erfordert andere gestalterische Entscheidungen.
Wenn das wichtigste Ziel des Nutzers der Kauf ist, dürfen wir ihn nicht zwingen, dutzende Bildschirme Text zu lesen. Wenn das Produkt hingegen teuer, komplex ist und Beratung erfordert, kann zu schnelles Weiterleiten zum Formular ebenfalls die falsche Lösung sein.
UX besteht unter anderem darin, das richtige Level an Führung des Nutzers zu finden.
Wireframe – bevor wir „verschönern“
Der nächste Schritt kann ein Wireframe sein, also ein vereinfachtes Schema eines Bildschirms, das Layout von Inhalten und Funktionen zeigt.
Ein Wireframe muss nicht schön sein. Und das ist gut so. In dieser Phase geht es nicht darum, ob die Farbe eines Buttons richtig gewählt ist.
Es geht um Antworten auf Fragen:
- Was sieht der Nutzer zuerst?
- Was ist am wichtigsten?
- Was sollte weiter oben stehen?
- Wo platzieren wir zusätzliche Informationen?
- Wie geht der Nutzer zum nächsten Schritt?
- Was passiert beim Klick?
Das ist ein bisschen wie Wohnungsplanung.
Zuerst legen wir fest, wo Wände, Türen und Räume sind. Erst später denken wir über Wandfarben nach.
Design System – damit das Projekt kein Flickwerk wird
In größeren Projekten taucht ein weiterer wichtiger Baustein auf - das Design System.
Das ist ein geordnetes Set von Regeln, Komponenten und Mustern, die definieren, wie die Oberfläche aufgebaut wird.
Es kann unter anderem folgendes umfassen:
- Farben,
- Typografie,
- Buttons,
- Formulare,
- Karten,
- Tabellen,
- Meldungen,
- Icons,
- Abstände,
- Responsivitätsregeln,
- Komponentenverhalten.
Wozu? – Damit die Oberfläche konsistent ist.
Wenn auf einer Unterseite ein Button sich anders verhält als auf einer anderen, muss der Nutzer die Oberfläche jedes Mal neu erlernen.
Ein Design System hilft auch dem Entwicklerteam. Anstatt jedes Mal eine Komponente neu zu bauen, kann es auf zuvor definierte Elemente zurückgreifen.
Das führt zu mehr Konsistenz, einfacherem Weiterentwickeln und oft auch zu geringeren Wartungskosten.
Und wo bleibt die Technologie?
Technologie sollte frühzeitig berücksichtigt werden, darf aber nicht das gesamte Projekt diktieren. Das ist ein wichtiger Unterschied.
Ein Designer kann eine großartige Funktion erfinden, die aus geschäftlicher Sicht Sinn macht. Ein Entwickler kann jedoch bemerken, dass ihre Umsetzung sehr teuer wäre oder Performance-Probleme erzeugt.
Andererseits kann ein Entwickler eine technologische Lösung vorschlagen, die sich leicht umsetzen lässt, die aus Nutzersicht das Problem aber nicht ausreichend löst.
Deshalb entstehen die besten Projekte dort, wo UX, Design, Entwicklung und Business von Anfang an miteinander sprechen.
Nicht nach dem Motto: „Erst die Designer, dann die Entwickler.“
Sondern: „Gemeinsam überlegen wir, wie wir das Problem am besten lösen.“
Technologie sollte nicht gewählt werden, weil sie „in“ ist
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, Headless CMS, native App, PWA... man kann lange Technologien aufzählen.
Der Kunde kauft jedoch keine Technologie. Er kauft eine Lösung.
Deshalb ist die Frage: „Welches Framework verwenden wir?“
oft weniger wichtig als: „Welche Probleme soll das System lösen?“ Erst danach kann die passende Architektur gewählt werden.
Eine einfache Unternehmenswebsite benötigt andere Technologie als ein Shop, der tausende Bestellungen abwickelt, und wieder eine andere benötigt eine B2B-Plattform mit umfangreichen Integrationen und individuellen Nutzerrechten.
Technologie sollte sich aus den Anforderungen ergeben, nicht Anforderungen aus der Technologie.
Backend, Frontend und der Teil, den der Nutzer nicht sieht
Man sollte auch daran denken, dass eine Website nicht nur das ist, was wir im Browser sehen.
Frontend ist der Teil der Anwendung, mit dem der Nutzer direkt interagiert.
Backend ist für die Logik auf dem Server verantwortlich – Datenverarbeitung, Datenbankkommunikation, Prozessabwicklung und Integrationen.
Und dazwischen gibt es oft eine ganze Reihe zusätzlicher Elemente;
- CRM.
- ERP.
- Zahlungssystem.
- Mailingplattform.
- Lagersystem.
- API.
- Analytics.
- Automatisierungen.
- Kundensupportsystem.
Wenn wir eine neue Website entwerfen, ohne dieses Ökosystem zu berücksichtigen, können wir ein schönes Frontend schaffen, das als isolierte Insel fungiert.
Dabei sollte das Ziel etwas völlig anderes sein.
Eine gute Website kann viel mehr als „Formulare sammeln“
Eine moderne Website kann Teil eines größeren Geschäftsprozesses sein;
- Der Nutzer sendet eine Anfrage.
- Das System erkennt das Thema.
- Der Lead landet im CRM.
- Der Vertriebsmitarbeiter erhält eine Benachrichtigung.
- Der Kunde erhält eine automatische Bestätigung.
- Daten werden einer passenden Kategorie zugewiesen.
- Das System kann die Verfügbarkeit eines Produkts prüfen.
- Es kann Informationen für den Vertriebsmitarbeiter vorbereiten.
- Es kann einen bestimmten Workflow starten.
Bei einem Shop kann die Bestellung automatisch durch die weiteren Erfüllungsstufen laufen. Im B2B-Bereich kann der Kunde Zugang zu individuellen Preisen, Dokumenten und Bestellhistorie erhalten.
Dann ist die Website nicht mehr nur eine „Visitenkarte“. Sie wird Teil der Geschäfts-Infrastruktur.
Was ist mit KI?
KI kann ebenfalls ein Element eines solchen Systems sein. Aber erneut – sie sollte nicht nur hinzugefügt werden, weil „jetzt alle KI haben“.
Wenn ein Chatbot kein echtes Problem löst, wird er nur ein weiteres Fenster auf der Website sein.
Wenn der Nutzer dank KI hingegen schneller das richtige Produkt finden, eine Dienstleistung konfigurieren, eine Antwort auf eine Frage erhalten oder durch einen Auswahlprozess geführt werden kann, dann hat die Technologie eine Berechtigung.
Dasselbe gilt für Personalisierung.
Wir können Nutzern unterschiedliche Inhalte je nach Verhalten, Eintrittsquelle oder Phase des Kaufprozesses zeigen. Wir können Daten analysieren und Kundenbedürfnisse besser vorhersagen.
Aber wir sollten immer mit der Frage beginnen: „Welches Problem lösen wir?“
Und erst danach: „Ist KI der beste Weg, es zu lösen?“
Wir testen nicht nur, ob es funktioniert
Ein häufiger Fehler ist, die Website erst am Ende zu testen. Dann stellen wir fest, dass das Formular zu lang ist, der Kaufprozess unintuitiv ist oder der Nutzer die wichtigste Information nicht findet.
Je später wir ein solches Problem entdecken, desto teurer ist seine Behebung.
Deshalb sollte man in Etappen testen. Wir können Prototypen prüfen. Wir können das Nutzerverhalten beobachten. Wir können Usability-Tests durchführen. Wir können Daten aus Google Analytics oder anderen Analysetools auswerten. Wir können Session-Aufzeichnungen oder Heatmaps nutzen, sofern sie datenschutzkonform implementiert sind. Wir können auch einfach mit Vertriebsmitarbeitern sprechen.
Letzteres wird oft unterschätzt.
Der Vertriebsmitarbeiter hört täglich Kundenfragen; er weiß, was nicht verstanden wird. Er weiß, wovor sie sich fürchten. Er weiß, welche Informationen vor dem Kauf übermittelt werden müssen.
Das ist enormes Designwissen.
MVP heißt nicht „irgendwas“
In digitalen Projekten taucht oft der Begriff MVP - Minimum Viable Product auf.
Es geht um die erste Version eines Produkts mit dem minimalen Funktionsumfang, der nötig ist, Annahmen zu verifizieren und Nutzern Wert zu liefern.
MVP sollte nicht bedeuten: „Lassen wir irgendwas bauen und schauen später.“
Ein gutes MVP sollte die Frage beantworten: „Welche kleinste Version der Lösung erlaubt uns zu prüfen, ob wir die richtige Richtung eingeschlagen haben?“
Das ist auch für Websites und Apps sehr wichtig.
Statt sofort dreißig Funktionen zu bauen, ist es manchmal besser, die fünf wichtigsten zu starten und zu prüfen, wie Nutzer sie verwenden. Später entwickelt man das System auf Basis realer Daten weiter, nicht nur auf Annahmen vom ersten Meeting.
Die Website endet nicht am Veröffentlichungstag
Das ist ein weiterer Punkt, den man oft vergisst.
Der Zeitpunkt der Veröffentlichung ist eigentlich der Beginn ihres wirklichen Lebens. Erst dann kommen reale Nutzer. Erst dann sehen wir, welche Inhalte funktionieren. Erst dann wissen wir, welche Elemente ignoriert werden. Erst dann können wir prüfen, ob die Anzahl der Anfragen, der Umsatz, die Verweildauer oder andere vorher festgelegte Kennzahlen gestiegen sind.
Deshalb sollte das Projekt weiterentwickelt werden;
- Analyse.
- Schlüsse.
- Änderung.
- Test.
- Erneute Analyse.
Das ähnelt mehr einem Zyklus als einem einmaligen Ereignis.
Was sollte eigentlich gemessen werden?
Das hängt vom Ziel des Projekts ab.
Für einen Onlineshop könnten das sein:
- Conversion-Rate,
- durchschnittlicher Bestellwert,
- Warenkorbabbrüche,
- Umsatz,
- Customer Lifetime Value.
Für ein Dienstleistungsunternehmen:
- Anzahl hochwertiger Leads,
- Formular-Conversionsrate,
- Anzahl vereinbarter Beratungstermine,
- Kosten pro Lead,
- Qualität der Anfragen.
Für ein Informationsportal:
- Auffindbarkeit bestimmter Informationen,
- Nutzerengagement,
- Rückkehrerquote,
- Downloads von Materialien.
Man muss nicht alles messen. Man muss jedoch wissen, was wichtig ist.
Denn wenn ein Unternehmen die Anzahl hochwertiger Anfragen erhöhen will, bedeutet reiner Trafficzuwachs nicht zwangsläufig Erfolg. Wir können zehnmal mehr Besuche haben und keinen zusätzlichen Kunden.
Der größte Fehler? Design ohne Antwort auf „Wozu?“
Man kann eine optisch großartige Website erstellen.
Man kann einen modernen Technologie-Stack einsetzen.
Man kann perfekte Animationen vorbereiten.
Man kann auf jedes Pixel achten.
Und dennoch kann das Projekt die erwarteten geschäftlichen Ergebnisse nicht bringen. Warum?
Weil die wichtigste Frage unbeantwortet blieb: Wozu machen wir das alles?
Wenn die Antwort lautet: „Weil die alte Website hässlich ist“,
ist das etwas zu wenig.
Wenn sie jedoch lautet: „Wir wollen die Anzahl der B2B-Anfragen erhöhen, die Zeit bis zum Finden der passenden Dienstleistung verkürzen und den Vertrieb entlasten, indem wiederkehrende Fragen weniger werden“,
haben wir plötzlich ein konkretes Problem zu lösen.
Und wir können eine Lösung entwerfen.
Bei Web24 wollen wir nicht nur Websites liefern
Das ist der Unterschied zwischen reiner Auftragserfüllung und technologischer Zusammenarbeit.
Wenn ein Kunde mit einer konkreten Idee kommt, bedeutet das nicht, dass unsere Aufgabe darin besteht, sie unreflektiert umzusetzen.
Unsere Aufgabe ist auch zu sagen: „Das macht Sinn.“
Oder: „Das geht besser.“
Oder: „Technisch können wir das bauen, aber wir sehen keinen geschäftlichen Nutzen.“
Oder: „Bevor wir das tun, prüfen wir, ob die Nutzer das wirklich brauchen.“
Manchmal ist die beste Designentscheidung, eine Funktion hinzuzufügen. Manchmal, sie zu entfernen. Manchmal, die Annahmen komplett zu ändern.
Und genau darauf beruht die Erfahrung eines Teams – nicht darauf, dass wir alles bauen können, sondern darauf, dass wir erkennen, was wirklich gebaut werden sollte.
Keine zwei Projekte sind gleich
Das führt uns zurück zum Ausgangspunkt.
Wir können zwei Kunden aus derselben Branche haben. Zwei Hersteller. Zwei Shops. Zwei Kanzleien. Zwei Softwarehäuser.
Ihre Websites können ähnlich aussehen. Sie sollten jedoch nicht identisch sein, nur weil sie in derselben Kategorie tätig sind.
Denn sie unterscheiden sich durch Menschen. Strategie. Verkaufsprozess. Angebot. Budget. Technologie. Kunden. Ziele.
Und genau deshalb erfordert jedes Projekt eigene Entscheidungen.
Nicht immer spektakuläre. Nicht immer bahnbrechende. Aber bewusste.
Die Website als Werkzeug, nicht als Dekoration
Eine gut gestaltete Website sollte für ein Unternehmen mehr sein als eine digitale Visitenkarte.
Sie sollte dem Nutzer helfen, eine Entscheidung zu treffen. Sie sollte Verkauf erleichtern. Sie sollte Fragen beantworten. Sie sollte Vertrauen aufbauen. Sie sollte Mitarbeiter unterstützen. Sie sollte sich dort in andere Systeme integrieren, wo es sinnvoll ist.
Und vor allem sollte sie ein konkretes Geschäftsziel erfüllen.
Deshalb gibt es keine einzelne Antwort auf die Frage: „Wie sollte eine gute Website aussehen?“
Besser ist die Frage: „Wie sollte die Website genau dieses Unternehmens funktionieren, damit sie ihm hilft, seine Ziele zu erreichen?“
Und genau von dieser Frage sollte jedes gute Projekt ausgehen.
Am Ende – die wichtigste Regel
Wir entwerfen keine Website, damit der Kunde sagen kann: „Aber hübsch.“
Wir entwerfen sie, damit der Kunde nach einigen Monaten sagen kann: „Das hilft uns wirklich, das Geschäft zu führen.“
Denn der Unterschied zwischen einer hübschen Website und einem guten digitalen Produkt ist oft auf dem ersten Bildschirm nicht sichtbar.
Man sieht ihn erst in den Ergebnissen.
Zusammenfassung der gesamten Serie
In dieser Serie haben wir uns angesehen, warum wir nicht zwei identische Websites entwerfen.
Wir begannen mit einer einfachen Annahme: dieselbe Branche bedeutet nicht dasselbe Geschäft.
Anschließend zeigten wir, wie Unternehmensstrategie, Vertriebsmodell, Zielgruppe und Nutzerbedürfnisse UX, Informationsarchitektur und Funktionalität beeinflussen.
Im letzten Teil führten wir durch den Gestaltungsprozess – von Discovery und Geschäftsverständnis über User Flow, Wireframes und Design System bis zu Technologie, Integrationen, Testing, Analytics und weiterem Ausbau.
Denn ein individuelles Design bedeutet nicht einfach „ein anderes Aussehen“.
Es bedeutet andere Entscheidungen, die aus einem anderen Problem resultieren.
Und genau deshalb sollte jedes Unternehmen eine speziell für es entwickelte Lösung bekommen, nicht eine für die „durchschnittliche Firma in der Branche“.
