Effizienter Responsive-Design-Prozess

Wie sieht Ihr Responsive-Design-Prozess aus? Haben Sie das Gefühl, dass es effizient ist? Der folgende Artikel ist ein Auszug aus dem Kapitel „Responsive Process“ von Ben Callahan, das erstmals in der eBook-Version von Smashing Book 5 (Inhaltsverzeichnis) veröffentlicht wurde. —Hrsg.

„Der erfolgreiche Teilnehmer an dieser RFP wird unserem Team drei statische Designoptionen zur Bewertung anbieten.“ Ich war noch nie ein großer Fan davon, einen Designansatz mit mehreren Optionen zu wählen, aber ich verstehe – manchmal braucht ein Kunde das.

„Jede dieser Optionen bietet Design für drei einzigartige Layouts: Startseite, Listenseite, Detailseite.“ Alles klar. Jetzt haben wir bis zu neun statische Designdateien. Das gerät etwas aus dem Ruder.

„Jedes dieser einzigartigen Seitendesigns sollte die Größe von Mobilgeräten, Tablets und Desktops berücksichtigen.“ Ich war nie gut in Mathe, aber ich kann diese Rechnung machen. Siebenundzwanzig statische Designdateien?! Wird nicht passieren.

Dies ist eine Anfrage aus dem wirklichen Leben, die ich vor nicht allzu langer Zeit erhalten habe. Es stellte sich heraus, dass der Kunde für einen effizienteren Ansatz sehr aufgeschlossen war. Aber diese Erfahrung hat mich wirklich zum Nachdenken gebracht… Das Schwierigste daran, diese Sachen zu machen, ist, diese Sachen nicht wirklich zu machen. Es geht darum, mit Menschen zu arbeiten, während Sie diese Sachen machen.

Sie sehen, fast jeder potenzielle Kunde da draußen hat bereits eine Website . Für uns bedeutet das, dass die meisten Kunden mit einer Reihe von Erwartungen und ihrem eigenen Gepäck aus früheren Webprojekten hierher kommen. Dieses Gepäck kann drastische Auswirkungen darauf haben, wie Ihr Kunde das Projekt angeht – und Sie. Um die negativen Auswirkungen dieser Erwartungen zu verringern, habe ich festgestellt, dass der beste Weg, sie zu bewältigen, darin besteht, derjenige zu sein, der sie setzt.

Mein Ziel in diesem Kapitel ist es, Ihnen dabei zu helfen, mit Ihren Webprojekten erfolgreicher zu sein, indem ich ganz von vorne beginne ; indem Sie vom ersten Tag an daran arbeiten, die Erwartungen Ihres Kunden hinsichtlich dessen, was passieren wird, festzulegen, und indem Sie während des gesamten Lebenszyklus eines Projekts daran arbeiten, dasselbe zu tun.

Hauptunterschiede im Prozess für Responsive Webdesign

Bevor Sie Ihren bevorzugten Texteditor öffnen, bevor Sie Macaw öffnen, bevor Sie Ihren Skizzenblock herausholen oder mit dem Formen von Text beginnen, müssen Sie Ihrem Kunden helfen, den Prozess zu verstehen. Es gibt viele Möglichkeiten, dies zu tun, und ich bevorzuge es am wenigsten, einfach zu versuchen, sie mit einem neuen Prozess zu verkaufen. Meiner Erfahrung nach ist es am besten, frühzeitig Wert in Ihrer Denkweise zu demonstrieren – noch bevor ein Vertrag unterzeichnet wird. Dies gibt Ihrem Kunden das Vertrauen, dass Sie wissen, wovon Sie sprechen, aber es bedeutet auch, dass Sie sein Vertrauen gewinnen müssen, um einen neuen Weg auszuprobieren.

Um dies zu fördern, versuchen mein Team und ich, bei der Interaktion miteinander vier Ideale im Auge zu behalten: Zusammenarbeit, Iteration, Anpassung und Priorisierung. Lassen Sie mich kurz erklären, warum diese spezifischen Ideen Sie auf dem rechten Weg halten werden.

Zusammenarbeiten

Ich weiß, ich weiß. Alle sprechen überall über Zusammenarbeit und wie sie für großartige Arbeit erforderlich ist. Weißt du was? Es ist wahr. Natürlich müssen Sie innerhalb Ihres Teams zusammenarbeiten, aber heutzutage ist eine andere Art der Zusammenarbeit erforderlich – die Zusammenarbeit mit Ihrem Kunden . Ich habe eine wichtige Erinnerung für Sie: Kunden sind auch Menschen. Sie haben vielleicht nicht Ihr Fachwissen, wenn es um Webdesign und -entwicklung geht, aber sie wissen viel mehr über ihr Geschäft, als Sie es je werden werden.

Wieder geht es von vorne los. Bei Sparkbox habe ich nach einer Möglichkeit gesucht, bei der Gewinnung neuer Kunden kooperativer zu sein. Als Teil davon haben wir einen neuen Ansatz zum Schreiben von Kostenvoranschlägen gewählt. Anstatt dass ein Kunde zu uns kommt und sein Projekt erklärt, damit wir für eine Woche verschwinden und mit der perfekten Lösung zurückkommen können, haben wir ihn eingeladen, uns bei der Schätzung zu helfen. Es ist super einfach – wir nennen es kollaborative Schätzung und Kunden lieben es.

Wir beginnen mit einer einfachen Google-Tabelle mit einigen anpassbaren Feldern und berechnen, was unserer Meinung nach die Arbeit kosten wird. Wir beginnen mit breiten Sortimenten, weil wir dies sehr früh im Prozess tun – normalerweise nach nur einem 30-minütigen Telefonat. Dann teilen wir es mit dem Kunden und arbeiten gemeinsam daran.

Deshalb ist dies wichtig: Wir arbeiten bei der allerersten Sache zusammen, die wir mit unseren Kunden tun. Wir möchten, dass sie wissen, dass wir mehr Wert schaffen, wenn wir mit ihnen arbeiten, anstatt für sie. Dies ist nur eine Möglichkeit, unser Geld dort einzusetzen, wo unser Mund ist.

Wir laden unsere Kunden auch in unsere Teamkommunikationskanäle mit uns ein. Wir sind große Fans von Slack und Basecamp. Diese Tools bieten eine großartige Mischung aus formeller Dokumentation und informellen Gesprächen, die beide erforderlich sind, um eine qualitativ hochwertige Zusammenarbeit zu ermöglichen.

In Daniel Malls offenem Redesign der Reading Is Fundamental-Website bekamen wir alle einen Einblick, wie Dan seine Kunden mit in das Projekt einbezieht. Brad Frost ging noch einen Schritt weiter mit einem GitHub-Projekt namens „Project Hub“, einem Tool, mit dem Sie den Fortschritt Ihres Projekts verfolgen können.

Denken Sie daran, dass dies alles nur Werkzeuge sind. Tools können helfen, aber was wir wirklich brauchen, ist ein Umdenken. Mein Freund Kevin Sharon sagte einmal etwas sehr Ergreifendes zu mir. Er sagte: „Wenn du nicht ‚Nein‘ sagen kannst, ist es keine Zusammenarbeit.“ Ich weiß nicht, wie es Ihnen geht, aber ich hatte viele Beziehungen zu Kunden, bei denen ich nicht befugt war, etwas zurückzudrängen – selbst wenn ich aus Erfahrung wusste, dass das, wonach sie fragten, nicht funktionieren würde. Diese Kunden kommen mit Lösungen zu Ihnen und nicht mit Problemen, die gelöst werden müssen.

Ich schäme mich, es zuzugeben, aber ich hatte auch Kundenbeziehungen, bei denen das Gegenteil der Fall war. Manchmal überwältigt mich meine Frustration und ich vergesse, dass mein Kunde Teil des Projekts sein muss. Wenn wir von unseren Kunden eine Idee hören und sofort anderer Meinung sind, machen wir uns genauso schuldig wie sie, wenn wir einen kooperativen Prozess ablehnen. Viele Webstudios sind nicht bereit, diese Art der Zusammenarbeit in ihrem Prozess zuzulassen, oft weil sie glauben, dass ihre Kunden nicht kreativ oder technisch genug sind, um einen sinnvollen Beitrag zu leisten.

Zusammenarbeit ist keine Einbahnstraße. Wenn Sie Ihre Sicht auf Ihre Kunden dahingehend ändern, dass sie echte Mitwirkende in Ihrer Arbeit werden, ergeben sich alle möglichen neuen Möglichkeiten, sie einzubeziehen und Ihnen zu helfen, ein besseres Produkt zu entwickeln.

Iterieren

Wir suchen regelmäßig nach Möglichkeiten, eine kleine, qualitativ hochwertige Teilmenge von Funktionen mit enormer Geschwindigkeit bereitzustellen. Ein Ansatz wie dieser demonstriert frühzeitig Fortschritte und bietet echte Möglichkeiten, das Gelernte in Schwung zu bringen, um Sie durch ein Projekt zu führen.

Wenn Sie das Gefühl haben, dass es politische Herausforderungen geben könnte, die Arbeitsweise Ihres Kunden zu ändern, ist hier ein Profi-Tipp (und ich spüre das in jedem unserer Projekte): Iteratives Arbeiten kann dazu beitragen, Skeptiker in Befürworter zu verwandeln. Die meisten Leute lassen Sie viel eher eine neue Arbeitsweise an einer kleinen Phase ausprobieren als an einem ganzen Projekt. Auch hier ist der wichtigste Punkt, Ihren Wert frühzeitig zu demonstrieren, um das Vertrauen Ihrer Kunden zu gewinnen.

Eine Art, wie sich Iteration manifestiert, ist das Prototyping. Wir suchen ständig nach Möglichkeiten, um eine bedeutende Herausforderung zu identifizieren, eine mögliche Lösung vorzuschlagen, ihre Gültigkeit durch Prototyping zu beweisen oder zu widerlegen, zu überarbeiten und zu wiederholen.

Oft suchen wir nach der Möglichkeit, mit einer bezahlten Entdeckungsphase zu beginnen, bevor wir ein großes Projekt beginnen; Betrachten Sie es als Verabredung, bevor Sie heiraten. Dies gibt Ihnen die Möglichkeit, viel mehr über das Projekt und die Zusammenarbeit mit diesem Kunden zu erfahren. Beide Parteien können feststellen, ob die Arbeitsbeziehung passt.

Anfängliche Engagements können viele Formen annehmen, aber die Hauptziele sind:

1. Den Umfang des Projekts besser verstehen
2. Identifizieren und beweisen Sie mögliche Lösungen für die größten Herausforderungen
3. Finden Sie heraus, ob der Kunde/Lieferant passt
4. Beweisen Sie, dass Sie fähig sind
5. Lassen Sie sich für das oben Genannte bezahlen

Ihre Kunden werden diesen Ansatz zu schätzen wissen und Sie werden eine hervorragende Grundlage für Ihre zukünftige Arbeit schaffen. Und wenn Sie etwas lernen, das Ihr Verständnis des Projekts dramatisch verändert, sind Sie nur an eine kleine Phase gebunden. Dieses Lernen wird den nächsten Schritt im Prozess maßgeblich beeinflussen und Sie zu einer besseren Lösung führen.

Wir haben einen Kunden, mit dem wir seit vielen Jahren zusammenarbeiten; Tatsächlich haben wir kürzlich unser dreißigstes Projekt mit ihnen gestartet. Für mich ist dies ein Zeichen dafür, dass wir einen für beide Seiten vorteilhaften Weg der Zusammenarbeit gefunden haben – sie sehen den Wert unseres Angebots und wir sind kreativ und technisch zufrieden mit unserer Arbeit mit ihnen. Bei dem Versuch herauszufinden, was diese Beziehung erfolgreich gemacht hat, komme ich immer wieder auf unseren iterativen Ansatz zurück. Es kam schon oft vor, dass sie mit einem Problem und einer Idee zur Lösung zu uns kamen. Anstatt ein vielleicht 12-wöchiges Projekt einfach abzubeißen, haben wir regelmäßig kleinere, iterative Phasen vorgeschlagen, die mögliche Lösungen testen und eine viel geringere Anfangsinvestition haben. Mit diesem Ansatz konnten wir ihr Vertrauen gewinnen. Dieses Vertrauen ist unerlässlich, um eine nachhaltige Beziehung aufzubauen, und Iteration ist der Kern von allem.

Anpassen

Als Responsive Webdesign auf den Markt kam, erinnerte ich mich, dass ich von der Idee beeindruckt war, dass die Flexibilität, die dem Produkt, das wir entwickelten, innewohnt, sich in unseren Prozess einfügt. Samantha Warren hat es am besten ausgedrückt: „Ihr Prozess sollte so reaktionsschnell sein wie die Produkte, die Sie entwerfen.“

Die Wahrheit ist, dass es für diese Art von Arbeit keinen perfekten Prozess gibt. Sie und ich müssen uns den Beschränkungen stellen, denen wir ausgesetzt sind. Jedes Projekt, jeder Kunde, Umfang, Zeitplan, Budget, Team, Tech-Stack, Support-Matrix ist anders. Die Organisationen, die in diesem Geschäft erfolgreich sind, sind diejenigen, die innerhalb der Einschränkungen eines Projekts arbeiten können und dennoch zeitlose Arbeit leisten.

Meine Ansichten zum Prozess sind einem Kunden ausgesprochen schwer zu erklären. Wenn ich die Gelegenheit hätte, würde ich wahrscheinlich ein paar Schlüsselpersonen (einschließlich des Kunden), die an dem Projekt beteiligt sind, für ein paar Wochen in einen Raum sperren und ihnen das Mandat geben, es herauszufinden. Glauben Sie mir, Kunden mögen es nicht, wochenlang in einem Raum eingesperrt zu sein.

Stattdessen müssen wir ein Gleichgewicht finden zwischen einem sehr starren Prozess (bei dem jeder Schritt festgelegt und dokumentiert wird) und einem improvisatorischen Prozess (bei dem wir darauf vertrauen, dass das Team den besten Ansatz findet, während es geht). Um dieses Gleichgewicht zu finden, müssen viele Faktoren berücksichtigt werden. Hier sind drei für den Anfang: die Größe des Teams; die Erfahrung des Teams; und die Kritikalität des Projekts.

Die Größe des Teams

Es ist viel einfacher, eine große Flexibilität im Prozess zu ermöglichen, wenn Sie ein sehr kleines Team haben. Zwei oder drei Personen, die im selben Raum sitzen, können ohne viel Struktur den Überblick behalten. Wenn Sie die Teamgröße auf sechs oder sieben erhöhen, wird es schwierig, den Einfluss jedes Spielers auf den Fortschritt des gesamten Projekts zu verstehen. Erhöhen Sie Ihr Team auf zehn, fünfzehn oder mehr und es wird fast unmöglich.

Das ist für mich sehr persönlich. Als ich Sparkbox mit meinen Partnern gegründet habe, waren wir nur zu viert. Jeder von uns hatte eine ziemlich klar definierte Rolle, und wir konnten ohne viel Prozess ziemlich effektiv arbeiten. Da wir alle zusammen in einem großen Raum saßen, gab es eine ständige Kommunikation über alle Aspekte unseres Geschäfts.

Mittlerweile haben wir 23 Vollzeitkräfte plus drei Auszubildende. Wir sind sicherlich nicht so schnell gewachsen wie manche Orte – wir gehen sehr bewusst mit unserem Wachstum um – aber der Ausdruck „Wachstumsschmerzen“ klingt immer noch wahr. Wir mussten ständig damit experimentieren, wann, was und wie wir kommunizieren. Nur durch dieses Experimentieren können wir eine für uns richtige Balance finden.

Die Lektion hier ist, dass die Größe Ihres Teams die Art des Prozesses beeinflusst, den Sie für ein bestimmtes Projekt einsetzen können. Im Allgemeinen gilt: Je mehr Leute Sie an einem Projekt haben, desto mehr Starrheit brauchen Sie. Wenn Ihre Teamgröße kleiner wird, können Sie mit einem weniger formellen Prozess davonkommen. Es liegt in der Verantwortung Ihres Projektmanagers, den Puls des Teams zu überwachen und den Prozess anzupassen, um einen reibungslosen Ablauf zu gewährleisten.

Die Erfahrung des Teams

Wenn Sie mit einem unerfahrenen Team zusammenarbeiten, hilft ein strengerer Prozess, alle auf dem gleichen Stand zu halten. Tatsächlich glaube ich, dass ein unerfahrenes Team einen konkreten Prozess als Kontext braucht, um Erfahrungen zu sammeln. Erst nachdem Sie den Erfolg in einer starreren Umgebung nachgewiesen haben, können Sie damit beginnen, die Prozessschichten aufzulösen, um einem Team mehr Freiheit bei der Arbeitsweise zu geben.

Dies ist wiederum ein ziemlich persönliches Konzept für mich, vor allem wegen der Art und Weise, wie wir Teams für ein Projekt organisieren. Wir stellen für jedes Projekt, das wir übernehmen, ein einzigartiges Team zusammen; Selbst während eines Projekts ist es möglich, dass wir Mitarbeiter in und aus dem Team wechseln. Dies kann zu Herausforderungen führen, insbesondere wenn die Erfahrungen dieser Personen sehr unterschiedlich sind. Meistens bedeutet es, dass wir uns der Tatsache bewusst sein müssen, dass verschiedene Menschen unterschiedliche Prozessebenen benötigen, um erfolgreich zu sein. Unsere Projektmanager überwachen dies genau und passen es bei Bedarf an.

Wir haben viele erfahrene Designer und Entwickler, also geht es bei dieser Balance hauptsächlich darum, die weniger erfahrenen Leute zu verteilen. Das Hinzufügen von ein oder zwei neueren Entwicklern zu einem hochqualifizierten Team wird die Messlatte für alle höher legen. Die neuen Entwickler lernen von den erfahreneren, und die erfahreneren lernen, indem sie die neuen Entwickler unterrichten. Dies sorgt für eine Win-Win-Situation!

Die Kritikalität des Projekts

Die Idee, wie kritisch das Projekt ist, stammt von einem Herrn namens Alistair Cockburn, einem der ursprünglichen Unterzeichner des Agilen Manifests. In seinen Schriften über „Crystal Methods“ beschreibt Cockburn den Bereich der Kritikalität, indem er diese Aussage vervollständigt.

Mängel verursachen einen Verlust von:

1. Komfort (nicht kritisch)
2. Ermessensgeld (etwas kritisch)
3. Wesentliches Geld (kritisch)
4. Leben (sehr kritisch)

Je kritischer unser Produkt ist, desto strenger sollte unser Prozess sein. Sie haben dies vielleicht erlebt, wenn Sie sowohl für kleine als auch für große Unternehmen gearbeitet haben. Kleine, lokale Unternehmen neigen dazu, Ihnen mehr Freiheit in Ihrer Arbeitsweise zu lassen, weil sie weniger auf dem Spiel stehen (geringere Kritikalität); Große Unternehmen haben viel mehr zu verlieren (höhere Kritikalität), wenn Ihr Prozess keine guten Ergebnisse liefert.

Als ich gerade in dieser Branche anfing, arbeitete ich fast ausschließlich mit kleinen, lokalen Unternehmen. Ich verwaltete Projekte alle zwei Wochen mit Haftnotizen, E-Mail und einem Telefonanruf. Jetzt bin ich in viel größere Organisationen involviert. Die Verwaltung dieser Projekte erfordert die Teilnahme an täglichen Stand-Ups, Retrospektiven und Sprint-Planungsmeetings. Wir finden uns dabei, Burn-ups zu bauen, in JIRA (Problemverfolgungssoftware) zu arbeiten und unsere Geschwindigkeit zu berechnen, mehr als ich zugeben möchte. All dies liegt an der Kritikalität der Arbeit – ein kleiner Prozentsatz einer ausreichend großen Zahl ist immer noch eine riesige Zahl. Diese größeren Unternehmen verstehen dies und haben Verfahren eingerichtet, um sie vor diesen gewaltigen Verlusten zu schützen.

Priorisieren

Wenn die Größe der Bildschirme, für die wir entwerfen, abnimmt, nehmen auch unsere Optionen zur Kommunikation von Prioritäten ab. Denken Sie darüber nach: Wir verwenden normalerweise Dinge wie Größe, Position, Reihenfolge und Kontrast, um Benutzern zu helfen, zu verstehen, worauf sie sich konzentrieren sollten. Auf einem kleinen Bildschirm können Sie mit der Größe eines Objekts oder der Position einer Überschrift nur begrenzt viel anfangen. Wir haben einfach nicht die gleichen Freiheiten, die wir haben, wenn wir uns auf Erlebnisse auf größeren Bildschirmen konzentrieren.

Aus diesem Grund ist es wichtig, die Priorität von Inhalt und Funktionalität in einem System zu verstehen. Luke Wroblewski hat uns auf brillante Weise ermutigt, zuerst über mobile Geräte nachzudenken, um unseren Kunden zu helfen, sich auf das zu konzentrieren, was wirklich wichtig ist. Die Wahrheit ist, dass responsives Webdesign ohne ein solides Verständnis der Priorität nur Vermutungen ist.

Wir haben dies bei unseren Kunden gefördert, indem wir sie sehr früh im Prozess zum linearen Denken gebracht haben. (Im Abschnitt „Getting It Done“ weiter unten werde ich die Arten von Tools vorstellen, die wir dafür verwenden.) Lineares Denken hat den Vorteil, dass die Leute das Wichtigste auswählen müssen, und es ist diese Priorität, auf die Sie sich einigen müssen. Wenn Sie dies sofort in Ihrem Projekt etablieren, legen Sie eine akzeptierte Grundlage, auf der Sie aufbauen können, und liefern Antworten auf viele Fragen, die Sie sich später im Projekt stellen werden.

Wir hatten kürzlich ein Projekt, bei dem unser Kunde mit bereits zusammengestellten Breitbild-Drahtmodellen zu uns kam. Sie hatten dies getan, um etwas Geld zu sparen, und wir versuchten gerne, auf diese Weise mit ihnen zusammenzuarbeiten. Als wir mit dem Design begannen, war der Kunde mit unserer Arbeit nicht zufrieden. Erst nach der Hälfte des Projekts stellten wir fest, dass die Widescreen-Wireframes die Priorität von Inhalt und Funktionalität nicht angemessen identifizierten. Das war der Kern der Probleme, die wir hatten. Am Ende gingen wir zurück, um eine Inhaltsanalyse und Priorisierung durchzuführen, um das Projekt wieder in Schwung zu bringen. Hätten wir das früher getan, hätten wir während des gesamten Projekts effizienter arbeiten können. Leider mussten wir, um ihnen beim Geldsparen zu helfen, einige Nacharbeiten durchführen, die hätten vermieden werden können, wenn wir nur zuerst die richtige Grundlage gelegt hätten! Lektion gelernt – Legen Sie frühzeitig Prioritäten fest.

Vier Ideale

Denken Sie bei Ihrem nächsten Projekt daran, dass Sie Ihren Kunden in das Projekt einbeziehen müssen. Suchen Sie nach Möglichkeiten, mit ihnen zusammenzuarbeiten, anstatt nur für sie zu arbeiten. Denken Sie daran, dass Sie umso mehr Vertrauen verdienen, je mehr Sie frühzeitig Wert zeigen. Iteration hilft Ihnen dabei – scheuen Sie sich nicht, klein anzufangen! Denken Sie auch daran, dass Sie Ihre Arbeitsweise mit Sicherheit anpassen müssen, um sie besser an die Anforderungen eines bestimmten Projekts oder Kunden anzupassen. Streben Sie schließlich nachdrücklich an, früh im Projekt eine Priorität von Inhalt und Funktionalität festzulegen. Dies zahlt sich später im Projekt aus, wenn Fragen zur Wichtigkeit bestimmter Arten von Inhalten auftauchen.

Über diese vier Ideale hinaus möchte ich Ihnen einen kleinen Rahmen geben, während Sie überlegen, welche Art von Prozess in Ihrem Alltag funktionieren wird.

Ein Rahmen für den Betrachtungsprozess

Unser Prozess kämpft immer um sein Leben

Eine Sache, die mich bei den meisten Präsentationen oder dem Schreiben über Prozesse erstaunt, ist, wie selbstbewusst die Leute, die sich austauschen, zu sein scheinen. Vielleicht sind wir der Ausreißer, aber unser Prozess kämpft immer um sein Überleben. Wenn sich eine neue Arbeitsweise ergibt, probieren wir sie aus. Wenn wir glauben, dass es auch nur einen Hinweis auf einen besseren Weg gibt, etwas zu tun, werden wir herumgraben und versuchen, ihn aufzudecken. So sind wir verdrahtet. Ich habe das Gefühl, dass viele von Ihnen auch so ticken.

Lassen Sie uns zustimmen, dass unser Prozess niemals abgeschlossen ist.

Abkehr von linearen Übergaben

Die meisten in der Branche sind sich einig, dass wir aufhören müssen, Ergebnisse über die Mauer zu werfen. Stattdessen denken viele darüber nach, wie sie ihre Teams neu organisieren können, in der Hoffnung, dass die Einbindung der richtigen Personen für die Dauer des Projekts das Einfühlungsvermögen der Teamkollegen erhöht und die Messlatte für alle höher legt. Trent Walton beschreibt dies eloquent in seinem Beitrag mit dem Titel „Reorganization“. Darin erklärt er, dass die Struktur Ihres Teams oft die Art des Prozesses einschränkt, den Sie verwenden können, und ermutigt uns, kleinere disziplinübergreifende Teams in Betracht zu ziehen. Wir haben gesehen, dass dies wahr ist, und verfolgen einen sehr ähnlichen Ansatz. Ehrlich gesagt waren unsere früheren linearen Prozesse wahrscheinlich immer etwas ineffizient. Ich glaube, responsives Webdesign hat diese Ineffizienz nur viel offensichtlicher gemacht; Der Umgang mit reaktionsschneller Arbeit hat mich zu Gesprächen mit unseren Kunden über ihre Organisationsstruktur geführt – ein weiterer Beweis dafür, dass RWD wirklich ein Katalysator für organisatorische Veränderungen ist.

Wir müssen mehr Disziplinen für einen größeren Teil des Projekts einbeziehen. Ich stelle mir das gerne so vor, als würden wir uns spiralförmig durch ein Projekt bewegen, wobei unsere Augen fest auf das Endprodukt gerichtet sind, auf das, was zu liefern ist. Mit jeder Spirale durch binden wir alle Disziplinen ein und gewinnen mehr Klarheit an allen Entscheidungspunkten. Das Konzept ist einfach: Lassen Sie das gesamte Team während der gesamten Dauer eines Projekts eine Rolle spielen. Mit anderen Worten, erkennen und akzeptieren Sie die Auswirkungen, die Änderungen in einem Bereich eines Projekts auf die anderen haben.

Mein Team und ich sind aufgrund unserer Interaktionen mit einem meiner Business-Mentoren auf diese Idee gekommen (Spirale durch ein Projekt). Sein Name ist Geoff und er ist ein sehr kluger Kerl. Er war CFO einiger ziemlich großer Organisationen und hat es sich zum Beruf gemacht, visionären Führungskräften dabei zu helfen, die Finanzen ihrer Unternehmen in den Griff zu bekommen.

Als wir uns zum ersten Mal mit Geoff trafen, waren wir im Krisenmodus. Wir hatten eine große Herausforderung vor uns, eine, mit der weder meine Partner noch ich wussten, wie wir damit umgehen sollten. Geoff hat uns alle hingesetzt und uns gebeten, „mit dem Ende im Hinterkopf zu beginnen“. Er wollte, dass wir erklären, wie es aussehen würde, wenn wir die schwierigen Zeiten, die vor uns liegen, überstanden haben. Er wollte, dass wir den Erfolg für diese Zeit im Leben unseres Unternehmens definieren. Als wir uns weiterhin mit Geoff trafen, wurde ich frustriert. Jedes Mal, wenn wir uns hinsetzten, hoffte ich, dass er uns den Rat geben würde, den wir brauchten, um mit der Lösung des Problems zu beginnen, mit dem wir konfrontiert waren. Stattdessen stellte er immer mehr Fragen. Das ging mehrere Wochen so, und es war eine schwierige Zeit für mich.

Ich werde nie das Treffen vergessen, das ich mit Geoff und meinen Partnern hatte, wo alles anfing, einen Sinn zu ergeben. Unser Treffen begann wie alle anderen; Wir gingen unser aktuelles Verständnis des Problems vor uns durch und nahmen uns etwas Zeit, um alle neuen Erkenntnisse, die wir gewonnen hatten, auszutauschen. Nur dieses Mal begann jeder von uns zu sehen, wie sich die Lösung abzeichnete. Es war nicht ganz klar, aber es begann sich zu fokussieren. Von den drei Optionen, die wir in Betracht gezogen haben, sah eine viel ansprechender aus als die anderen. Was wir in den letzten Monaten gelernt hatten, führte uns eindeutig zu der besten Option, um das Problem anzugehen, mit dem wir konfrontiert waren.

Diese Lektion war für mich von unschätzbarem Wert. Was es mich gelehrt hat, ist, dass ein linearer Prozess von uns verlangt, Entscheidungen zu treffen, bevor wir alle Informationen haben. Wie könnten wir möglicherweise alles wissen, was wir wissen müssen, um eine Reihe von Wireframes zu erstellen, ohne das visuelle Design zu berücksichtigen? Wie könnten wir das Interface-Design perfektionieren, ohne mit etwas Front-End-Code zu experimentieren? Wenn wir so tun, als ob es möglich wäre, mit dem Inhalt zu beginnen, dann etwas User Experience Design zu machen, dann etwas User Interface Design zu machen und so weiter, ignorieren wir die Auswirkungen, die jedes dieser Ergebnisse auf die anderen hat. Stattdessen müssen wir ihnen erlauben, sich gegenseitig zu informieren. Wir müssen ihnen Raum zum Atmen geben, sich anpassen und das aus dem Projekt Gelernte nutzen, um sie voranzubringen.

Das ist genau der spiralförmige Prozess, durch den uns Geoff gedrängt hat. Diese Wochen des Stellens von Fragen informierten unser Verständnis des Problems. Anstatt eine Entscheidung zu treffen (ein UI-Design zu genehmigen) und so weiterzumachen, als ob es sich nie ändern würde (OK, Front-End-Entwickler, gehen Sie dieses Design programmieren), zwang uns Geoff zu erkennen, dass wir nicht alle Informationen hatten, die wir brauchten um die beste Entscheidung zu treffen. Geoff wollte, dass wir mit der Entscheidung bis zum „letzten verantwortlichen Moment“ warten.

Ich habe versucht, diese Idee der Spirale auf das zu übertragen, was wir jeden Tag tun, und bin auf einer Visualisierung wie dieser gelandet:

Bitte setzen Sie Ihre eigenen Disziplinen in die obigen Kuchenstücke ein – das Bild ist vereinfacht, um den Ansatz zu veranschaulichen. Es ist wichtig zu beachten, dass diese Punkte keine Ergebnisse im herkömmlichen Sinne sind. Sie bieten Gelegenheiten für Sie, sich mit Ihrem Kunden zusammenzusetzen und Ihren Fortschritt in Richtung des „einen Ergebnisses“ zu überprüfen. Das bedeutet: Hören Sie auf, die Ergebnisse zu verfeinern, aus Angst, Ihren Kunden zu enttäuschen. Es ist schrecklich ineffizient, Ihre Drahtmodelle in Illustrator schön aussehen zu lassen, wenn eine Skizze auf einem Whiteboard ausreicht. Wir haben sogar aufgehört, sie als Ergebnisse zu bezeichnen, und haben angefangen, sie Updates zu nennen.

Diese Art von Workflow ist flexibel genug, um sie für jede Art von Projekt zu verwenden, da Sie einfach die Arten von Disziplinen austauschen können, die für das Projekt benötigt werden. Die Zeremonie rund um den Prozess kann je nach Erfahrung der beteiligten Personen starrer oder improvisatorischer gestaltet werden. Der Schlüssel ist, sicherzustellen, dass alle Menschen beteiligt sind.

Dieser Ansatz verzögert Entscheidungen, bis Sie die richtigen Informationen haben. Es erkennt an, dass Entscheidungen, die von einer Disziplin getroffen werden, zweifellos die anderen beeinflussen werden. Es öffnet das Gespräch für das Team und erfordert die Zustimmung aller Beteiligten. Es ist weniger formell, aber effizienter. Es ist weniger vorhersehbar, aber ich glaube, dass es das Potenzial hat, ein viel besseres Produkt zu liefern.

Lassen Sie uns zustimmen, dass wir nach multidisziplinären Beiträgen suchen müssen.

Effizienz ist der Schlüssel

Wenn wir alle Zeit der Welt hätten, müssten wir uns keine Gedanken über unseren Prozess machen – wir könnten einfach Dinge ausprobieren, bis wir auf eine großartige Idee stoßen. Sie und ich wissen beide, dass dies nicht der Fall ist.

Viele der Anpassungen, die wir an unserem Prozess bei Sparkbox vornehmen, sind darauf zurückzuführen, dass wir nach einem schnelleren Weg suchen, um etwas zu erreichen. Durch das Versprechen einer höheren Geschwindigkeit erhalten wir auch Möglichkeiten, mit einigen sehr talentierten internen Teams bei größeren Kunden zusammenzuarbeiten. Alle suchen nach Effizienzgewinnen.

Einigen wir uns darauf, dass ein guter Prozess auch ein effizienter Prozess ist.

Sich ständig weiterentwickeln. Multidisziplinär. Effizient. Ich möchte, dass wir diese drei Dinge im Hinterkopf behalten, wenn wir uns mit den Grundlagen dieses Zeugs befassen. Wir können diese Ideen als Filter verwenden, durch den wir neue Ansätze in Betracht ziehen.

Genug Theorie

Das ist genug Theorie. Lassen Sie uns in die Grundlagen dieser Arbeit einsteigen. In unseren Webprojekten stelle ich mir ständig drei Fragen:

1. Für wen bauen wir?
2. Was sollen sie aus der Erfahrung gewinnen?
3. Wie sollen wir die Erfahrung darstellen?

Das Ziel ist es, einen Weg zu finden, den richtigen Leuten (wer) die richtigen Dinge (was) auf die richtige Weise (wie) zu sagen. Das Geheimnis großartiger Kommunikation jeglicher Art ist die Beantwortung dieser Fragen. Natürlich werden Sie im Laufe Ihres Projekts viele weitere Fragen stellen. Fragen wie welche Art von Navigationsmuster soll ich auf dieser Website verwenden oder brauchen wir wirklich eine Anzeige oben auf jeder Seite? Ich schlage vor, dass die Antworten auf Wer, Was und Wie Sie in die richtige Richtung führen, während Sie alle anderen Fragen beantworten, die auftauchen.

Hoffentlich haben Sie das Kapitel von Dan Mall bereits gelesen (kurz vor diesem). Darin leistet er großartige Arbeit, indem er einen Kontext bereitstellt, um zu verstehen, mit wem Sie kommunizieren. Seine Erklärungen zu Vorstellungsgesprächen und Kick-off-Meetings werden Sie sicher in die richtige Richtung bringen.

In ähnlicher Weise dreht sich im nächsten Kapitel von Eileen Webb alles um die Inhaltsstrategie für Ihr Responsive-Projekt. Es ist ein gründliches Kapitel, und sie beantwortet die Fragen dazu, was wir versuchen zu kommunizieren, besser als ich es jemals könnte.

Der Rest dieses Kapitels ist also der Beantwortung dieser dritten Frage „Wie?“ gewidmet. Ich werde mit Ihnen die Arten von Tools teilen, die für mich und mein Team bei Sparkbox am hilfreichsten waren, und darauf vertrauen, dass sie auch Ihnen helfen werden!

Es erledigen

Wie ich bereits erwähnt habe, ist es für eine effektive Kommunikation entscheidend, die Priorität der Inhalte und Funktionen zu verstehen, die wir präsentieren. Hier sind einige Möglichkeiten, wie sich diese Wahrheit in unserer Arbeit manifestiert.

Inhaltsprioritätsleitfaden

Ein Leitfaden zur Priorität von Inhalten ist „teilweise Inhaltsmodellierung, teils abgespecktes Wireframe“ (siehe „Leitfaden zur Inhaltspriorität“ von Emily Gray); wie ein Mini-Content-Modell, in der Reihenfolge der Prioritäten und in Zusammenarbeit mit dem Kunden. (Siehe https://bit.ly/content-priority-guide für ein funktionierendes Beispiel eines Leitfadens zur Priorität von Inhalten.)

Der Inhaltsprioritätsleitfaden sagt Ihnen, welche Arten von Inhalten auf jeder Seite vorhanden sein sollten. Dies können einfache Dinge wie der Titel, das primäre Bild und der Textkörper eines Blogbeitrags sein, oder sie können viel komplexer sein: Berücksichtigen Sie alle Inhaltstypen, die Sie möglicherweise auf der Produktdetailseite einer E-Commerce-Website benötigen.

Es ermöglicht auch die Erläuterung jedes Inhaltstyps. Wenn Sie eine kurze Beschreibung eines Produkts haben, kann der Prioritätenleitfaden sagen: „Ein Satz, der das Produkt beschreibt und was es einzigartig macht.“ Für ein Element wie ein Heldenbild könnten Sie einige Details zur künstlerischen Ausrichtung des Fotos angeben, wenn dies für einen bestimmten Fall relevant ist.

Leitfäden zur Inhaltspriorität helfen Ihnen auch dabei, wiederverwendbare Komponenten schnell zu identifizieren. Dies ist sehr hilfreich, wenn Sie die Verwaltung dieser Inhalte planen – das Erkennen wiederverwendbarer Muster bedeutet, dass Sie ein effizienteres System zur Verwaltung der Inhalte aufbauen können.

Am wichtigsten ist, dass ein Prioritätsleitfaden in der Prioritätsreihenfolge ist . Es provoziert eine Diskussion darüber, was auf einer bestimmten Seite wirklich wichtig ist. Dies hilft enorm, wenn Sie überlegen, wie eine Website über die Breite des Darstellungsbereichs hinweg reagiert. Und da es keinen eigentlichen Inhalt enthält, ermöglicht es großartige Gespräche über das Was und Warum von Inhaltstypen, die leicht übersehen werden können, wenn Sie sofort mit dem Schreiben der Kopie beginnen.

Wenn Ihre Kunden Schwierigkeiten haben, Prioritäten zu setzen (und das werden sie wahrscheinlich), könnten Sie diese Entscheidungen um das Wichtigste herum in einer Tabelle platzieren und ihnen Optionen zur Überprüfung geben – primär, sekundär, tertiär usw. Das Ergebnis ist das gleiche: Sie haben a priorisierte Liste von Inhaltstypen für jede Seite, aber der Prozess, um dorthin zu gelangen, kann sich für den Kunden etwas freundlicher anfühlen, wenn ihm einige Optionen gegeben werden.

Informationsarchitektur

Sobald Sie ein gutes Verständnis für die Arten und die Priorität von Inhalten haben, die im System vorhanden sein müssen, ist es wichtig zu überlegen, wie diese Inhalte gruppiert werden sollten und welche Pfade durch die Inhalte Sie Ihren Benutzern geben möchten. Diese Art des Denkens ist entscheidend für die Erstellung einer brauchbaren Website.

Ich habe kürzlich gesehen, wie Aaron Quinn über Informationsarchitektur sprach, und er hat etwas gesagt, das mir wirklich im Gedächtnis geblieben ist. Er schlug vor, dass wir uns bei der Gruppierung von Informationen möglicherweise zu sehr auf unseren gesunden Menschenverstand verlassen. Stattdessen plädierte er dafür, dass wir Konsens über gesunden Menschenverstand stellen, wenn wir planen, wie unsere Benutzer mit dem interagieren, was wir bauen. Lassen Sie mich erklären, warum mit einer kurzen Geschichte.

Wir haben einen Kunden, mit dem wir seit über einem Jahr zusammenarbeiten. Sie hat ein sehr erfolgreiches SAAS-Produkt entwickelt, bei dessen Aufbau wir ihr geholfen haben. Diese Frau ist unglaublich schlau; Sie arbeitet jeden Tag im Internet – damit verdient sie ihren Lebensunterhalt. Vor nicht allzu langer Zeit hatte ich ein Gespräch mit ihr darüber, was als nächstes für ihr Produkt ansteht, und sie sagte mir Folgendes: „Ich denke, wir müssen einige Änderungen an den Registerkarten auf unserer Website vornehmen.“ Ich hielt inne, weil ich verzweifelt versuchte, mich daran zu erinnern, wo wir Tabs auf ihrer Website implementiert hatten. Als sie meine Verwirrung spürte, fuhr sie fort, mir mehr darüber zu erklären, was sie sich erhofft hatte. Nach ein paar Augenblicken wurde mir klar, dass sie über die Navigation sprach. Es war aufschlussreich, dass diese versierte Webunternehmerin ihre Navigation als „Tabs“ bezeichnete.

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efficient. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

That's enough theory. Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. Who are we building for?
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

Getting It Done

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

Information Architecture

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

Style Comparisons

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

You get the idea. The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

User Experience Design

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

Das ist eine Menge. And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

Wenn wir reaktionsschnell bauen, müssen wir uns darauf konzentrieren, eine Single-Site-Lösung über verschiedene Darstellungsbereichsbreiten hinweg zu testen. Wir müssen die Usability des Ganzen messen, nicht nur die Breakpoints. Dies wird uns helfen, die benutzerfreundlichste Erfahrung für die meisten Menschen zu schaffen.

Und jetzt ein paar Updates, die wir mit unseren Kunden verwenden, um diese Ziele zu erreichen.

Content-Prototyp

Sie haben schon gehört, dass ein Webdesigner etwas CSS lernen sollte, richtig? Nun, ich stimme zu, und ich denke, ein Content-Stratege sollte etwas HTML lernen. Aus diesem und vielen anderen Gründen haben wir ziemlich früh in unserem Webentwicklungsprozess Inhaltsprototypen erstellt. Sobald wir beginnen, uns ein klares Bild des tatsächlichen Inhalts zu machen, fangen wir an , diesen Inhalt mit Hypertext zu kennzeichnen. Das machen wir mit HTML, richtig? Wer könnte Inhalte besser in semantische Tags verpacken als die Leute, die die Inhalte am besten verstehen? Während Tools wie Markdown ebenfalls funktionieren können, denke ich, dass es am besten ist, etwas grundlegendes HTML zu lernen, bevor Sie direkt zu Markdown springen. Zu verstehen, warum Sie den Inhalt auf diese Weise schreiben, ist genauso wichtig wie das eigentliche Schreiben des HTML-Codes. Tools wie Markdown fügen eine Abstraktionsebene zwischen Ihren Aktionen und der Ausgabe dieser Aktionen hinzu – eine Abstraktion, die in Ordnung ist, sobald Sie verstehen, was sie Ihnen gibt.

Wenn wir einen Content-Prototyp erstellen, lassen wir absichtlich fast alle Stile weg. Wir lassen sie ziemlich hässlich, also ist es sehr klar, dass wir nichts entworfen haben. Dadurch bleibt das Gespräch auf den Inhalt und die Priorität dieses Inhalts konzentriert. Wissen Sie, wenn Sie dies einem Kunden zeigen, wird er sofort die Reihenfolge der Dinge erkennen – und genau das wollen Sie von ihm: die richtige Priorität setzen! Außerdem fügen wir normalerweise gerade genug CSS ein, um Gruppierungen anzuzeigen, etwa so:

Ich habe dir gesagt, dass es hässlich ist.

Außerdem überschwemmen wir unsere Content-Prototypen mit Links. Ein Grund, warum wir diese erstellen, besteht darin, den Benutzern zu ermöglichen, von Seite zu Seite zu navigieren, um zu sehen, ob der Fluss durch die Inhalte funktioniert.

Denken Sie daran, dass Sie Ihre Kunden darauf vorbereiten müssen, diese Art von hässlichem Update zu sehen. Andernfalls werden sie sich sicherlich Gedanken darüber machen, Sie in ihr Projekt einzubeziehen. Es hat jedoch etwas Mächtiges, Rohinhalte in einem Browser markiert zu sehen.

Ein wichtiger Hinweis: Wir wissen, dass rein semantisches Markup wahrscheinlich nicht in die Produktion gehen wird. Dies wäre zwar ideal, aber die Realität der Arbeit im Internet sieht heute so aus, dass sie von Einzelpersonen und Teams mit sehr unterschiedlichen Fähigkeiten gewartet und erweitert werden muss. Mit dieser reinen Version des Markups zu beginnen, ist jedoch eine fantastische Möglichkeit, uns an unsere Ideale zu erinnern. Wenn wir dann das Markup anpassen, um Styling, Wiederverwendbarkeit, Erweiterbarkeit usw. zu ermöglichen, sind wir uns sehr bewusst, dass jede Änderung, die wir vornehmen, uns vom Ideal wegführt. Jede Änderung ist ein Kompromiss und sollte als solcher gründlich überlegt werden, bevor sie vorgenommen wird.

Statische Wireframes

In den letzten Jahren gab es eine ziemliche Abneigung gegen traditionellere statische Wireframes. Ich glaube, dass sie noch viel Wert hinzufügen können. Ich glaube auch, dass sie nicht bei jedem Projekt benötigt werden. Wenn wir sie verwenden, tun wir sie normalerweise in schmalen Breiten – so unbequem das auch ist – um uns dabei zu helfen, uns auf die Priorität zu konzentrieren. Die Begrenzung unserer visuellen Immobilien erzwingt diesen Fokus. Wir haben dafür viele Tools verwendet, von Keynote bis Balsamiq. Ehrlich gesagt, jedes dieser Tools wird die Arbeit erledigen. Finden Sie einen, mit dem Sie sich wohlfühlen, und machen Sie sich an die Arbeit.

Wir skizzieren auch viel. Whiteboards, Bleistift und Papier, verschiedene Zeichen-Apps. Wir machen Fotos von diesem Zeug und teilen es mit unseren Kunden, wobei wir absichtlich alles sehr roh halten. Die Rohheit ist ein wichtiger Teil dessen, was wir tun. Es hilft unseren Kunden zu wissen, dass wir keine Zeit damit verschwenden, Dokumente aufzupolieren, die von der Politur nicht profitieren, und es sorgt dafür, dass das Feedback fokussiert bleibt. Das Letzte, was wir wollen, ist, dass jemand die Farben unserer Wireframes kommentiert.

Interaktive Wireframes

Ein Teil der Abkehr von traditionelleren Wireframes war zugunsten eines interaktiveren Ansatzes. So wie das Agile Manifest funktionierende Software über Dokumentation fördert, glauben viele in unserer Branche, dass es viel wirkungsvoller ist, Ihre Absicht für eine Interaktion anhand eines Prototyps zu demonstrieren, als zu versuchen, sie statisch zu beschreiben. Heutzutage sind die für Rapid Prototyping verfügbaren Tools enorm leistungsfähig: Frameworks wie Bootstrap und Foundation; CSS (oder Sass und LESS) Toolkits wie Bourbon und Pure CSS; Visual-Prototyping-Tools wie InVision und Marvel. Sogar visuelle Webdesign- und Entwicklungstools wie Macaw oder Präsentationstools wie Keynote können verwendet werden, um sehr interaktive Wireframes zu erstellen.

Der Vorteil dieses Ansatzes besteht darin, dass Sie den Leuten die Idee zeigen können, anstatt zu versuchen, sie ihnen zu erklären. Wenn ein Bild mehr als tausend Worte sagt, sagt ein Prototyp mehr als tausend Bilder.

Wir arbeiten jetzt mit einer Organisation zusammen, die das versteht. Eines ihrer Ziele ist es, Rapid Prototyping früher in ihren Prozess einzubeziehen, damit sie die Prototypen für Usability-Studien sowie für Produktionscode verwenden können. Unsere Arbeit mit ihnen konzentriert sich darauf, ein System von Komponenten zu erstellen, das für alle ihre Web-Eigenschaften verwendet werden kann. Dieses System wird schließlich auch verwendet, um es ihrem Team zu ermöglichen, sehr schnell interaktive Wireframes zu erstellen. Da wir es mit Blick auf ihre Marken erstellt haben, werden die interaktiven Wireframes ihren Produktionsversionen sehr ähnlich sehen, was bei ihren UX-Tests enorm hilfreich sein wird.

Bei einem solchen Ansatz steht der langfristige Erfolg einer Web-Property im Vordergrund. Es verkörpert den „One Deliverable“-Workflow, über den wir zuvor gesprochen haben, indem es alle Disziplinen in die Erstellung des Prototyps einbezieht und die Erkenntnisse aus Design und Entwicklung in weitere Entscheidungen einfließen lässt. Ich glaube, wir sehen eine Verlagerung hin zu Unternehmen, die ausgereifte Front-End-Systeme bauen, anstatt CSS nachträglich zusammenzuhacken. Einem Unternehmen die Möglichkeit zu geben, eine statische Version seiner Webarbeit mit echten Benutzern zu testen, ist ein wichtiger Schritt, um dies in naher Zukunft als Norm zu festigen.

UI-Design und -Entwicklung

„Gutes Design ist Problemlösung.“

— Die Kunst und Wissenschaft des Webdesigns, Jeffrey Veen (2000) .

Für diejenigen unter Ihnen, die Designer sind, klingt dieses Zitat sehr wahr. Viele Leute sehen, was wir tun, als Dekoration, aber es ist so viel mehr. In den letzten Jahren habe ich festgestellt, dass ich Jeffs Aussage von ganzem Herzen zustimme, mir aber auch der Tendenz von Designern bewusst bin, ihre Lösungen zu verfeinern. Das führt mich zu dem, was ich „den Schaltpunkt“ nenne.

Wenn Sie die Aktivität des Designs in drei Phasen aufteilen – die Ästhetik etablieren, das Problem lösen und die Lösung verfeinern (wie oben angegeben) – ist der Wechsel von der Problemlösung zur Lösungsverfeinerung der Schaltpunkt. Dies ist der letzte verantwortungsvolle Moment, um sich dem Medium Web zuzuwenden. Wenn Sie dies nicht tun, werden Sie diese Verfeinerungsphase am Ende mehrmals durchführen – und das ist höchst ineffizient.

Wenn Sie jemals Stunden damit verbracht haben, eine PSD zu optimieren, sie einem Entwickler zum Erstellen übergeben und dann in ein oder zwei Wochen wieder überprüft haben, haben Sie diesen Schmerz erlebt. All die Mühe, die Sie zum Verfeinern und Verfeinern aufgewendet haben, indem Sie statische Pixel herumgeschoben haben, ist verschwendet. Sobald das Design das Medium wechselt (von statischem Design in Photoshop oder einem anderen Tool zu HTML und CSS im Browser), ist ein weiterer Verfeinerungsdurchgang erforderlich. Die Idee hinter dem Schaltpunkt ist zu erkennen, wie ineffizient dieser ist. Anstatt mit statischen Tools zu verfeinern, lassen Sie das grundlegende Design so schnell wie möglich codieren und kümmern Sie sich um die Verfeinerung im Endmedium – dem Web.

Dies erfordert oft Design-Pairing, buchstäblich zusammensitzen, um diese Verfeinerungen zum Leben zu erwecken. Obwohl sich dies manchmal langsam und schmerzhaft anfühlen kann, ist es für alle Beteiligten enorm vorteilhaft. Wenn ein Designer einem Front-End-Entwickler die Art von Stilanpassungen mitteilt, die er gerne sehen würde, lernt der Front-End-Entwickler, worauf es bei einem verfeinerten Design ankommt. Während der Front-End-Entwickler die angeforderten Änderungen vornimmt, sieht der Designer, wie diese Änderungen vorgenommen werden, und lernt vielleicht ein wenig CSS. Dieser Prozess macht alle klüger. Es bedeutet auch, dass das nächste Mal, wenn diese beiden sich paaren, es viel schneller geht.

Heutzutage müssen wir mit einer Reihe von Tools vertraut sein, um UI-Gespräche in Gang zu bringen, und wir müssen die Codierung dieser Designs früher im Prozess verschieben. Werfen wir einen Blick auf einige Möglichkeiten, dies zu tun.

Stilfliesen

Samantha Warren ging neue Wege, als sie Stilkacheln einführte, um „eine visuelle Sprache“ für das Web zu definieren. Diejenigen von uns mit Branding-Hintergrund haben sofort gesehen, wie wertvoll Stilfliesen sein können.

Stilfliesen sind ganz einfach. Sie umfassen im Allgemeinen Farbpaletten, Typografieoptionen, Texturen und Ikonografie- oder Illustrationsstile. Sie sind bewusst keine ganzseitige Komposition. Stattdessen repräsentieren sie gerade genug Design, um festzustellen, ob wir uns in die richtige Richtung bewegen. Aus diesem Grund funktionieren sie am besten, wenn Ihr Kunde seine Wünsche zum Ausdruck gebracht hat, Sie aber nicht vollständig davon überzeugt sind, dass Sie auf derselben Seite sind.

Stilfliesen habe ich vor allem wegen ihrer Schnelligkeit zu schätzen gelernt. Wo wir früher eine Woche damit verbracht haben, eine Startseite und Unterseiten in Photoshop zu entwerfen, können wir jetzt innerhalb weniger Stunden eine einfache Stilkachel erstellen. Dies kann Zeit und Geld sparen und Ihnen die Gewissheit geben, dass Sie sich in die richtige Richtung bewegen.

Samantha hat eine Handvoll Beispiele auf der Style Tiles-Site, und unten sind einige großartige Ressourcen aufgeführt, die ihre Verwendung in realen Prozessen abdecken:

• „Get Your (Visual) Style On“: Yesenia Perez-Cruz, Dan Mall und mein Vortrag auf der Artifact Conference in Austin, Texas (13. Mai 2013).
• „Schnellere Designentscheidungen mit Style Tiles“: Samantha Warren bei einem Event Apart in Austin, Texas (Februar 2015).
• Der Styleguide-Podcast mit Samantha Warren

Aufgrund ihrer statischen Natur verwenden wir sie nicht allzu oft. Unsere anfängliche Designrichtung wird normalerweise mit einer Elementcollage oder einem Stilprototyp festgelegt, die beide als Nächstes behandelt werden.

Element-Collagen

Dan Mall stellte uns Elementcollagen als „Ansammlung unterschiedlicher Teile ohne spezifische Logik oder Ordnung“ vor. Ihre vielfältige Natur macht deutlich, dass das, was Sie sehen, kein fertiges Design ist; Vielmehr bieten Elementcollagen den Kunden den Kontext einer Vielzahl von Komponenten, die möglicherweise in einem System zusammenleben. Sie helfen uns, etwas Fleisch auf die Knochen eines Drahtgitters zu bringen; sie helfen uns, uns vorzustellen, in welche Richtung wir uns bewegen; Sie ermöglichen uns, mit der Visualisierung der Bausteine ​​unserer Website zu beginnen, ermutigen uns aber, das Ganze nicht aus den Augen zu verlieren.

Ein Vorteil von Elementcollagen besteht darin, dass Sie auswählen können, welche Komponenten angezeigt werden sollen. Interessiert sich Ihr Kunde wirklich dafür, wie die Suche seinen Benutzern präsentiert wird? Toll! Vielleicht sollten Sie sich etwas Zeit nehmen, um dieses Anliegen anzusprechen – fügen Sie es in die Elementcollage ein. Ist Ihr Kunde von den Call-to-Action-Buttons besessen? Fügen Sie sie in die Elementcollage ein. Diese Pick-and-Choice-Mentalität macht es einfach, jede Collage auf das zuzuschneiden, was in Ihrem Projekt am wichtigsten ist. Ihre Kunden werden dies sehr zu schätzen wissen.

Bei einem kürzlich durchgeführten Projekt mussten wir die Designrichtung für eine Neugestaltung der Webeigenschaften eines unserer Kunden festlegen. Katie Kovalcin (eine unserer Designerinnen) leitete die Designanstrengungen unseres Teams und sie entschied sich dafür, Collagen mit zwei Elementen zu erstellen, anstatt Homepage-Kompositionen zu erstellen.

Die Gesamtzeit, die wir in die Erstellung dieser beiden Designkonzepte investiert haben, betrug etwa 16 Stunden. Als ich Katie fragte, wie lange es gedauert hätte, wenn sie gebeten worden wäre, zwei Homepage-Comps zu machen, antwortete sie:

„In diesem Schritt, in dem sie versuchen, ihre neue Ästhetik herauszufinden, wäre es schwierig, diese Ästhetik zu finden, während sie gleichzeitig versuchen, die Hierarchie der Seite festzulegen und auch die Interaktionen herauszufinden. Es konnte also manchmal bis zu einer Woche dauern, die gesamte Homepage zu gestalten, um die Ästhetik herauszufinden , je nachdem, wie viel wir arbeiten mussten. Ich würde sagen, wahrscheinlich fast 25 bis 30 Stunden pro Person.

Aber abgesehen von der Elementcollage war es ziemlich einfach, mit dem Seitenlayout und all dem anderen Kram voranzukommen, da es nicht viel Mühe gibt, herauszufinden, welche Schaltflächenstile wir verwenden werden, oder Schriftarten oder Farben .“

Das heißt, durch die Verwendung einer Elementcollage haben wir die Zeit, die wir in die Etablierung einer Ästhetik gesteckt haben, geviertelt.

Es gibt einen weiteren wirklich interessanten Ausdruck in Katies obigem Zitat; Sie sagte: „Es wäre schwierig, diese Ästhetik zu finden, während man versucht, die Hierarchie der Seite zu gestalten und auch die Interaktionen herauszufinden.“ Mit anderen Worten, wenn Sie mit einer Homepage-Zusammenstellung beginnen, versuchen Sie, zu früh zu viel zu erreichen. Wenn wir zuerst einen kleineren Schritt machen (indem wir Elementcollagen oder Stilkacheln verwenden), können wir die vor uns liegenden Designherausforderungen aufteilen und meistern. Dies bringt unsere Kunden häufiger ins Gespräch und ermöglicht es uns, im Laufe der Zeit zu lernen, was zu einer besseren Arbeit führt.

Stil-Prototypen

Sie können sich Stilprototypen als interaktive Stilkacheln vorstellen. Die gleichen Arten von Dingen, die Sie in eine Stilkachel aufnehmen könnten – Markenzeichen, Überschriften, Absatzstile, Schaltflächenstile, Linkbehandlung, Farbempfehlungen – sind in einem Stilprototypen enthalten. Der einzige Unterschied ist, dass wir noch einen Schritt weiter gehen und es codieren.

Das Schöne daran ist, dass wir echten Webtyp, echte Farben, echte Hover-Zustände, Illustrationsstile mit Webvektoren und die Reaktion von Typ und grundlegendem Layout anzeigen können. Wir bitten unsere Kunden, sie in ihrem bevorzugten Browser zu überprüfen. Dies eröffnet Gespräche darüber, was es bedeutet, einen Browser zu unterstützen. Wenn sie beispielsweise einen Browser verwenden, der border-radius nicht unterstützt, sehen sie keine abgerundeten Ecken.

Wir können auch Stilprototypen in etwa einem Tag bauen, was uns die gleichen Effizienzvorteile bietet, die uns eine Stilkachel bietet. Kunden lieben sie, weil sie mit ihnen interagieren können. Sie können sie auf ihren Telefonen und Tablets sehen. Sie können anfangen, mit ihnen zu spielen.

In einer Welt, in der die meisten von uns glauben, dass Webdesigner Programmieren lernen sollten, sind Stilprototypen eine fantastische Einführung in das Schreiben von HTML und CSS. Aufgrund ihrer Einfachheit kann sogar ein nicht programmierender Designer herausfinden, wie man sie erstellt. Bevor sie es wissen, haben sie das Selbstvertrauen, Produktions-CSS zu verfeinern, anstatt die Änderungen, die sie sehen möchten, statisch zu simulieren.

Als wir die ursprüngliche Sparkbox-Website entworfen und kürzlich neu gestaltet haben, haben wir Stilprototypen verwendet, um eine Designrichtung festzulegen.

Atomares Design

Jeremy Keith stellte mir zum ersten Mal die Idee vor, das Design mit „den Atomen einer Website“ zu beginnen, während seiner Breaking Development Keynote mit dem Titel „There is No Mobile Web“. Brad Frost hat den Begriff bereits im Juni 2013 formalisiert, als er ein mentales Modell skizzierte, um sich dem Design eines „Systems von Komponenten“ für das Web zu nähern.

Die grundlegende Prämisse ist, dass wir bei unserer Arbeit fünf Granularitätsebenen berücksichtigen sollten, um wiederverwendbare Komponentensysteme zu erstellen. Die kleinste Ebene wird Atom genannt; Denken Sie an eine einfache HTML-Eingabe oder ein Label für eine Eingabe. Diese Atome können zu Molekülen kombiniert werden; Vielleicht besteht ein Suchmolekül aus einem Knopf, einem Label und einer Eingabe. Diese Moleküle können kombiniert werden, um Organismen zu bilden; Vielleicht enthält der Header einer Website die Such-, Marken- und Navigationsmoleküle. Diese Organismen werden zu Vorlagen und Seiten zusammengesetzt. Vorlagen sind voller generischer Daten; Seiten sind Vorlagen, in die echte Daten eingefügt wurden. All diese Theorien können uns helfen, modulareren, wiederverwendbaren und erweiterbaren Code zu erstellen.

Eine Sache, die ich gelernt habe, als wir unsere Projekte mit dieser Denkweise angegangen sind, ist, dass atomares Design viel einfacher ist, wenn Sie es zulassen, dass es sich aus dem Refactoring entwickelt. Eine übliche Arbeitsweise besteht für uns darin, eine kleine Komponente in HTML und CSS zu erstellen, ohne uns viel Gedanken über die Atome, Moleküle oder Organismen zu machen. Sobald wir das UX- und UI-Problem mit einer Schnittstelle gelöst haben, können wir diesen Code in eine atomare Struktur umgestalten. Dieser umgekehrte Ansatz bedeutet, dass wir keine Zeit damit verschwenden, darüber nachzudenken, was ein Molekül im Vergleich zu einem Organismus sein sollte. Stattdessen lassen wir zu, dass sich die verschiedenen Ebenen entwickeln, während sich das System selbst entwickelt.

Das Ergebnis eines atomaren Ansatzes ist eine Musterbibliothek, die in ein System integriert werden kann.

Musterbibliotheken

Eine Musterbibliothek ist genau das, wonach es sich anhört – eine Bibliothek der Muster, die in Ihrem System vorhanden sind. Heutzutage arbeiten viele Leute an Musterbibliothekslösungen; Leute wie Brad Frost, Anna Debenham, Jina Bolton und Bermon Painter haben über das Thema gesprochen und geschrieben. Tatsächlich haben Brad und Dave Olson eines der bekannteren Tools entwickelt, die heute verfügbar sind, Pattern Lab. Pattern Lab ist großartig, weil es Ihnen ermöglicht, den spezifischen Inhalt von den HTML-Modulen zu trennen, und es bietet ein atomares Framework, das es einfach macht, ein System von Mustern aufzubauen. Sie haben auch einige großartige Funktionen zum Testen hinzugefügt, während Sie sich in der Entwicklung befinden. Das Ganze ist sehr einfach lokal zum Laufen zu bringen und hat eine einfache Oberfläche, die einem Kunden leicht gezeigt werden kann. Wenn Sie in mustergesteuertes Design einsteigen möchten, ist dies ein fantastischer Ausgangspunkt.

In diesem Bereich passiert gerade viel, und es gibt viele andere Ressourcen für diejenigen von uns, die daran interessiert sind, mehr zu erfahren. Brad hat mit Anna Debenham und Brendan Falkowski (zusammen mit einigen anderen Leuten) zusammengearbeitet, um Website-Styleguide-Ressourcen zu erstellen. Dies ist eine enorme Sammlung vieler Beispiele, Artikel, Vorträge, Podcasts und mehr, die sich mit mustergesteuertem Design und Entwicklung befassen.

Bisher besteht die größte Herausforderung darin, einen Weg zu finden, eine Musterbibliothek auf dem neuesten Stand zu halten, nachdem die Muster in ein Backend-System integriert wurden. Ich habe noch nicht die perfekte Lösung dafür gesehen, aber es arbeiten viele kluge Köpfe daran. Sehen Sie sich Rizzo von Lonely Planet als großartiges Beispiel für eine Organisation an, die fleißig daran arbeitet, genau dieses Problem zu lösen. Auch wenn wir keine perfekte langfristige Lösung haben, habe ich enorme Vorteile bei der Gestaltung auf diese Weise gesehen. Es lässt Sie modular denken, und dies macht die Front-End-Arbeit, die wir leisten, viel einfacher zu integrieren und zu warten.

Was ist mit Haltepunkten?

Wann immer ich über Prozesse spreche oder schreibe, werde ich immer nach der Auswahl von Haltepunkten gefragt. Seltsamerweise kommt dieses Gespräch fast nie in unserer reaktionsschnellen Arbeit von Tag zu Tag auf. Sicherlich kommen einige Kunden zu uns, nachdem sie eine Menge Arbeit geleistet haben, um Analysen zu überprüfen und Geräte zu priorisieren – alles im Namen der Dokumentation der Haltepunkte des Systems. Diese Denkweise hat für mich nie viel Sinn gemacht.

Ich glaube, es war Stephen Hay, der es zuerst gesagt hat: „Fang klein an und füge einen Breakpoint hinzu, wenn die Seite kaputt geht.“ Unsere Websites haben oft Dutzende von Breakpoints – die meisten davon passen nicht zu gängigen Gerätegrößen. Wenn Sie feststellen, dass Ihre Inhalte und Ihr Design nicht mehr harmonieren, beheben Sie das Problem.

Nun gibt es einen Unterschied zwischen dem, was Stephanie Rieger große Haltepunkte und kleinere Haltepunkte nennt. (Ich habe auch gehört, dass sie Breakpoints und Tweakpoints genannt werden.) Lassen Sie mich jedes erklären.

Wichtige Haltepunkte

Wenn es Änderungen im Layout gibt, die erfordern, dass separate Module bei ihrer Designänderung zusammenarbeiten, verwenden wir einen gemeinsamen Haltepunkt (einen Haupthaltepunkt). Vielleicht haben Sie eine Layoutanpassung, die eine gestapelte Produktliste bei kleinen Darstellungsfensterbreiten in ein zweispaltiges Layout bei größeren Darstellungsfensterbreiten verschiebt. In diesem Fall sollten Sie verfolgen, wo diese Layoutverschiebung stattfindet, da wahrscheinlich viele andere Änderungen bei derselben Ansichtsfensterbreite vorgenommen werden müssen.

Die meisten unserer Arbeiten haben zwischen drei und sechs große Haltepunkte. Diese werden in unserem Workflow oft als Sass-Variablen festgelegt, damit wir später an einer Stelle Änderungen daran vornehmen können. Es ist auch üblich, dass wir eine Reihe wichtiger Breakpoints für wichtige Abschnitte einer Website haben. Beispielsweise haben wir möglicherweise drei Haupthaltepunkte in der Kopfzeile unserer Website und drei völlig unterschiedliche Haupthaltepunkte in der Fußzeile. Dies hält unsere Arbeit modular und ermöglicht es diesen Abschnitten, sich unabhängig voneinander zu entwickeln, während sie dennoch den Zusammenhalt mit dem System als Ganzes aufrechterhalten.

Kleinere Haltepunkte

Wenn subtilere Änderungen an Schrift oder Abstand erforderlich sind, können wir immer noch eine Medienabfrage verwenden, um diese Anpassungen vorzunehmen (ein kleiner Haltepunkt). Dies sind in der Regel einmalige Stiländerungen für Dinge wie die Schriftgröße (um die Zeilenlänge in Schach zu halten) oder um den Abstand zu erhöhen, wenn die Breite des Ansichtsfensters zunimmt. Diese geringfügigen Anpassungen zeigen eine tiefe Liebe zum Detail, die Ihre Arbeit wirklich von anderen abheben kann.

Anstatt dafür Präprozessorvariablen zu verwenden, verwenden wir normalerweise nur hartcodierte Zahlen. Gelegentlich haben wir auch Präprozessorberechnungen verwendet, um diese relativ zu einem wichtigen Haltepunkt zu halten. Wenn wir zum Beispiel einen großen Breakpoint bei 30em namens $bp_header-show-nav haben, möchte ich vielleicht die Schriftgröße einer Überschrift bei 5em über dem $bp_header-show-nav . In diesem Fall würde das um 35 Uhr passieren. Sollten wir diesen großen Haltepunkt irgendwann in der Zukunft auf 32 Uhr verschieben, würde die kleine Änderung dann bei 37 Uhr erfolgen. Relatives Denken mit kleineren Breakpoints kann hilfreich sein, wenn Sie vermuten, dass sich die großen Breakpoints ändern könnten. Sie müssen von Fall zu Fall Ihr Urteilsvermögen einsetzen, um die besten Entscheidungen zu treffen.

Weiterführende Lektüre

Weitere Informationen zu Haltepunkten finden Sie in diesen Artikeln:

• „Es gibt keinen Haltepunkt“
• „Das Dazwischen“ von Mark Boulton
• „Pragmatisches Responsive Design“ von Stephanie Rieger

Übergang nach draußen

Heutzutage reicht es nicht aus, nur großartige Websites zu erstellen. Wir müssen auch die Langlebigkeit dessen berücksichtigen, was wir bauen. Während Ansätze wie atomares Design hilfreich sein können, müssen wir noch mehr tun. Im Moment beinhalten die meisten unserer Projekte eine Art Schulungskomponente – und ich spreche nicht davon, dem Kunden beizubringen, wie man das CMS verwendet. Wenn Organisationen beginnen, den Wert, den das Web ihnen bietet, wirklich zu verstehen, entscheiden sie sich, ihre eigenen Teams aufzubauen, um ihre Web-Eigenschaften zu besitzen und zu pflegen. Wenn wir etwas Dauerhaftes bauen wollen, müssen wir sicherstellen, dass das Team, das unsere Arbeit übernimmt, in der Lage ist, sie ordnungsgemäß zu warten. Aus diesem Grund führen wir viel eingehendere Schulungen zu den Techniken durch, die wir zum Erstellen für das Web verwenden.

Glücklicherweise gibt es heute viele gemeinsame Wege, um den Übergang anzugehen. Jedes Repo, das wir in der Quellcodeverwaltung erstellen, hat eine nützliche Readme-Datei; wir liefern automatisierte Tests, die unseren Code unterstützen; und wir arbeiten an Möglichkeiten, das Leistungsbudget eines Projekts umzustellen, damit unsere Kunden weiterhin die Geschwindigkeit ihrer Websites beibehalten können. Neben dem atomaren Denken liefern wir auch funktionierende Beispiele für von uns gebaute Subsysteme. Beispielsweise ist es üblich, dass wir uns überlegen, wie Typografie in allen Web-Eigenschaften im Kontext der Marke eines Kunden funktioniert, daher stellen wir möglicherweise auch eine detaillierte Dokumentation zu diesem typografischen System sowie eine Seite mit Beispielen zur Verfügung, die zeigen, wie es verwendet wird. Diese Art von Ergänzungen zu unserer Arbeit machen es viel einfacher, wenn wir den Code von unserem Team an das Team unseres Kunden weitergeben.

All dies hat auch tiefere Auswirkungen. Das Verständnis, wer das von Ihnen erstellte System warten wird, sollte auch Ihre Entscheidungen bezüglich der Technologiewahl und der Entwicklungstechnik beeinflussen. Mit anderen Worten, wenn das Webteam Ihres Kunden nicht bereit ist, Grunt mit Assemble und einem lokalen Server von der Befehlszeile aus zu verwenden, müssen Sie eine Arbeitsweise finden, die seinen Fähigkeiten besser entspricht. Denken Sie daran, Sie bauen das für sie.

Es war auch von großem Nutzen, die Webdesign- und Entwicklungsteams unserer Kunden einzuladen, mit uns an dem Projekt teilzunehmen. Das Projekt als Gelegenheit zu nutzen, um das Team Ihres Kunden zu schulen, zeigt einen unglaublichen Wert und macht Sie zu einer leichten Wahl unter Ihren Mitbewerbern.

Menschen über den Prozess

Eine letzte Sache, die ich bei der ständigen Weiterentwicklung unseres Workflows gelernt habe, ist, dass der Prozess, den Sie verwenden, viel weniger wichtig ist als die Menschen, die ihn verwenden. Wenn Sie bessere Webprodukte entwickeln möchten, beginnen Sie mit der Entwicklung Ihrer Mitarbeiter. Dies bringt Sie weiter als jede Optimierung Ihres Prozesses oder Workflows.

Halten Sie Ihr Team bei Laune

In diesem Sinne empfehle ich die Lektüre von Flow von Mihaly Csikszentmihalyi. In diesem Buch erklärt er seine Forschungen zum besseren Verständnis des individuellen Glücks. Er beschreibt, was er den „Flusskanal“ nennt, indem er das Fähigkeitsniveau auf der x -Achse gegen das Herausforderungsniveau auf der y -Achse aufträgt. Der Strömungskanal ist der Bereich, in dem Ihr Können auf eine angemessene Herausforderung stößt. Eine zu große Herausforderung für Ihre Fähigkeiten erzeugt Angst und eine zu geringe Herausforderung für Ihre Fähigkeiten führt zu Langeweile.

Dies lässt sich auf das übertragen, was wir tun, indem wir uns überlegen, wo wir uns in unserer täglichen Arbeit herausfordern. Bei Sparkbox sprechen wir von einer Kultur des Lernens. Das bedeutet (hoffentlich), dass die Fähigkeiten meines Teams kontinuierlich zunehmen. Daraus folgt, dass wir, um glücklich zu sein, ständig wachsende Herausforderungen finden müssen, die unseren ständig wachsenden Fähigkeiten entsprechen. Es liegt in unserer Verantwortung, diesen Innovationsbedarf mit finanzieller Verantwortung in den Budgets unserer Kunden in Einklang zu bringen.

Das ist schwierig. Für uns bedeutet das, dass wir aufhören müssen, das Rad neu zu erfinden; Dies hat uns veranlasst, Bibliotheken mit gut getesteten Schnittstellenelementen in Betracht zu ziehen, anstatt dieselben Probleme bei jedem Projekt wiederholt zu lösen. Das bedeutet, dass wir verstehen müssen, wofür jeder unserer Kunden Geld ausgeben sollte , um innovativ zu sein. Und es hat einiges an Transparenz zwischen diesen Kunden und unserem Team erfordert, damit wir alle auf derselben Seite sind.

Am Ende sorgt es für ein zufriedeneres Team – eines, das seine Arbeit liebt, weil es sie auf die richtige Weise herausfordert. Und es sorgt für einen zufriedeneren Kunden – einen, der Ihre Empfehlungen respektiert, wo und warum er investieren sollte. Das ist für alle Beteiligten hervorragend.

Weiter

Dies ist der Teil, in dem ich Sie zutiefst inspiriere und Sie ermutige, sich in eine mutige neue Welt des Webdesigns zu wagen. Aber um ehrlich zu sein, habe ich mich bemüht, eine abschließende Stimmung für dieses Kapitel zusammenzufassen.

Nach einigem Nachdenken glaube ich, dass das daran liegt, dass das Schreiben im Prozess nie wirklich abgeschlossen ist.

Ich hoffe, dass Sie nach dem Lesen dieser Worte inspirierter geworden sind, in Ihr eigenes Verständnis der Funktionsweise des Webs zu investieren, und eher bereit sind, in das Verständnis Ihrer Teamkollegen zu investieren. Ich hoffe, Sie haben sich darauf gefreut, einen neuen Ansatz auszuprobieren, aber ich hoffe auch, dass Sie sich befähigt gefühlt haben, diese Seiten zu zerreißen, wenn sie für Sie nicht funktionieren. Nur Sie, Ihr Team und Ihr Kunde können herausfinden, wie Sie ein Projekt am besten angehen. Das ist die Natur dessen, was wir tun.

Die Zeit ist jetzt – also ran an die Sache!