Die Geschichte des Grafikdesigns erzählen

Lassen Sie mich das für Sie einrahmen: Wir werden ein Stück Produktions-UI aus einer Sketch-Datei nehmen, es in Informationsstücke zerlegen und es dann zu einer Geschichte zusammensetzen, die wir unseren Freunden erzählen. Unsere Freunde hören, sehen oder berühren die Geschichte vielleicht, also werden wir dieselben Informationen für verschiedene Menschen interpretieren und übersetzen. Wir werden Farben, Typografie und sogar Größen interpretieren und sie auf unterschiedliche Weise ausdrücken. Und wir wollen wirklich, dass alle aufpassen. Diese Geschichte darf nicht langweilig oder frustrierend sein; sie muss leicht zu verfolgen, zu verstehen und zu merken sein. Und sie muss, *muss*, von Anfang bis Ende Sinn ergeben.

Ich habe meine Kollegin Katie gebeten, eine Komponente auszuwählen, die sie in Sketch entworfen hat. Ich werde sie durchgehen und markieren (wir verwenden hauptsächlich SCSS, Twig und Craft, aber die Templating-Sprache ist nicht sehr wichtig), dann wird sie kurz antworten. Hoffentlich liege ich bei den meisten Dingen richtig und bei ein oder zwei Dingen falsch, damit wir sehen können, wie Dinge beim Handoff verloren gehen.

Bei White-Label- oder Framework-Front-Ends liegt der Fokus darauf, Teile zu erstellen, die so flexibel und anpassungsfähig wie möglich sind, so inhaltlich und stilistisch unabhängig wie möglich (im Rahmen des Produkts), weil man einfach nie weiß, wohin der Code letztendlich verwendet wird. Aber kürzlich bin ich zu einer Webdesign-Agentur gewechselt, die eine vollständige Umkehrung dieses Fokus hat. Es ist besonders. Es ist maßgeschneidert. Es geht darum, sich wirklich tief mit dem jeweiligen Kunden, den Sie haben, und den jeweiligen Kunden *ihrerseits* zu beschäftigen und etwas zu entwerfen, das zu ihnen passt, wie ein Schneider es tun würde.

Die enge Zusammenarbeit mit einer Grafikdesignerin wie Katie, mit hochfertigen, pixelgenauen UIs, anstatt direkt von Wireframes oder Geschichten auszugehen, ist eine Umstellung und eine Ausbildung, aber es gibt immer noch viele Dinge, die ich beisteuern kann. Hauptsächlich: **Dokumentendesign.**

Dokumentendesign, das zugegeben nur das alte semantische Web mit einem Accessibility-Hut ist, betrachtet Grafikdesign wirklich, befasst sich damit als Kommunikationssystem und übersetzt den zugrunde liegenden Zweck der Farben/Typografie/Layouts in ein zugängliches, linearisierbares und durchwanderbares DOM. Es ist HTML, Kinder. Es ist nur HTML. Man sollte denken, wir alle wissen es inzwischen... aber sehen Sie sich um. Sie würden sich irren!

Katie hat mir eine Sketch-Datei voller Artboards geschickt, und sie ist ziemlich gut darin, aufzuschreiben, was sie will, sodass ich nicht zu viel nachdenken muss

Zuerst sehe ich mir die gesamte UI-Datei an und stelle fest, was auf dieser Website eigentlich eine Karte ist – es stellt sich heraus, dass sechs oder sieben Komponenten dieses Paradigma verwenden. Machen wir ein paar Beobachtungen

• Eine Karte ist ein Block von Metadaten über eine Seite auf der Website.
• Sie enthält ein Bild/Medien und Metadaten – sie ist ein Medienobjekt.
• Sie wird in einer Gruppe von Objekten angezeigt.
• Diese Gruppe ist immer typisiert (es gibt keine Ansicht, in der Suchergebnisse und Nachrichtenartikel und Klassen alle vermischt sind).
• Jedes Objekt hat einen einzelnen Link zu einer Seite und keine anderen Aktionen.
• Jedes Objekt hat einen Call-to-Action (Buchen, etc.).
• Jedes Objekt kann Zeiten, Kategorien, Abzeichen und Calls-to-Action haben.
• Jedes Objekt muss Medien, Titel und Link haben.

Eine Karte ist also der wichtigste Weg, wie mein Benutzer diese Website navigieren wird. Sie werden geführten Pfaden folgen, wo sie eine Reihe von Karten erhalten, aus denen sie wählen können, basierend auf Top-Seiten wie „Was ist los“ oder „Kurse“. Sie erhalten auf dieser Karte keine Optionen. Es ist kein wirklich interaktives Element – es ist ein Führer, eine Karteikarte, die sie auf ihren Weg bringt: in diesem Fall ein Kaufweg, bei dem sie ein Ticket für eine Vorstellung in diesem Kunstzentrum bucht.

Bevor wir weitermachen, lassen Sie mich das für Sie einrahmen

Stellen Sie sich vor, Sie betrachten einen Flyer für eine Vorstellung und besprechen ihn am Telefon. Wenn Sie tatsächlich zu dieser Vorstellung gehen wollten. Was würden Sie tun? Sie würden den Flyer nicht einfach vorlesen, oder? Das ist der Text. Und er könnte alle möglichen zufälligen Dinge enthalten, wenn Sie buchstäblich oben beginnen würden. Sie würden nicht mit „Twentieth Century Fox“ oder „Buy Hot Dog Get Cola Free“ oder „Comedy Drama Musical Family Friendly“ beginnen. (Ich würde tatsächlich auflegen, wenn Sie das täten!) Und Sie würden nicht einfach die Farbe oder die Schriftarten beschreiben. Das ist der CSS. Sie würden die Informationen auf dem Flyer *durchsprechen*. Sie würden sagen: „Es ist The Greatest Showman und es ist am Dienstag, beginnt um 19:30 Uhr. Es ist im Odeon am Oxford Street an der Straßenbahn.“ Richtig?

Das ist das Dokument. Behalten Sie diese Person am Telefon im Hinterkopf.

Zählen, gruppieren und benennen

Nehmen wir also an, wir liefern eine Karte als Inneres eines Listenelements. Wir wollen eine Gruppe und diese Gruppe soll zählbar sein. Wir haben die Seite bereits mit einem <h1> benannt, also werden wir die Gruppe mit einer Überschrift, einem <h2>, einführen und beschreiben. Zuerst benennen wir sie, dann liefern wir sie, sodass jemand, der einen Screenreader benutzt, kann

1. Die Liste im Übersichten-Überblick signalisiert bekommen.
2. Vorab eine Zählung der Anzahl der Elemente auf einer Seite erhalten.
3. Wissen, dass sie zum nächsten Listenelement springen können, um die nächste Karte zu erhalten.
4. Wissen, dass sie die Gruppe jederzeit überspringen und zur nächsten Seite gelangen können – die Paginierung ist das nächste Element und wird als Landmark gekennzeichnet.

Sehen Sie den Pen
Karten als zählbare Liste mit beschreibender Überschrift geliefert von limograf (@Sally_McGrath)
auf CodePen.

Anker

In diesem speziellen Fall werde ich die gesamte Karte in ein Anker-Element (<a>) einpacken. Es gibt nur einen Link auf der Karte und ich möchte diese Informationen *vorladen*, damit jemand klicken kann, sobald er weiß, dass es die richtige Karte ist, anstatt nach der Aktion suchen zu müssen. Ein großer klickbarer Bereich ist auch schön, obwohl das natürlich zu weit gehen und eine Benutzeroberfläche zu einer Art Stolperfalle machen kann! Aber diese Karten sind nicht zu riesig und ich sehe, dass sie eine schöne Lücke um sich herum haben, sodass es einen Ruhebereich gibt, der versehentliche Klicks für Menschen mit eingeschränkter Feinmotorik reduziert.

Titel

Dann springen wir eine Überschriftenebene tiefer und markieren den Namen jeder Vorstellung als Überschrift, ein <h3>. Die Designerin hat diese Typografie zum Fokus gemacht, und wir werden das auch tun. Manche Leute surfen super schnell, indem sie zur nächsten Überschrift springen, dann zur nächsten Überschrift, also werde ich keine wichtigen Informationen vor der Überschrift setzen – sie werden daran vorbeispringen. Ich werde das Bild dort platzieren, denn in diesem Fall weiß ich, dass ich keine *aussagekräftigen Bildbeschreibungen* aus der API erhalten kann, sodass diese Bilder verborgen sind und leere Alt-Attribute haben. Jetzt kann der Benutzer erraten (in meinem Fall richtig), dass der Entwickler den Inhalt tatsächlich auf eine aussagekräftige Weise beschreibt und vielleicht zu den Übersichten zurückkehrt (Überschriften der Ebene 3 auflisten) und einfach eine Liste der Shows erhält.

Nun liefern wir unsere Metadaten. Listen wir sie auf

• Abzeichen
• Datum/Uhrzeit
• Kategorien

Abzeichen

Dies scheint etwas zu sein, das der Veranstaltungsort einer Karte hinzufügt, um sie hervorzuheben. Als Entwickler sehe ich nicht sofort, warum ein Benutzer danach suchen würde, aber es wird vom Designer stark betont, also werde ich sicherstellen, dass es bleibt. Katie hat das Abzeichen aus dem Fluss genommen, aber ich weiß, dass unser Benutzer es durch einen Sprung zu den Überschriften verpassen könnte. Ich werde also einfach den Wortlaut direkt nach dem Titel setzen, denke ich. Ich werde es entweder als erstes oder als letztes platzieren, um es in einer nicht-visuellen Navigation leichter zu erfassen und nicht zu verrückt zu sein, wenn man mit der Tastatur navigiert, visuell.

<p class="c-card__badge"><abbr title="Harrow Arts Centre">HAC</abbr> Highlight.</p>

... Aber nach reiflicher Überlegung werde ich doch kein <abbr> verwenden. Es ist die Markenfarbe, also ist es wirklich eine Aussage des Eigentums dieses Veranstaltungsortes, und wir haben HAC bereits tausendmal gesagt, also weiß der Benutzer, wo er ist.

<p class="c-card__badge">HAC Highlight </p>

Sehen Sie den Pen
Abzeichen von limograf (@Sally_McGrath)
auf CodePen.

Datum/Uhrzeit

Jetzt Datum und Uhrzeit. Katie gibt mir die Informationen zu diesem Entscheidungspunkt, indem sie die Daten fett formatiert. Daten sind wichtig. Ich werde es in eine <h4> packen, weil ich denke, dass jemand eine Seite mit Veranstaltungen schnell nach einer Matinee durchsuchen könnte, zum Beispiel, oder nach einem Nachrichtenartikel, der an einem bestimmten Tag veröffentlicht wurde. Ich platziere Daten nicht immer in Überschriften, besonders wenn es Millionen auf einer Seite gibt, aber ich stelle immer sicher, dass sie in einem <time>-Element mit einem vollständigen Wert stehen, sodass die von Katie angegebenen <time>Do</time> oder <time>Mo</time> als verständliche englische Wörter „Donnerstag“ statt Müll vorgelesen werden. Ich hätte auch versteckte Vervollständigung oder <abbr> mit einem Titel verwenden können.

Kategorien/Tags

Als Nächstes kommen die Kategorien, und ich platziere sie nach Abzeichen und Datum. Dieser Abschnitt ist in der visuellen Reihenfolge von oben nach unten, von links nach rechts, natürlich als Nächstes, aber er scheint auch *depriorisiert* zu sein: Er wurde links unten gedrängt und die Schrift ist kleiner. Das funktioniert für unser lineares Storytelling. Als Regel gilt: Wir wollen nicht, dass die Leute *wiederholte* oder allgemeinere Inhalte (Kino, Kino, Kino) durchgehen, um zu *einzigartigen* oder spezifischeren Inhalten (Montag, Dienstag, Mittwoch) zu gelangen. Denken Sie daran, wir sind innerhalb unserer Karte: Wir wissen, dass sie bereits auf einige allgemeine Weisen sortiert wurde (Nachrichten, Vorstellung, Kurs usw.), sodass sie wahrscheinlich viele wiederholte Stücke enthält. Wir wollen sicherstellen, dass der Benutzer, wenn möglich, vom Spezifischen zum Allgemeinen gelangt.

Es gibt eine primäre Kategorie, die zuerst sortiert wird, und dann manchmal einige andere Kategorien. Ich werde dies nicht als zählbare Liste liefern, da es meistens nur eine Kategorie gibt und viele Listen mit einem Element nicht viel nützen. Aber ich werde ein kleines Tag davor setzen, denn sonst ist es eine leicht undurchsichtige Ankündigung. TANZ! GESPROCHENE WORTE! (Ich meine, man kann es *rückwirkend* herausfinden, aber wir versuchen immer, Dinge zuerst zu benennen und dann zu zeigen, in linearer Reihenfolge. Das ist kein *Memento*.) Ich habe früher title="" ziemlich stark verwendet, aber ich habe Beschwerden über den Tooltip erhalten, also umgehe ich das. Beachten Sie die Verwendung eines Doppelpunkts oder Punktes, um uns eine „Pause“ zu geben. Das ist ein schöner Schliff.

<p class="c-card__tags h-text--label>
  <span class="h-accessibility">Categories: </span>
{% for category in categories.all() %}
  <span class="c-card__tag c-tag">{{category}}{% if not loop.last %} / {% endif %}</span>
{% endfor %}</p>

Außerdem härte ich meine Leerzeichen ein, um sicherzustellen, dass die Kategorien niemals zu einem vollständigen Kauderwelsch verschmelzen, selbst wenn Textkomprimierung oder spaceless rendering irgendwo in der Pipeline aktiviert sind. (Das kann mit Screenreadern und Spans passieren und ist ziemlich beunruhigend!)

Es gibt einen Teil dieses Designs, den ich im CSS machen werde, aber noch nicht wirklich in das Dokumentendesign integriert habe: die Farbkodierung der primären Kategorie. Ich beschreibe die Farbe dem Leser nicht, da sie willkürlich und nicht evokativ erscheint. Wenn es neben dem Taggen von Kategorien eine subtextuelle Komponente gäbe (wenn beispielsweise Gartenbaukurse grün wären), würde ich sie vielleicht einbringen, aber in diesem Fall ist es ein *nonverbaler Schlüssel* zu einer Kategorie, daher wollen wir ihn nicht in unserem *verbalen* Schlüssel haben.

Ich sortiere die primäre Kategorie an den Anfang des Kategorienabsatzes, aber ich kennzeichne sie nicht als primär. Das liegt daran, dass es einen Sortierfilter vor dieser Liste gibt, der nach der primären Kategorie sortiert, und ich vermute, dass es einfacher und weniger ärgerlich wäre, eine Kategorie aus diesem Dropdown auszuwählen, als jede Karte durchzulesen, auf der steht: Kategorien Primärkategorie Musik Sekundärkategorien Tanz. Da könnte ich mich irren! Das Gleichgewicht zwischen nützlicher und übermäßiger Kennzeichnung ist manchmal etwas schwierig. Sie müssen den Seitenkontext berücksichtigen. Wir bauen vielleicht Komponenten, aber unser Benutzer befindet sich auf einer Seite.

Sehen Sie den Pen
Dummies im Seitenkontext von limograf (@Sally_McGrath)
auf CodePen.

Aktion

Zuletzt die Aktion. Die Anweisung an den Benutzer, zu *buchen* oder *mehr erfahren* oder was auch immer es ist, wurde als Button gestaltet. Es ist eigentlich kein Button, es ist nur eine Anweisung, also werde ich es in diesem Fall als Span markieren. Ich möchte definitiv, dass dies am Ende des linearen Dokuments steht. Es ist ein Call-to-Action und auch ein Signal, dass wir das Ende dieser Karte erreicht haben. Die Aktion ist in beiden Fällen der Ausstiegspunkt: Wenn der Benutzer handelt, gehen wir zum Ziel, wenn nicht, gehen wir zur nächsten Karte. Wir wollen definitiv keine Daten nach der Aktion, da sie dann vielleicht schon gegangen sind.

Sehen Sie den Pen
Karte von limograf (@Sally_McGrath)
auf CodePen.

Meine Schlussfolgerung

Diese Markierung, die Daten zählt, gruppiert und benennt, liefert lineare *und* nicht-lineare Interaktionen. Die Seite ergibt Sinn, wenn man sie von oben nach unten liest, ergibt Sinn, wenn man Teile davon aus dem Kontext liest, und hilft beim Springen.

Katie, du bist dran…

Was für ein Spitzenartikel! Wirklich interessant. (Ich mag besonders, dass „Mo“, „Di“ usw. auf Karten als „Montag“, „Dienstag“ usw. gelesen werden… clever!)

Eine Sache, die mir aufgefallen ist, ist, dass Benutzer durch die Verwendung von assistiven Technologien Informationen in einer von uns festgelegten „festen“ Reihenfolge erhalten. Solange es keinen Filter gibt, muss jemand, der zum Beispiel nach Tanzveranstaltungen sucht, eine Titel-, Abzeichen-, Datums- und vielleicht mehrere andere Kategorien durchsuchen, um herauszufinden, ob eine Veranstaltung für ihn geeignet ist oder nicht. Ein bisschen mühsam. Aber das hast du nicht falsch gemacht – so funktioniert das Internet eben. Etwas, worüber ich in Zukunft nachdenken muss.

Die meisten unserer Kunden sind Kunst- und Kulturveranstaltungsorte, die Tickets für Veranstaltungen verkaufen müssen, daher entwerfe ich viele Veranstaltungskarten. Sie gehören zu den ersten Dingen, mit denen ich beginne, wenn ich eine Website entwerfe. (Noch bevor ich eine Typenhierarchie für den Rest der Website festlege.)

Visuell betrachtet beschreibe ich hier die allgemeinen Konventionen einer Veranstaltungskarte

• Sie muss wie eine Liste aussehen – damit die Leute verstehen, wie sie zu benutzen ist.
• Sie muss genügend Informationen liefern, damit die Leute entscheiden können, ob sie interessiert sind oder nicht. (Die Mindestinformationen sind wahrscheinlich ein Bild, ein Titel, ein Datum und ein Link.)
• Sie muss einen klaren Call-to-Action enthalten – normalerweise einen Link, um weitere Informationen zu erhalten.
• Sie muss visuell leicht scannbar sein.

Informationen visuell scannbar zu machen, ist ein ziemlich einfacher Fall: Sicherstellen, dass jeder Informationstyp (z. B. Bild, Titel, Datum, Kategorie, Link) auf jeder Karte an derselben Stelle sitzt und einer klaren Hierarchie folgt.

Ich konzentriere mich sowieso viel auf Typografie in meiner Arbeit, aber ganz klar: Titel sind so gestaltet, dass sie sehr prominent sind; Daten sind gleich gestaltet, aber anders als Titel; Kategorien sehen wieder anders aus – damit die Leute die Informationen, an denen sie interessiert sind, einfach durch das Scannen der Seite erkennen können. Ich komponiere die Karte für den Benutzer und sage: „Hey, hier ist der Name der Veranstaltung, hier ist, wann sie stattfindet – und hier geht es zu Ihren Tickets!“

Die Typografiestile – und insbesondere der Abstand dazwischen – leisten viel Arbeit, daher weise ich hier darauf hin, dass die Abstände im Codebeispiel nicht ganz stimmen

Das ist wichtig. Benutzer müssen Informationen schnell scannen können, da sie nicht alle dasselbe suchen, um die Entscheidung für eine Veranstaltung zu treffen. Zu viel oder zu wenig Abstand zwischen den Elementen kann ablenken.

Perfekt!

Manche Leute wollen einfach nur einen allgemeinen Überblick darüber, was in ihrem lokalen Veranstaltungsort ansteht. Andere haben vielleicht eine Werbung für eine bestimmte Vorstellung gesehen, die ihr Interesse geweckt hat, und wollen Tickets kaufen. Es gibt Leute, die Musik lieben, aber Theater nicht mögen und einfach eine Liste von Konzerten wollen; nichts weiter. Und manche Leute, die am Wochenende ausgehen wollen, sich aber nicht besonders darum kümmern, was es ist. Deshalb gestalte ich Karten so, dass sie leicht zu scannen sind – denn die meisten Benutzer lesen überhaupt nicht von oben nach unten.

Trotz der eben genannten Konventionen sehen Karten in Projekten natürlich nicht alle gleich aus – oder funktionieren auf die gleiche Weise.

Es gibt immer eine Spannung im Webdesign zwischen der Schaffung einer vertrauten Benutzeroberfläche für den Benutzer und etwas Neuem für den Kunden. Benutzerdefinierte Schriftarten und Farbpaletten leisten hier viel, aber das andere Stück ist die Entdeckung.

Ich lese mich in einen Kunden ein, einschließlich, wer seine Zielgruppe ist, indem ich lese, was sie auf Bewertungsseiten und sozialen Medien sagen, und indem ich direkt mit dem Kunden zusammenarbeite. Wenn man den Leuten zuhört, wie sie über ihre Arbeit sprechen und welches Feedback sie von ihrer Zielgruppe/Benutzern erhalten, deckt das oft interessante kleine Nuggets auf, die ein Design beeinflussen. Entwickler sind normalerweise nicht stark in die Entdeckungsphase involviert, was ich gerne ändern würde, aber für jetzt muss ich Sally ganz klar machen, was an *dieser* Veranstaltungskarte für jedes neue Projekt besonders ist. Ich schreibe viele, viele (viele) Notizen in Sketch-Dateien, stelle aber fest, dass sie oft verloren gehen, sodass wir manchmal eine Tabellenkalkulation für spezielle Funktionalitäten haben.

Sehen Sie den Pen
Karten im Seitenkontext, aus der Produktion gescrapt von limograf (@Sally_McGrath)
auf CodePen.