Responsivt design

Og udviklingsrollen i design

Dette er et dyb dykke ned i udviklingsrollen i designprocessen med fokus på responsivt design. Det er rettet mod designledere / ledere og udviklere, der arbejder med designteam, og visuelle designere, der ønsker at blive bedre webdesignere. Jeg vil forsøge at udlægge problemerne og foreslå praktiske løsninger. Jeg håber, det hjælper.

Responsiv webdesign. En mørk kunst?

Det er 2018. Hvorfor taler vi stadig om lydhør design?

Jeg lærte først responsivt design tilbage i 2011. Jeg begyndte med at læse Ethan Marcottes bog, 'Responsive Web Design'.

En mørk kunst af webdesign?

Responsivt design har været en ting i ca. 8-9 år nu. I de tidlige dage var det direkte imponerende at se et responsivt websted! Næsten en 'mørk kunst' af webdesign. Men det var længe siden.

I min rolle som enten designer eller udvikler finder jeg det underligt, at jeg stadig bliver bedt af klienter, agenturer og designere om:

“… Et responsivt websted…”

Min første tanke er altid:

'Nå, selvfølgelig ...'

Men meget af mit freelance webudviklingsarbejde involverer 'at gøre tingene lydhøre'. Designere beder mig om at opbygge et websted og derefter sende mig en mockup af et websted til kun skrivebordet. Og mit første spørgsmål er altid:

”Hvordan ser det ud på mobil? På tablet? ”

Tænk ud over skrivebordet

For at citere fra Ethans bog:

Tænk ud over skrivebordet, og design design, der svarer til dine brugers behov, uanset hvor stor eller lille skærmen er.

Det er min oplevelse, at visuelle designere, selv nu, ikke gør dette. Eller i det mindste ikke at gøre det godt nok.

En rædselshistorie om webdesign er gået galt

For sammenhæng vil jeg dele min værste virkelige oplevelse af webdesign gået galt. Naturligvis vil jeg ikke navngive navne. Jeg vil bare sige, at webstedet modtog betydelig trafik, herunder et højt volumen på mobil. Og at virksomheden var afhængig af salg fra deres hjemmeside. Så det var en stor ting at få det rigtigt!

Et firma havde brugt 3+ måneder og godt over $ 100.000 på en massiv omdesign af deres websted. De havde skabt et smukt konceptarbejde, men de var intetsteds tæt på et byggeklar design, og en hård lanceringsdato voksede smerteligt tæt.

Holdet havde ikke så meget som tænkt over det, hvordan det ville arbejde ud over skrivebordet. Og da jeg spurgte teamet ansvarligt om, hvordan noget af det ville fungere i andre størrelser, fik jeg bare blanke udtryk tilbage, som om jeg stillede skøre spørgsmål! De så virkelig ikke det som en del af deres job at tænke på disse ting.

De havde kun designet et smukt billede af et websted. Ikke noget, der kunne bygges.

Nu foreslår jeg ikke, at en periode med designkonceptudforskning ikke er umagen værd, før jeg kom i produktionsklar design… Men de havde udtømt næsten hele projektets tidslinje, og bygningen var nu godt bagefter planen (eller rettere sagt, det var ikke startet).

Da jeg åbnede deres første PSD, opdagede jeg, at webstedets beholder var cirka 1.750 px bred. Hvis du ikke allerede gisper, skal du overveje, at denne bredde kun ville have fungeret for 1-5% af trafikken!

Efter lidt grave blev grundene til alt dette tydelige:

I flere måneder havde der været et team af visuelle designere, der kærligt lavede pixels i isolation fra alle, der har nogen respons eller udviklingskendskab.

Fortællende havde de gennemgået deres arbejde med store tv-skærme og trykt mockups på små stykker papir, som var fastgjort på en studievæg. Utroligt nok havde ingen under denne proces overvejet, hvordan det rent faktisk ser ud i en webbrowser, så meget mindre på mindre skærme og mobile enheder.

I sidste ende lancerede de (noget) på deadline. Men med kun halvdelen af ​​hjemmesiden bygget, et utal af problemer og en masse meget ulykkelige interessenter, der beder grimt om:

"Hvordan skete dette?!"

Udviklerne finder ud af det

Dette er desværre, hvordan en masse designere synes.

Jeg har arbejdet på utallige projekter, hvor jeg var nødt til at tage et desktop-design og omdanne det til et fungerende, bygges, responsivt websted.

Som designer udfylder jeg hullerne i andre designerers arbejde. Men som udvikler går jeg ud over * for at afslutte, hvad designeren skal have.

* Bemærk: Ærligt, jeg nyder faktisk (nogle gange) denne udfordring som kreativ udvikler. Dette er mere at sige; Dit gennemsnitlige udvikler / udvikling team vil ikke sætte pris på dette.

Hvad kan vi gøre ved det?

Jeg tror, ​​det kommer til en ændring i tankegangen:

  • At tænke responsivt.
  • At revurdere din designproces.

Senere i denne artikel vil jeg dække nogle ting, jeg har forsøgt med designteams, som jeg har arbejdet med, som viste sig at være en succes. Men først; Den mest omstridte del af denne artikel ... Afbryd dig selv ...

Tilfældet for designere, der lærer at kode

Jeg stikker min hals ud her ... Men freak out! Fortsæt med at læse for min fulde begrundelse. Det er ikke så 'sort og hvidt', som du måske tror ...

Denne tankegang af "udviklerne vil finde ud af det" er ikke god nok.

Imidlertid er en erfaren designer mere end i stand til at være en god lydhør webdesigner, hvis de tænker lydhør.

Det er ikke så sort / hvidt, som 'designere skal kode'. Det er ikke. Men det hjælper.

Hvis du ikke rigtig forstår, hvordan noget fungerer, vil du kun nogensinde virkelig tage et stikk på det. Men udviklere ønsker ikke, at designere tager en kniv ved det og overlader det til dem at finde ud af, hvordan det rent faktisk fungerer.

Vi er alle nødt til at gøre det bedre - uanset om det er designere, der lærer at kode, eller arbejde med visuelle designere for at lære dem, hvordan man designer bedre, lydhøre websteder.

Dette er en gravering fra det 16. århundrede, kaldet 'To flayede mænd og deres skeletter' af den italienske billedhugger, Domenico del Barbiere.

Dette kunstværk er repræsentativt for italienske renæssancekunstnere som de store Leonardo da Vinci og Michelangelo, der dissekerede døde menneskelige kropper for at få en bedre forståelse af, hvordan muskler fungerer, så de kunne skabe mere realistiske malerier og skulpturer.

Denne praksis er et utroligt eksempel på dedikation til dit håndværk. Jeg foreslår ikke, at vi begynder at dissekere vores websteds brugere eller webudviklere! Men det er god mad at tænke over, hvordan:

At få en bedre forståelse af, hvordan noget fungerer, er afgørende for at gøre dit bedste arbejde.

Afskæring af en populær analogi

Hvis du nogensinde har drøftet 'skulle designere kende kode' med visuelle designere, har du sandsynligvis hørt denne linje:

”Men arkitekter ved ikke, hvordan man bygger!” Gotcha!

Altså nej. De fleste arkitekter kan ikke bygge en bygning. Men en god arkitekt vil have en god idé om, hvad der går ind i det. De tegner ikke bare smukke billeder af bygninger. De udarbejder skemaer. De kender de anvendte materialer - hvordan de ser ud, føles, reagerer på forskellige lys osv.

Min far var en kvantemåler. Hans job involverede risikovurdering og satte en pris på en arkitekts - ofte urealistiske - vision. Og forståeligt nok var han ikke glad for nogle arkitekter, han arbejdede med! (Lyder velkendt af forholdet mellem visuelle designere og udviklere? ”)

Men de bedste arkitekter, han arbejdede med - dem, der virkelig kendte deres handel - designet mere realistiske, byggelige bygninger, hvilket sparer alle en masse tid og penge. Og han elskede at samarbejde med disse arkitekter! Ligesom udviklere elsker at arbejde med designere, der kender deres ting. Hvilket skaber en sundere arbejdskultur og et bedre slutprodukt.

Mit ærlige råd er:

Lær hvordan du bygger det, du designer. Det vil simpelthen gøre dig til en bedre webdesigner. Jeg tror, ​​du vil blive overrasket over, hvor meget du nyder det. Det er sjovt og meget tilfredsstillende at bringe dine egne kreationer til live og forbedre dem i browseren!

Men hvis ikke:

Alt dette er ikke at sige, at visuelle designere ikke kan være gode webdesignere eller blive undervist i responsivt design. De er bare nødt til at lære at tænke responsivt - at tænke som en udvikler uden egentlig at kende kode.

To måder at nærme sig responsiv webdesign på

Der er to måder, jeg nærmer mig webdesign, men tankeprocessen - denne opfattelse af at tænke responsivt - er altid den samme. Hvilket, tror jeg, er nøglen.

Hvor meget jeg faktisk designe visuelt (dvs. oprette detaljerede mockups) afhænger i det væsentlige af, hvem der bygger det.

Fremgangsmåde 1: Når en anden skal bygge det, jeg designer

I dette tilfælde som designer:

  • Jeg designer hvert breakpoint.
  • Jeg sørger for, at jeg dækker alle scenarier og tilstande.
  • Jeg leverer responsive skabelondesign.
  • Jeg leverer et styleguide, der dækker noget, der ikke er indlysende i de visuelle design, som svævertilstande osv.

Og slutproduktet ser sådan ud:

Adobe Portfolio marketing website (2016) design case study

Fremgangsmåde 2: Når jeg skal bygge det, jeg designer selv

I modsætning til hvad jeg har sagt om at dække alle breakpoints og scenarier - i dette tilfælde - designer jeg kun til desktop. Men jeg tænker altid på og forestiller mig, hvordan det kunne se ud på mindre skærme. Da jeg er den, der bygger den, går jeg så hurtigt som muligt ind i browseren for at validere mine ideer.

Et eksempel på denne tilgang er mit personlige projekt, Club of the Waves:

Casestudie af Club of the Waves-design

Som du kan se ovenfor, har jeg kun hånet kernesiderne på skrivebordet.

Min designproces gik nogenlunde sådan:

  • Dette var en omdesign af et eksisterende websted. Så jeg brugte Google Analytics til at finde ud af, hvilken browserstørrelse 'de fleste' ser webstedet på. Derefter designede jeg mine desktopmodeller, så de svarede til den størrelse.
  • Derfra designede jeg resten i browseren - skrev kode - og så mine ændringer ske live. På denne måde kan jeg finpudse størrelser, afstand, layout og animation til mit hjerte indhold.
  • Og jeg kan teste det i forskellige browserstørrelser og tilføje de nødvendige breakpoints og medieforespørgsler, som jeg går.

Et andet eksempel på denne tilgang til webdesign er Owl Studios websted. Jeg hånede det på skrivebordet, som det ses nedenfor:

Owl Studios design case study

Og så havde jeg det sjovt i browseren:

Jeg havde ingen reel plan for, hvordan webstedet ville animere. Jeg følte det bare, skrev kode og opdaterede browseren, indtil jeg var tilfreds med det. Det var meget 'en udviklings ting', men 100% del af designprocessen.

Og det samme "design i browseren" -processen gælder for alle breakpoints. Nedenfor kan du se skærmbilleder af, hvordan det endte med at se ud på mobilen:

Spørgsmålet om finjustering

Jeg har lige beskrevet, hvordan jeg finjusterer et design i browseren - tilføjer animation, finjusterede størrelser og afstand osv.

Tænk på, hvor let, effektivt og hurtigt det er for en kreativ udvikler at gøre. Forestil dig nu en designer, der prøver at videresende de samme tweaks til en udvikler ...

  • Forsyner du dem med runde efter runde med justeringer via e-mail?
  • Hunder du dem på Slack?
  • Sender du snesevis af GitHub-problemer?
  • Leverer du dem en ny designfil, der fremhæver ændringerne flere gange?
  • Eller skal du sidde ved siden af ​​dem og fortælle dem, hvad de skal gøre !?
Jeg lover dig, ingen udvikler vil have en designer over deres skulder, bagkørsel!

Men hvordan du gør det, kan denne frem-og-tilbage-proces være meget tidskrævende, ineffektiv og frustrerende for alle.

Udvikling er design

Designere, produktledere, designledere og endda udviklere er nødt til at stoppe med at tænke på udvikling som at være adskilt fra design.

Og det behøver ikke at betyde:

  • 'Designere skal kode.'
  • Eller; 'Udviklere skal designe.'

Det betyder; Vi skulle arbejde sammen.

HTML, CSS og endda JavaScript i dag er en del af designprocessen.

Design stopper ikke, når du forlader Sketch, Photoshop eller XD. Eller når du først har lanceret et websted eller et produkt.

  • Vi justerer vores designs i browseren.
  • Vi tester vores designs med rigtige mennesker,
  • Derefter arbejder designere og udviklere sammen for at gentage designet.

Webstedsanimation er måske det mest indlysende eksempel på, hvordan udvikling er design. Vores branche er blevet besat af animerende websteder. Men en designer gør ikke det *, en udvikler er det.

* Og jeg taler ikke om designere, der bruger fancy design prototypesoftware til at oprette videoer og simuleringer, der imiterer belastningstilstande og interaktioner. Undskyld. Det er ikke rigtigt. En udvikler er stadig nødt til at genskabe, hvad designeren gjorde - så tæt som de realistisk kan - inden for budgettet og tidslinjen.

Epikurrence №6 og grundlæggende kultur, som det fremgår af: 'Åndeliv i digitale produkter'

Hvis det at udvikle ting som ovenstående ikke betragtes som kreativt eller en del af designprocessen ... Så ved jeg ikke, hvad der er.

Så hvad angår udviklingen i design:

Gør:

Medtag front-end og kreative udviklere i designprocessen. Få deres udtalelser tidligt, og luk alle problemer ud, før det er for sent.

Må ikke:

Bare dump designerne på udviklerne i slutningen af ​​processen, og håb, at det er okay. Eller du vil slutte med en rædselshistorie for at konkurrere med mine tidligere!

Du er et team, handle som et

En enkel måde at tilskynde designere og udviklere til at arbejde bedre sammen er at få dine design- og udviklingshold til at sidde sammen. Eller i det mindste tæt på hinanden. Adskill dem ikke.

  • Opdelingen af ​​dit hold sætter unødvendige grænser.
  • Opretter en splittende kultur.
  • Og gør samarbejde vanskeligt.

Jeg har oplevet, at dette går galt så mange gange hos store virksomheder og designbureauer. Det er ikke sundt.

Tænker responsivt

Ingen designer har til hensigt at forkaste udviklere, men nogle gange designer de utilsigtet ting, der ikke fungerer, eller som ikke dækker alle baser. Som nogen, der koder, forstår jeg det, men designere, der rent fokuserer på visuals, gør det ofte ikke. De er nødt til at lære at tænke responsivt - at tænke som en udvikler.

Så hvordan lærer vi visuelle designere at tænke responsivt?

Svaret er ikke at råbe på dem, når de begår fejl. Det er at uddanne dem, så de danner bedre vaner i deres designproces og tankegang.

Nedenfor er 5 ting, jeg prøvede med designteam i NYC, hvilket viste sig at være effektivt:

1) Design med lydhør skabeloner

Her er en skisseskabelon, jeg oprettede for et team af designere på et tidligere job:

Denne tilgang er en god måde at undervise designere til at tænke igennem alle scenarier og nærme sig deres design mere responsivt.

En god lydhør skabelon inkluderer:

  • Et tegnebræt til at repræsentere hvert breakpoint.
  • Hver med det responsive gitter tydeligt synligt.
  • I dette tilfælde svarede breakpoints groft til en 'stor' og en 'lille' desktopvisning, tablet (portræt) og mobil.

Nu skal jeg sige; Jeg synes, det er vigtigt at ikke tænke på et websted som bare på 'desktop', 'tablet' og 'mobile'. Eller 'breakpoint 1', 'breakpoint 2' og så videre ... Men det er en effektiv måde at indramme det til ikke-tekniske mennesker. Og god nok til en visuel designtilgang som denne.

Jeg tror, ​​at den vigtige lektion her er:

Stress test

Det er usandsynligt, at du løser ethvert responsivt problem med en templet mockup-tilgang som denne, men i det mindste giver det designere et forenklet middel til stresstest af deres design. Og med held og hell, opdager eventuelle fejl i designet, før de overleverer det til en udvikler.

2) Det er ikke en 'version'

Jeg tror, ​​at en stærk erkendelse for nogle mennesker er at stoppe med at tænke på mobil og tablet som en 'version'.

  • Det er ikke en version.
  • Det er det samme websted.
  • Det er den samme HTML-kode.
  • Kun CSS er ændret.

'Version' er en arv fra en æra med omdirigering af mobiltrafik til et helt andet websted, der er målrettet mod mobilbrugere - en æra, der erstattede responsive websteder. Vi er nødt til at komme videre fra dette arv.

Jeg tror, ​​at dette 'version mindset' er det, der holder nogle designere tilbage fra at designe responsivt.

"En anden vil finde ud af den anden version ..."

Eller;

“Ikke så mange mennesker vil se det på mobil ...”

Nå, denne holdning er ikke længere god. Fordi den 'anden version' får meget mere opmærksomhed, end nogle er klar over eller er interesserede i at tænke. Det er en del af designerens job at tænke ud over skrivebordet.

3) Design til alle scenarier, ikke kun i det bedste tilfælde

Tænk på et lydhør layout som:

  • Et UI, der er næsten umuligt at bryde.
  • Det kan tage enhver mængde indhold og tegn.
  • Og det fungerer på alle browsers bredde eller højde.

Alt for ofte ser jeg design, der kun fungerer til et begrænset antal tegn, men du kan garantere, at klienten skriver flere ord i deres overskrift end “Lorem Ipsum.”

Design ikke med et praktisk antal tegn, der passer til dit design.

Tænk på designet og indholdet som noget, der fungerer sammen. Ikke uanset hinanden.

Design ikke ting for at imponere dine designervenner eller for at vinde en pris eller for at få likes på Dribbble. Grundlæggende dit arbejde i virkeligheden og design med reelt indhold og data - eller en tæt tilnærmelse.

4) Tænk på procenter, ikke pixels

Du designer muligvis noget, der skal være 100px bredt i din designsoftware. Men i browseren er den 100 px en procentuel bredde på dens container. Når browserbredden bliver mindre, bliver dine 100 px mere som 80 px, 60 px, 40 px og så videre.

Tænk nu på det indhold, du har i det 100px-område ...

  • Fungerer det i mindre bredde end 100 px?
  • Hvis ikke, skal du enten tænke om layoutet eller indholdet igen.
  • Eller opret et breakpoint for at dække, hvad der sker, når det ikke længere fungerer.

Jeg understreger dette tankegang i procentdel og ikke pixels, fordi det er det, som billeddesignere på mit sidste job kæmpede mest. De kunne bare ikke få hovedet omkring dette begreb om, at tingene bliver forholdsmæssigt smallere, og hvorfor det er et designproblem.

Jeg oprettede denne hurtige mockup (ovenfor) for at demonstrere dette punkt til junior (og senior) billeddesignere på mit sidste job, hvilket viste sig virkelig effektivt!

  • Det viser det samme 12 kolonnetetværk ved 2 forskellige browserbredder.
  • Det viser tydeligt, hvordan gitterkolonnerne bliver smalere,
  • Og hvilken virkning det har på den samme tekst, der spænder over de samme 4 kolonner i begge scenarier.

Nogle gange er det at se at tro. At demonstrere ting som dette, i en designmodel eller en hurtig demo i browseren (via en service som Codepen) kan være nøglen til at få folk til at forstå.

5) Se design i browseren eller på en enhed

Vender tilbage til min rædselshistorie tidligere: der laves let fejl, når vi ikke bygger vores arbejde i virkeligheden. Så:

  • Gennemgå ikke (kun) dit arbejde på store skærme eller tv-skærme.
  • Udskriv ikke (kun) udlister og se dem fastgjort på en væg.

Ingen af ​​disse giver en nøjagtig skildring af, hvad slutbrugeren vil se. Hvilket virkelig er det eneste, der betyder noget.

Vær også forsigtig, når du designer på nethindeskærme og små bærbare skærme. For eksempel er det svært at designe et websted på en MacBook - eller en hvilken som helst bærbar computer, fordi du sandsynligvis ikke kan se hele bredden på siden i designsoftwaren. Så du zoomer ind og ud for at se værket, mens du designer. Men problemet er dette: kun du, dine designer venner og dine Dribbble tilhængere ser dit arbejde sådan. Slutbrugeren vil ikke.

Forhåbentlig demonstrerer dette mit punkt:

Til venstre er din webside designmodel. Dit team gennemgår det som et samlet, sammenhængende design, ligesom du ville gøre som et stykke grafisk design.

Men til højre er det, hvad brugeren faktisk ser - i browseren - når de ruller. Der er en stor forskel! Så du skal overveje den virkelighed mere end siden som helhed.

Dette er ikke grafisk design, det er webdesign.

En god måde at undgå dette problem er at komme til en indbygget prototype så hurtigt som muligt. Eller den næste bedste ting, noget som en InVision-prototype. På denne måde kan dit team gennemgå arbejdet i browseren, som dine slutbrugere ville ... Eller i deres hånd på en mobilenhed.

Det er vigtigt at holde perspektiv og forankre dine designs i virkeligheden.

Opdatering: 2019. Jeg skrev en bog om systemdesign og retningslinjer for digitalt brand! https://designsystemfoundations.com