Das ist der fünfte Artikel einer Serie zum Thema Management von Kundenprojekten. Hier plaudern wir ein bisschen aus dem Nähkästchen. Wir erzählen, was wir über die Jahre gelernt haben und auf welche Details es unserem Gefühl nach ankommt.
Unsere Kunden sind Selbständige und mittelständische Unternehmen. Wir sprechen hier über kleine und mittelgroße Website-Projekte. In der Regel gibt es einen Ansprechpartner, der auch entscheiden darf. Oft ist das der Inhaber selbst oder jemand in der Entscheidungsebene direkt darunter. Es sind 2 bis 5 Personen zu managen.
Im dritten Artikel dieser Serie ging es um den Prototypen mit dem wir in ein Projekt einsteigen. In diesem Artikel geht es um Websites, bei denen man mehr machen muss, als Farben und Typografie in einem fertigen Theme anzupassen.
Ich bin von der Ausbildung her Kommunikations-Designerin und beschäftige mich seit über zehn Jahren mit dem Entwickeln von WordPress-Themes. Ich stehe also jeweils mit einem Bein in einer der beiden Welten. Ich kenne mich mit Design und mit Code ein bisschen aus. Das ist eher ungewöhnlich.
Normalerweise sind die Prozesse Design und Entwicklung getrennt. Die Designagentur/der Designer entwirft die Gestaltung, die WordPress-Agentur/der Entwickler setzt das Ganze um. Im ungünstigsten Fall wurde das Design schon mit dem Kunden abgestimmt, bevor die Entwicklerseite das Design zu Gesicht bekommt.
Das ist ungünstig, weil es sein kann, dass im Design ungelöste Fragen schlummern.
Design und Code – eine spannende Beziehung
Als ich vom klassischen Design ins Webdesign und dann weiter ins Coding gewechselt bin, musste ich meine Denkweise komplett umstellen. Viele Dinge funktionieren im Web einfach anders.
- Responsive Design ist mehr als Desktop und iPhone
- Pixelperfekt gibt es nicht
- Blindtexte sind keine Inhalte
- Barrierefreiheit
- Was kann WordPress?
Responsive Design ist mehr als Desktop und iPhone
Auch die Zustände dazwischen sind wichtig. Das Layout verändert sich fließend und passt sich der jeweiligen Bildschirmgröße automatisch an. Die Zwischenzustände kann man leider nicht so schön kontrollieren wie die Desktopansicht, aber sie müssen trotzdem gut funktionieren. Die Website muss lesbar und bedienbar bleiben.
Je nachdem, wie das Design konzipiert ist, funktioniert das gut oder weniger gut. Mobile First (oldie but goodie) ist da immer noch ein guter Ansatz. Aber Achtung: Ein Design, das nicht mobile first konzipiert ist, kann man nicht mobile first coden.
Pixelperfekt gibt es nicht
Nicht alles, was auf der Zeichenfläche geht, funktioniert auch im Browser. Layouts verändern sich fließend, Schriften werden unterschiedlich gerendert, Textumbrüche passieren an unterschiedlichen Stellen und so weiter. Die Browser haben ihren eigenen Kopf.
Blindtexte sind keine Inhalte
Damit meine ich, dass man sich mit Blindtexten gerne selbst belügt. Mir geht es auch so – beim Gestalten wähle ich natürlich eine Überschriftenlänge, die gut aussieht. Baut der Redakteur dann eine dreizeilige Überschrift ein, geht das Layout womöglich kaputt. Solche Fälle versuchen wir im Auge behalten und testen das Design möglichst früh mit echten – oder zufallsgenerierten – Inhalten.
Barrierefreiheit
Dropdown-Menüs über vier Ebenen kann kein Mensch bedienen und Formularfelder mit zartgrauen Begrenzungs-Linien verschwinden auf hellen Bildschirmen einfach. Die Liste noch lang. Manche Dinge, die im Design schick aussehen, funktionieren im Web einfach nicht.
Was kann WordPress?
WordPress kann viele Dinge richtig gut. Man kommt mit Bordmitteln (Gutenberg-Blöcke und Plugins) sehr weit. Wenn man die Möglichkeiten kennt und sie richtig einsetzt.
Auf der anderen Seite darf man nicht zu zu eng denken. Wenn man alles nur in WordPress-Standard-Schachteln packt, sehen am Ende alle Websites gleich aus. Es gibt Fälle, für die man individuelle Lösungen braucht.
Wichtig ist, dass das WordPress-KnowHow möglichst früh in den Designprozess einfließt. Es hilft nichts, wenn das Design das Rad neu erfindet, wo es bereits eine gute Standardlösung gibt.
Andererseits ist es praktisch, wenn man möglichst frühzeitig einschätzen kann, welche Teile des Designs eine Sonderlösung brauchen. Dann kann man in Ruhe abwägen, ob es sich lohnt, in diese Lösung zu investieren und schauen, welche Alternativen es gibt.
Müssen jetzt alle Designer Code lernen?
Mir macht das Coden Spaß. Aber das geht nicht allen Designern so. Viele möchten einfach nur kreativ sein und wollen sich nicht einschränken lassen. Das ist vollkommen okay.
Wichtig ist eigentlich nur der Austausch zwischen Design und Entwicklung. Dieser Austausch muss schon sehr früh beginnen. Entwicklerin und Designerin müssen von Anfang an miteinander kommunizieren. Die Methode „Wir machen jetzt mal ein Design und dann sollen die Entwickler das irgendwie umsetzen“ halte ich für veraltet. Das hat auch früher nicht sonderlich gut funktioniert.
Ein Wort zu Tools
Zum Gestalten von Entwürfen verwenden wir Sketch, für die Abstimmung Zeplin.
Tools wie AdobeXD und Zeplin werben damit, die ideale Schnittstelle für die Übergabe Design/Entwicklung zu sein. Damit verkaufen sie so ein bisschen eine Illusion.
Dahinter steht die Vorstellung, dass die Designerin erst Mal ganz in Ruhe ihr Design baut. Ganz am Schluß übergibt sie das Design an die Entwickler. Das ist nicht realistisch, denn damit käme die Schnittstelle viel zu spät. Ist das Design fertig, wurden viele Entscheidungen schon getroffen, die später im Entwicklungsprozess unangenehm auffallen. Die Tools sind eine Hilfe, aber kein Ersatz für eine gute Abstimmung.
Neue Tools sind im Kommen
Bei den derzeit gängigen Tools steht das Design im Mittelpunkt. Sie sind für Designer gemacht, die sich nicht so gut mit Code auskennen. Die Tools produzieren zwar auch ein bisschen Code, aber mehr als Nebenprodukt.
Inzwischen gibt es Apps, die den umgekehrten Weg gehen. Sie verbinden ebenfalls Code und Design, gehen dabei aber vom echten Code aus. „Visual Coding“ nennt sich das dann. Da gibt es inzwischen ganz spannende Sachen. Mir sind eine ganze Reihe solcher Apps begegnet, Hadron, Phase und UX Pin. Ich schaue mir gerade Framer etwas näher an.