Reagerend ontwerp

En de rol van ontwikkeling in design

Dit is een diepe duik in de rol van ontwikkeling in het ontwerpproces, met een focus op responsief ontwerp. Het is gericht op ontwerpleiders / managers en ontwikkelaars die met ontwerpteams werken, en visuele ontwerpers die betere webontwerpers willen worden. Ik zal proberen de problemen op te lossen en praktische oplossingen voorstellen. Ik hoop dat het helpt.

Responsief webontwerp. Een donkere kunst?

Het is 2018. Waarom hebben we het nog steeds over responsive design?

Ik leerde voor het eerst responsive design in 2011. Ik begon met het lezen van het boek 'Responsive Web Design' van Ethan Marcotte.

Een donkere kunst van webdesign?

Responsief ontwerp is nu al zo'n 8-9 jaar iets. In het begin was het ronduit indrukwekkend om een ​​responsieve website te zien! Bijna een 'donkere kunst' van webdesign. Maar dat was lang geleden.

In mijn rol als ontwerper of ontwikkelaar vind ik het vreemd dat ik nog steeds door klanten, bureaus en ontwerpers wordt gevraagd om:

"... Een responsieve website ..."

Mijn eerste gedachte is altijd:

‘Nou ja, natuurlijk ...’

Maar veel van mijn freelance webontwikkelingswerk omvat ‘dingen responsief maken’. Ontwerpers vragen me om een ​​website voor ze te maken en me een model van een website met alleen een desktop te sturen. En mijn eerste vraag is altijd:

“Hoe ziet dit eruit op mobiel? Op tablet? '

Denk verder dan het bureaublad

Om te citeren uit het boek van Ethan:

Denk verder dan het bureaublad en maak ontwerpen die beantwoorden aan de behoeften van uw gebruikers, ongeacht hoe groot of klein het scherm is.

Het is mijn ervaring dat visuele ontwerpers dit zelfs nu nog niet doen. Of tenminste, het doet het niet goed genoeg.

Een horrorverhaal over webdesign is misgegaan

Voor de context wil ik mijn ergste echte ervaring met verkeerd ontworpen webontwerp delen. Uiteraard zal ik geen namen noemen. Ik zeg alleen dat de website veel verkeer heeft ontvangen, waaronder een groot volume op mobiel. En dat het bedrijf afhankelijk was van de verkoop van hun website. Het was dus een groot probleem om dit goed te krijgen!

Een bedrijf had meer dan 3 maanden en meer dan $ 100.000 besteed aan een enorm nieuw ontwerp van hun website. Ze hadden mooi conceptwerk gemaakt, maar ze kwamen nergens in de buurt van een ontwerp dat klaar was om te bouwen, en een harde startdatum kwam pijnlijk dichterbij.

Het team had er nog niet zo over nagedacht hoe het zou werken buiten de desktop. En toen ik het verantwoordelijke team vroeg hoe het allemaal in andere formaten zou werken, kreeg ik gewoon lege uitdrukkingen terug, alsof ik gekke vragen stelde! Ze zagen het echt niet als een onderdeel van hun taak om over deze dingen na te denken.

Ze hadden alleen een mooie foto van een website ontworpen. Niets dat zou kunnen worden gebouwd.

Nu suggereer ik niet dat een periode van ontwerpconceptverkenning niet de moeite waard is, voordat ze in productie klaar ontwerp komen ... Maar ze hadden bijna de hele projecttijdlijn uitgeput en de build lag nu ver achter op schema (of liever, het was niet begonnen).

Toen ik hun eerste PSD opende, ontdekte ik dat de websitecontainer ongeveer 1.750px breed was. Als je nog niet naar adem snakt, bedenk dan dat deze breedte slechts voor 1-5% van het verkeer zou hebben gewerkt!

Na een beetje graven werden de redenen voor dit alles duidelijk:

Maandenlang was er een team van visuele ontwerpers geweest die liefdevol pixels maakten, los van iedereen met enige responsieve of ontwikkelingskennis.

Veelzeggend hadden ze hun werk op grote tv-schermen bekeken en modellen op kleine stukjes papier geprint, vastgemaakt aan een studiomuur. Verbazingwekkend genoeg had niemand tijdens dit proces overwogen hoe het er eigenlijk uitziet in een webbrowser, laat staan ​​op kleinere schermen en mobiele apparaten.

Uiteindelijk lanceerden ze (iets) op de deadline. Maar met slechts de helft van de website, talloze problemen en heel veel ongelukkige belanghebbenden die boos vragen:

"Hoe is dit gebeurd?!"

De ontwikkelaars zullen het uitzoeken

Dit is helaas hoe veel ontwerpers denken.

Ik heb aan talloze projecten gewerkt waarbij ik een desktopontwerp moest nemen en er een functionerende, bouwbare, responsieve website van kon maken.

Als ontwerper vul ik de gaten in het werk van andere ontwerpers. Maar als ontwikkelaar ga ik boven en buiten * om af te maken wat de ontwerper zou moeten hebben.

* Opmerking: Eerlijk gezegd geniet ik eigenlijk (soms) van deze uitdaging als een creatieve ontwikkelaar. Dit is meer te zeggen; Uw gemiddelde ontwikkelaar / ontwikkelingsteam zal dit niet op prijs stellen.

Wat kunnen we eraan doen?

Ik geloof dat het neerkomt op een verandering in denkrichting:

  • Reactief denken.
  • Om uw ontwerpproces te heroverwegen.

Later in dit artikel ga ik enkele dingen bespreken die ik heb geprobeerd met ontwerpteams waarmee ik heb gewerkt en die succesvol zijn gebleken. Maar eerst; Het meest omstreden deel van dit artikel ... Zet je schrap ...

Het geval voor ontwerpers die leren coderen

Ik steek mijn nek hier uit ... Maar, word niet gek! Blijf lezen voor mijn volledige reden. Het is niet zo ‘zwart en wit’ als je misschien denkt ...

Deze mindset van ‘de ontwikkelaars komen er wel uit’ is niet goed genoeg.

Een ervaren ontwerper is echter meer dan in staat om een ​​goede responsieve webontwerper te zijn, als hij responsief denkt.

Het is niet zo zwart en wit als 'ontwerpers zouden moeten coderen'. Het is niet. Maar het helpt wel.

Als je niet echt begrijpt hoe iets werkt, zul je het alleen echt proberen. Maar ontwikkelaars willen niet dat ontwerpers het proberen en het dan aan hen overlaten om erachter te komen hoe het eigenlijk werkt.

We moeten allemaal beter doen - of dat nou ontwerpers zijn die leren coderen of samenwerken met visuele ontwerpers om hen te leren hoe ze betere, responsieve websites kunnen ontwerpen.

Dit is een gravure uit de 16e eeuw, door de Italiaanse beeldhouwer Domenico del Barbiere ‘Two Flayed Men and their Skeletons’ genoemd.

Dit kunstwerk is representatief voor Italiaanse renaissancekunstenaars, zoals de grote Leonardo da Vinci en Michelangelo, die dode menselijke lichamen ontleedden om een ​​beter begrip te krijgen van hoe spieren werken, zodat ze meer realistische schilderijen en sculpturen konden maken.

Deze oefening is een ongelooflijk voorbeeld van toewijding aan je vak. Ik suggereer niet dat we beginnen met het ontleden van de gebruikers van onze website of webontwikkelaars! Maar het is goed om over na te denken hoe:

Een beter begrip van hoe iets werkt, is van vitaal belang om uw beste werk te doen.

Een populaire analogie ontleden

Als je ooit hebt gedebatteerd 'moeten ontwerpers code kennen' met visuele ontwerpers, dan heb je deze regel waarschijnlijk gehoord:

"Maar architecten weten niet hoe ze moeten bouwen!" Gotcha!

Welnee. De meeste architecten kunnen geen gebouw bouwen. Maar een goede architect zal een goed idee hebben van wat erin gaat. Ze tekenen niet alleen mooie foto's van gebouwen. Ze stellen schema's op. Ze hebben kennis van de gebruikte materialen - hoe ze eruit zien, voelen, reageren op ander licht, enz.

Mijn vader was een kwantiteitsonderzoeker. Zijn taak bestond uit risicobeoordeling en het bepalen van een prijs voor de - vaak onrealistische - visie van een architect. En begrijpelijk, hij was niet dol op sommige architecten met wie hij samenwerkte! (Klinkt bekend in de relatie tussen visuele ontwerpers en ontwikkelaars? ”)

Maar de beste architecten met wie hij samenwerkte - degenen die hun vak echt kenden - ontwierpen realistischere, bouwbare gebouwen, waardoor iedereen veel tijd en geld kon besparen. En hij hield van werken met die architecten! Net zoals ontwikkelaars graag werken met ontwerpers die hun dingen kennen. Dat zorgt voor een gezondere werkcultuur en een beter eindproduct.

Mijn eerlijke advies is:

Leer hoe u kunt bouwen wat u ontwerpt. Je wordt er gewoon een betere webontwerper van. Ik denk dat je verrast zult zijn hoeveel je ervan geniet. Het is leuk en heel bevredigend om je eigen creaties tot leven te brengen en te verbeteren in de browser!

Maar als dat niet lukt:

Dit alles wil niet zeggen dat visuele ontwerpers geen goede webontwerpers kunnen zijn of responsive design kunnen worden geleerd. Ze moeten gewoon leren responsief te denken - te denken als een ontwikkelaar, zonder code te kennen.

Twee manieren om responsief webontwerp te benaderen

Er zijn twee manieren waarop ik webontwerp benader, maar het denkproces - dit idee van responsief denken - is altijd hetzelfde. Welke volgens mij de sleutel is.

Hoeveel ik eigenlijk visueel ontwerp (d.w.z. gedetailleerde mockups maak), hangt in wezen af ​​van wie het bouwt.

Benadering 1: Wanneer iemand anders gaat bouwen wat ik ontwerp

In dit geval, als ontwerper:

  • Ik ontwerp elk breekpunt.
  • Ik zorg ervoor dat ik alle scenario's en staten bestrijk.
  • Ik lever responsieve sjabloonontwerpen.
  • Ik lever een styleguide die alles bedekt wat niet duidelijk is in de visuele ontwerpen, zoals zweeftoestanden, enz.

En het eindproduct ziet er ongeveer zo uit:

Adobe Portfolio marketing-website (2016) ontwerp case study

Benadering 2: wanneer ik ga bouwen wat ik zelf ontwerp

In tegenstelling tot wat ik heb gezegd over het behandelen van alle breekpunten en scenario's - in dit geval - ontwerp ik alleen voor desktop. Maar ik denk er altijd aan en stel me voor hoe het eruit zou kunnen zien op kleinere schermen. Omdat ik degene ben die het bouwt, kom ik zo snel mogelijk in de browser om mijn ideeën te valideren.

Een voorbeeld van deze aanpak is mijn persoonlijke project, Club of the Waves:

Club of the Waves ontwerp case study

Zoals je hierboven kunt zien, heb ik alleen de kernpagina's op het bureaublad bespot.

Mijn ontwerpproces ging ongeveer als volgt:

  • Dit was een herontwerp van een bestaande website. Dus gebruikte ik Google Analytics om erachter te komen in welke browsergrootte 'de meeste mensen' de website bekijken. Vervolgens heb ik mijn desktopmodellen ontworpen om bij die grootte te passen.
  • Van daaruit heb ik de rest in de browser ontworpen - code schrijven - en mijn wijzigingen live zien gebeuren. Op deze manier kan ik de grootte, afstand, lay-out en animatie naar hartelust aanpassen.
  • En ik kan het testen op verschillende browsergroottes, terwijl ik onderweg alle vereiste breekpunten en media-vragen toevoeg.

Een ander voorbeeld van deze benadering van webdesign is de website van Owl Studios. Ik bespotte het op desktop, zoals hieronder te zien:

Case study van Owl Studios

En toen had ik er plezier in, in de browser:

Ik had geen echt plan voor hoe de website zou animeren. Ik voelde het gewoon, code schrijven en de browser vernieuwen totdat ik er blij mee was. Het was heel erg 'een ontwikkelingsding', maar 100% deel van het ontwerpproces.

En hetzelfde 'ontwerp in de browser' is van toepassing op alle breekpunten. Hieronder zie je screenshots van hoe het eruit zag op mobiel:

De kwestie van fijnafstemming

Ik heb zojuist beschreven hoe ik een ontwerp in de browser kan verfijnen - animatie toevoegen, afmetingen aanpassen en afstand, enz.

Bedenk hoe gemakkelijk, efficiënt en snel dat is voor een creatieve ontwikkelaar. Stel je nu een ontwerper voor die dezelfde tweaks probeert door te geven aan een ontwikkelaar ...

  • Bezorg je ze ronde na ronde van tweaks per e-mail?
  • Hound je ze op Slack?
  • Dien je tientallen GitHub-problemen in?
  • Lever je ze meerdere keren een nieuw ontwerpbestand met de wijzigingen?
  • Of ga je naast ze zitten en vertel ze wat ze moeten doen !?
Ik beloof je, geen enkele ontwikkelaar wil een ontwerper over hun schouder, achterbank rijden!

Hoe je het ook doet, dit heen en weer proces kan voor iedereen erg tijdrovend, inefficiënt en frustrerend zijn.

Ontwikkeling is design

Ontwerpers, productmanagers, ontwerpmanagers en zelfs ontwikkelaars moeten niet langer denken dat ontwikkeling los staat van ontwerp.

En dat hoeft niet te betekenen:

  • 'Ontwerpers moeten coderen.'
  • Of; ‘Ontwikkelaars moeten ontwerpen.’

Het betekent; We moeten samenwerken.

HTML, CSS en tegenwoordig zelfs JavaScript maken deel uit van het ontwerpproces.

Het ontwerp stopt niet zodra u Sketch, Photoshop of XD verlaat. Of nadat u een website of product heeft gelanceerd.

  • We passen onze ontwerpen aan in de browser.
  • We testen onze ontwerpen met echte mensen,
  • Vervolgens werken ontwerpers en ontwikkelaars samen om het ontwerp te herhalen.

Website-animatie is misschien wel het meest voor de hand liggende voorbeeld van hoe ontwikkeling ontwerp is. Onze branche is geobsedeerd geraakt door het animeren van websites. Maar een ontwerper doet dat niet *, een ontwikkelaar wel.

* En ik heb het niet over ontwerpers die fancy design prototyping software gebruiken om video's en simulaties te maken die belastingstoestanden en interacties imiteren. Sorry. Dat is niet echt. Een ontwikkelaar moet nog steeds nagaan wat de ontwerper heeft gedaan - zo nauwkeurig als realistisch mogelijk is - binnen het budget en de tijdlijn.

Epicurrence №6 en Basic Culture, zoals te zien in: ‘Een nieuw leven inblazen in digitale producten’

Als het ontwikkelen van dingen zoals het bovenstaande niet als creatief wordt beschouwd, of als onderdeel van het ontwerpproces ... Dan weet ik niet wat het is.

Dus met betrekking tot de rol van ontwikkeling in ontwerp:

Do:

Betrek front-end en creatieve ontwikkelaars bij het ontwerpproces. Ontvang vroeg hun mening en verwijder problemen voordat het te laat is.

Niet doen:

Dump de ontwerpen gewoon aan de ontwikkelaars aan het einde van het proces en hoop dat alles goed is. Of je komt eerder met een horrorverhaal over de mijne, eerder!

Je bent een team, gedraag je als een

Een eenvoudige manier om ontwerpers en ontwikkelaars aan te moedigen beter samen te werken, is door uw ontwerp- en ontwikkelingsteams bij elkaar te laten zitten. Of tenminste, dicht bij elkaar. Scheid ze niet.

  • Het opdelen van uw team legt onnodige grenzen op.
  • Creëert een verdeeldheidscultuur.
  • En maakt samenwerking moeilijk.

Ik heb ervaren dat dit zo vaak misgaat bij grote bedrijven en ontwerpbureaus. Het is niet gezond.

Reagerend denken

Geen enkele ontwerper is van plan ontwikkelaars kwaad te maken, maar soms ontwerpen ze onbedoeld dingen die niet werken of niet alle basissen dekken. Als iemand die codeert, begrijp ik dit, maar ontwerpers die zich puur op visuals richten, doen dat vaak niet. Ze moeten leren responsief te denken - te denken als een ontwikkelaar.

Dus, hoe leren we visuele ontwerpers om responsief te denken?

Het antwoord is niet om tegen ze te schreeuwen als ze fouten maken. Het is om hen te onderwijzen, zodat ze betere gewoonten vormen in hun ontwerpproces en denken.

Hieronder zijn 5 dingen die ik heb geprobeerd met ontwerpteams in NYC, die effectief bleken:

1) Ontwerp met responsieve sjablonen

Hier is een schets-sjabloon die ik heb gemaakt voor een team van ontwerpers bij een vorige taak:

Deze benadering is een goede manier om ontwerpers te leren alle scenario's te overdenken en hun ontwerpen responsiever te benaderen.

Een goede responsieve sjabloon omvat:

  • Een tekengebied om elk breekpunt weer te geven.
  • Elk met het responsieve raster duidelijk zichtbaar.
  • In dit geval kwamen de breekpunten ongeveer overeen met een 'grote' en een 'kleine' desktopweergave, tablet (staand) en mobiel.

Nu zou ik moeten zeggen; Ik vind het belangrijk om een ​​website niet alleen als ‘desktop’, ‘tablet’ en ‘mobiel’ te beschouwen. Of ‘breekpunt 1’, ‘breekpunt 2’ enzovoort ... Maar het is een effectieve manier om het in te kaderen voor niet-technische mensen. En goed genoeg voor een visuele ontwerpbenadering zoals deze.

Ik denk dat de belangrijke les hier is:

Stresstest

Het is onwaarschijnlijk dat u elk responsief probleem met een dergelijke mockup-aanpak als deze oplost, maar het biedt ontwerpers op zijn minst een simplistische manier om hun ontwerpen te testen op stress. En met een beetje geluk, ontdekt eventuele gebreken in het ontwerp voordat ze het aan een ontwikkelaar overhandigen.

2) Het is geen ‘versie’

Ik denk dat een krachtig besef voor sommige mensen is om te stoppen met denken aan mobiel en tablet als een ‘versie’.

  • Het is geen versie.
  • Het is dezelfde website.
  • Het is dezelfde HTML-code.
  • Alleen de CSS is gewijzigd.

'Versie' is een oude term uit een tijdperk van mobiel verkeer omleiden naar een geheel andere website, gericht op mobiele gebruikers - een tijdperk dat responsieve websites heeft vervangen. We moeten verder gaan met deze oude term.

Ik denk dat deze ‘versiemindset’ is wat sommige ontwerpers ervan weerhoudt om responsief te ontwerpen.

"Iemand anders zal de andere versie achterhalen ..."

Of;

"Niet zo veel mensen zullen het op mobiel zien ..."

Nou, deze houding is niet meer goed genoeg. Omdat de ‘andere versie’ veel meer aandacht krijgt dan sommigen zich realiseren, of willen nadenken. Het is onderdeel van het werk van de ontwerper om verder te denken dan alleen desktop.

3) Ontwerp voor alle scenario's, niet alleen het beste scenario

Beschouw een responsieve lay-out als:

  • Een gebruikersinterface die bijna onmogelijk te breken is.
  • Het kan elke hoeveelheid inhoud en tekens bevatten.
  • En het werkt op elke browserbreedte of -hoogte.

Te vaak zie ik ontwerpen die alleen voor een beperkt aantal tekens werken, maar u kunt garanderen dat de klant meer woorden in de kop gaat schrijven dan "Lorem Ipsum".

Ontwerp niet met een handig aantal tekens dat bij uw ontwerp past.

Beschouw het ontwerp en de inhoud als iets dat samenwerkt. Niet los van elkaar.

Ontwerp geen dingen om indruk te maken op je designvrienden, om een ​​prijs te winnen of om likes op Dribbble te krijgen. Aard uw werk in de realiteit en ontwerp met echte inhoud en gegevens - of een goede benadering.

4) Denk in percentages, niet in pixels

U kunt iets ontwerpen dat 100 px breed is in uw ontwerpsoftware. Maar in de browser zal die 100 px een procentuele breedte van zijn container zijn. Dus, naarmate de browserbreedte kleiner wordt, zal uw 100 px meer op 80 px, 60 px, 40 px, enzovoort lijken.

Denk nu eens aan de inhoud die je hebt in dat 100px-gebied ...

  • Werkt het op een kleinere breedte dan 100 px?
  • Als dit niet het geval is, moet u de lay-out of de inhoud opnieuw bedenken.
  • Of maak een breekpunt om te dekken wat er gebeurt als het niet meer werkt.

Ik benadruk dit punt van denken in percentages en niet in pixels, want dit is waar visuele ontwerpers in mijn laatste baan het meest mee worstelden. Ze konden gewoon niet hun hoofd rond dit concept van dingen krijgen die proportioneel smaller worden, en waarom dat een ontwerpprobleem is.

Ik heb dit snelle model (hierboven) gemaakt om dit punt aan mijn laatste baan te laten zien aan junior (en senior) visuele ontwerpers, wat echt effectief bleek!

  • Het toont hetzelfde raster met 12 kolommen, op 2 verschillende browserbreedtes.
  • Het laat duidelijk zien hoe de rasterkolommen smaller worden,
  • En welk effect dat heeft op dezelfde tekst, verspreid over dezelfde 4 kolommen in beide scenario's.

Soms is zien geloven. Dit soort dingen demonstreren, in een ontwerpmodel of een snelle demo in de browser (via een service zoals Codepen) kan de sleutel zijn om mensen te laten begrijpen.

5) Bekijk ontwerpen in de browser of op een apparaat

Terugkomend op mijn horrorverhaal eerder: fouten worden gemakkelijk gemaakt als we ons werk niet in realiteit onderbouwen. Zo:

  • Beoordeel uw werk niet (alleen) op grote monitoren of tv-schermen.
  • Druk niet (alleen) modellen af ​​en bekijk ze vastgemaakt aan een muur.

Geen van beide geeft een nauwkeurige weergave van wat de eindgebruiker zal zien. Dat is echt het enige dat telt.

Wees ook voorzichtig bij het ontwerpen op retina-schermen en kleine laptopschermen. Het ontwerpen van een website op een MacBook - of een laptop - is bijvoorbeeld moeilijk, omdat u waarschijnlijk niet de hele breedte van de pagina in de ontwerpsoftware kunt zien. Je zoomt dus in en uit om het werk te bekijken terwijl je ontwerpt. Maar het probleem is dit: alleen jij, je designer-vrienden en je Dribbble-volgers zien je werk zo. De eindgebruiker niet.

Hopelijk toont dit mijn punt aan:

Links ziet u het ontwerp van uw webpagina. Je team beoordeelt het als een geheel, samenhangend ontwerp, net zoals een grafisch ontwerp.

Maar aan de rechterkant is wat de gebruiker daadwerkelijk ziet - in de browser - tijdens het scrollen. Er is een groot verschil! Je moet dus rekening houden met die realiteit, meer nog dan met de pagina als geheel.

Dit is geen grafisch ontwerp, het is webontwerp.

Een goede manier om dit probleem te voorkomen, is om zo snel mogelijk bij een gebouwd prototype te komen. Of, het volgende beste, zoiets als een InVision-prototype. Op deze manier kan uw team het werk in de browser bekijken, zoals uw eindgebruikers zouden doen ... Of, in hun hand op een mobiel apparaat.

Het is belangrijk om perspectief te houden en je ontwerpen in realiteit te aarden.

Update: 2019. Ik heb een boek geschreven over systeemontwerp en digitale merkrichtlijnen! https://designsystemfoundations.com