Design i browseren bruges til at skræmme mig. Ikke fordi det syntes svært, men fordi jeg troede, at jeg ville ende med et design lavet af mange små kasser, ville noget, der var så generisk og intetsigende, ende med at omdanne det i Photoshop.

Den frygt viste sig at være fuldstændig uberettiget. Ikke kun blev mine designs mere fokuserede, jeg gennemførte dem også hurtigere og fik involveret klienter tidligere i processen gennem interaktion og diskussion.

Det er ikke så hårdt som du tror

Design er design. Det er ligegyldigt, om det gøres i et softwareprogram eller skrives i kode. Design i browseren er ikke noget sværere end at designe i Photoshop. Ligesom ethvert værktøj skal du bruge det til at lære det og til sidst mestre det.

Design er en iterativ proces, en der gøres vanskeligere ved at arbejde for klienter. Det er svært, nogle gange for kunderne at se præcis, hvad du beskriver; design i browseren kan få dem involveret i hele processen i stedet for bare designfasen.

I det væsentlige fusionerer design- og udviklingsfaserne, og hvis du er naturligt god til design og front-end-udvikling, vil du tage til at designe i browseren som en ande tager til vand.

En stor fordel ved at designe i browseren er, at vi kan designe ud fra realistiske forventninger. Nogle gange kan design i software skabe uforudsete problemer for udvikling af fronten. UI-elementer kunne være designet wonky eller måske har de bare ingen mening, det er svært at forklare for en klient, hvorfor du har ændret noget, ikke fordi de ikke forstår, men fordi du allerede har lagt det i designet og havde det godkendt. Design i browseren henvender sig til ideen om enkelhed.

Har en plan

Før jeg tænker på design, skal jeg have en plan. Bare fordi jeg bruger et andet værktøj betyder det ikke, at min proces ændres. Jeg har lyst til at have en smuk solid plan, før jeg begynder at designe, og jeg har brug for at vide, hvad jeg designer, hvorfor jeg designer, hvem jeg designer for, klient baggrund og enhver service eller produktinformation, som jeg bliver nødt til at fokusere på på.

Når jeg har bestemt disse ting, vil jeg få en bedre ide om, hvad produktet er, eller hvad klienten gør, hvor længe har de gjort det, hvad sætter dem adskilt fra deres konkurrence, hvem deres bruger base er, og hvad den primære og sekundære Målene for hjemmesiden skal være.

Jeg personligt gerne have dokumentation for alt. Normalt har jeg dokumentation for sitemap, indhold, opkald til handling og sitearkitektur. Når jeg begynder at designe, skal jeg have en klar strategi for designet, og alt indhold skal have været samlet.

Skitse først

Skitsering er nøglen, hvis jeg skal designe alt i browseren. Jeg kan rive ud indholdsområder med blyant og papir, få feedback og hurtigt iterere ind i grundlaget for mit design.

Jeg skitserer ud fra den plan jeg har beskrevet ovenfor, og jeg sørger for, at jeg har alle indholdsområder og opfordringer til handling udlagt. Skitsering skal være hurtig, ikke bruge meget tid på at perfektere noget. Det skal være solidt nok til at vise til en klient men sjusket nok, at du kan få dem færdige på mindre end en time.

Næste kan jeg prototype siden fra mine skitser i HTML og CSS. Prototypen er en masse grå bokse med tekst og billeder til pladsholdere. De grå bokse fungerer som containere til indhold, når jeg faktisk begynder at designe. Den største fordel ved prototyper med kode er, at klienten kan interagere med prototypen og se, hvordan sitearkitekturen fungerer, på den måde, hvis noget er slukket eller har brug for raffineret, kan vi klare det nu snarere end på startdagen.

Style fliser

Før vi kan begynde at designe, har vi brug for en slags stil at basere vores design ud af. Vi skal bestemme de farver og skrifttyper, vi vil anvende med potentielle teksturer og mønstre. Her kommer stilfliser til spil.

Style fliser blev oprettet af Samantha Warren, og jeg har brugt dem et stykke tid nu. De hjælper kunderne med at se en tidlig og meget enkel stil guide, som vi kan bruge til at begynde at designe med. Jeg kan godt lide at oprette flere af disse for at se, hvilken klient foretrækker den måde, at jeg kan indsnævre den til en. Jeg finder ud af, at disse også er meget vigtige i godkendelsesprocessen og hjælper med at forhindre fuldstændig afvisning.

Design

Nu er vi klar til at begynde at designe. Hvis du er vant til at designe i et softwareprogram som Photoshop eller Sketch dette er ikke meget anderledes. Ved hjælp af vores prototypefil begynder vi at tilføje mock indhold i vores markup. På dette tidspunkt ved vi præcis, hvad der går ind i hvert indholdsafsnit i markeringen, og nettet er allerede defineret, så det skal ikke tage så lang tid.

Nu skal jeg begynde layering stilarter på mit indhold. Jeg skal tilføje basisformater til farve, typografi og layout. Når basisformaterne er færdige, vil jeg træde væk og se på den. Jeg kan godt lide at skærmbilleder bestemte dele af designet til senere henvisning.

Refinement

Når jeg er tilfreds med basislaget, kan jeg godt lide at tage noter om, hvad man skal forfine. Baseret på disse noter vil jeg højst sandsynligt bruge Photoshop eller Skitse at tilføje tekstur eller noget med en håndgribelig følelse. Photoshop og Sketch er gode værktøjer til at forfine komplekse UI-elementer hurtigt, så jeg redder alt, hvad der kan være en smerte at kode ud mere end én gang

Grunden til, at jeg gør dette er, fordi jeg vil have min kodebase til at være magert og rent og jo mere du kode, kommentere og slette, jo mere slurvet og oppustet bliver din kodebase.

Gem og genbrug almindelige mønstre

Hvis du skulle udforme i browseren fra bunden hver gang, kan det virke som om de tager for evigt, men hvis du starter fra en brugerdefineret base, en ramme, kan du eliminere gentagne trin. Til at begynde med har jeg en brugerdefineret version af Initializr som jeg bruger med et brugerdefineret reagerende net bygget i Sass (http://sass-lang.com/). Brug af en brugerdefineret ramme giver mig en start for prototyping og design.

At have et bibliotek med almindelige brugergrænseflader er også en god måde at opbygge en hurtig prototype på, og det gør det mere effektivt at designe i browseren. Jeg bruger Sublim tekst at kode og en ting, som jeg har lært at drage fordel af, er de brugerdefinerede uddrag, du kan oprette. Jeg har tilføjet flere variationer af navigation, lister, sidebjælker og andre fælles elementer til min liste over uddrag, så jeg kan hurtigt placere dem i min markering med en simpel handling. Jeg bruger også konti på Codepen og JSFiddle at gemme mønstre. Dan Cederholm lavede et godt WordPress tema til opbevaring af almindelige mønstre, der hedder pærer . Det bruger indlæg til at gemme kode, som du kan redigere live i front-end for at teste og forhåndsvise ændringer.

Konklusion

Øvelse og praktisk anvendelse gør dig bedre til at designe i browseren. Chancerne er, hvis du gør nogen form for front-end-udvikling, har du allerede en basisramme til at starte fra, og du har allerede nogle fælles mønstre at bruge.

Nu er alt hvad du behøver at lave, begynder at designe i browseren og i sidste ende kommer du op på en arbejdsgang, der er effektiv og fungerer inden for din proces. Med praksis får du kun hurtigere.