“Her er de gale, feilmonterte, opprørerne, bråkmakerne, de runde knaggene i de firkantede hullene ... de som ser ting annerledes - de er ikke glad i regler ... Du kan sitere dem, være uenig med dem, herliggjøre eller ødelegge dem, men det eneste du ikke kan gjøre er å ignorere dem fordi de endrer ting ... ” - Apple’s Tenk annerledes kampanje, Steve Jobs, 1997.
Mesteparten av tiden lager designere fremdeles statiske mock-ups av skjermer ved hjelp av tradisjonelle designverktøy under webdesignprosessen. Men noen designere tar et stort sprang og omgår dem, går rett til kode, bygge og justere design i nettleseren, og teste designene deres slik de ser ut for folk i sanntid. Er de gale, feilmonterte, opprørere?
Vanligvis involverer den tradisjonelle nettstedsutviklingsprosessen mange faser, inkludert planlegging, innholdsstrategi, design, wireframing, prototyping, testing, utvikling, publisering og så videre. Men i løpet av designfasen, kan det være en annen måte å produsere 'piksel-perfekte' responsive nettstedsdesign og helt utenom designverktøy?
Med fremveksten av responsiv utforming og mangfoldet av enheter som er i bruk (mobiltelefoner, nettbrett, bærbare datamaskiner, stasjonære datamaskiner, klokker), er det mye vanskeligere å holde alt konsistent - og med flere bevegelige deler å ta i betraktning, endres tilnærmingen til å designe nettsteder og grensesnitt.
Selv om det ikke er nødvendig for en designer å bli en ekspertkoder, er en løsning at designere begynner å jobbe direkte med koden som driver et nettsted. Designere som kan krangle koden med bare litt HTML og CSS vil finne seg selv en stor ressurs for ethvert team og har en enorm fordel generelt.
Hvorfor? Når du engasjerer et responsivt webdesignprosjekt med alle dets kompleksiteter, designere har vanligvis ikke tid til å lage en statisk design av en komponent (la oss si en topptekst eller bunntekst) på tvers av 10 forskjellige oppløsninger og visningsfelt. Selv om de bare designer de mest populære enhetene, må de likevel vurdere 4-5 skjermer med forskjellige sideforhold, skjermtetthet og skjermdimensjoner. Ingen liten oppgave mildt sagt.
La oss utforske en annen tilnærming og planleggingsprosess for nettsteddesign.
Den første fasen begynner med et klientspørreskjema som spør om de generelle prosjektmålene fra et forretningsperspektiv, målgruppen, konverteringsstrategier, forskjellige ytelsesforventninger , og så videre. Dette gjøres før den faktiske designfasen lanseres for bedre å forstå kundens behov og prosjektet generelt og for å være mer effektiv nedover linjen.
Det neste trinnet er å skrive en oversikt over prosjektet for å bekrefte at den ble forstått. Dette er nyttig når du arbeider med prosjekter i en nisje der du kanskje ikke har mye erfaring eller kompetanse. Kall det en funksjonell spesifikasjon - men mindre teknisk.
Dette hjelper med å definere terminologier, nøkkelord og prosesser. Avhengig av prosjektets kompleksitet, er det en god ide å gjøre flere scenarier og brukerflyter - vanligvis ombordflyt, søke og navigere på et nettsted, eller et 'legg i handlekurv' og utsjekkingsflyt hvis det er et e-handelsnettsted.
Prototyping er neste fase i nettstedsdesignprosessen. Bygg raskt wireframes å snakke om sideoppsettet, funksjonalitetene og hvordan nettstedssidene vil se ut på forskjellige enheter er en god start. Det tar ikke mye tid å lage dusinvis av trådrammer av forskjellige maler og komponenter. En enkel nettsideprototype kan opprettes fra disse, og avhengig av kompleksiteten i prosjektet, kan prototypeverktøy som InVision , Adobe XD , Balsamiq , Moqups , eller Axure kan bli brukt.
Neste trinn er å sette sammen en Humørbrett : en samling ting designeren, klienten og andre interessenter kan like på andre nettsteder - oppsett, utseende, farger eller skrifttyper, ikoner, bilder og så videre. Dette vil bidra til å definere nettstedets generelle utseende. Hvis klienten har en guide for merkevarestil, bør den vurderes og innlemmes i det nye nettstedsdesignet.
Når forskjellige gjenstander er godkjent - trådrammer, prototyper, mockups, humørbrett osv. - er det lurt å gjøre en grensesnitt inventar .
Et grensesnitt inventar er en omfattende samling av biter og deler som utgjør grensesnittet ditt.
Brad Frost
Hvis du gjør responsivt webdesign fra bunnen av, begynner du med å skrive ned alle komponentene og elementene som prosjektet skal bygges fra. En uordnet liste vil gjøre det bra og er definitivt bedre enn ingenting. For eksempel tabeller, knapper, bilder, typografi, media, skjemaer, navigering, komponenter osv.
“Design i nettleseren” er et begrep som ble populært med økningen av responsiv webdesign. For å minimere timene som brukes i designprogrammer som Skisse ble designere oppfordret til å flytte designfasen til nettleseren, og bruke CSS for layout og styling. Denne tilnærmingen til nettstedsdesign viser seg å være mer effektiv da den kutter ut mange trinn.
Ved å fokusere på HTML-mockup, og teste designideer 'i nettleseren' med CSS, kan tiden som brukes til å lage statiske mockups av sider i andre designverktøy som Sketch, lagres. Det er en god ide for designere for å få tak i en god kodeditor og komme med en god oppdateringsmetode for nettleseren, slik at de kan se endringer i sanntid. Sublim tekst og Codekit , for eksempel, er en flott kombinasjon.
HTML og CSS , strukturert som de er, tvinger deg til å tenke på mønstre og holde deg i sjakk. Det er lettere å tenke på modularitet når du bygger HTML-komponenter som enkelt kan kopieres, dupliseres og fylles ut med dynamiske data og samtidig ha samme struktur. Hvis du vil lage en spesifikk modifikasjon, må du eksplisitt målrette mot det elementet, eller legge til en annen CSS-klasse.
Når du utformer overskrifter, med mindre de overstyres, vil de være konsistente på hele nettstedet. Det samme gjelder andre elementer. Denne typen tanker tvinger deg til å standardisere, gruppere vanlige elementer sammen, gjenbruke allerede utformede elementer så mye som mulig, og viktigst av alt, holde alt modulært.
Med en enkelt CSS-erklæring kan du endre polstring på knappene for bedre berøringsmål, og teste direkte på en mobiltelefon , tablett og desktop. Dette gjøres ikke lett i Photoshop eller Sketch fordi andre elementer ikke er klar over hverandre i layout, og du må omorganisere objekter hver gang du endrer størrelsen på noe.
Vil du prøve et annet topptekstfargeskjema? Ved å jobbe med bare noen få linjer med CSS-kode, er endringer synlige på alle HTML-maler umiddelbart, på alle enheter og skjermer. Den slags fleksibilitet kan ikke lett etterlignes når du har 20 statiske modeller. Riktignok kan du bruke 'symboler' i Sketch eller Adobe XD for gjenbrukbare komponenter, men de er ikke like allsidige som CSS.
I denne fasen må det tas flere tekniske beslutninger. Spørsmål som må besvares er:
Å velge skrifttyper for et responsivt webdesignprosjekt kan være utfordrende. Det er mange muligheter og like mange fallgruver. Siden designet skal brukes i nettleseren, er dette det beste stedet å prøve dem ut. Fontlesbarhet kan variere basert på størrelse, vekt, farger og gjengivelse, så ved å prøve ut skrifter direkte i nettleseren, designere kan sørge for at ting ser riktig ut, og at de ønskede forventningene blir oppfylt.
Det er mange online verktøy for å velge og teste skrifttyper og prøve ut skrifttypekombinasjoner. På Typetester og Typecast forskjellige skrifttyper fra forskjellige tjenester og støperier kan bli funnet og testet. Når du arbeider med en bestemt font-abonnementstjeneste som Nitrogen eller Fonts.com , designere kan generere skrifter og teste på sidemalene sine direkte. Å generere en Typekit-pakke med nye skrifter er enkelt og raskt, og du kan enkelt se hvordan bestemte skrifter vil påvirke ytelsen til nettsider.
Hvis tegning tilpasset ikoner , størrelse, rutenett og stil må defineres. Jobber i Illustrator , hvert tegnebrett vil for eksempel representere ett ikon. Ikoner kan enkelt eksporteres fra Illustrator som SVG eller PNG, som senere kan gjøres om til en ikonfont med tjenester som Icomoon . Det anbefales å bruke vektorikoner (SVG) fordi vektorer er oppløsningsuavhengige, så det er ingen bekymringer for hvordan de vises på HD-skjermer.
Selv om vi designer i nettleseren, med dusinvis av maler og komponenter, kan vi potensielt miste oversikten over hvor noe brukes, og på hvilken måte. Det er en god idé å bygge en stilguide av alle komponentene som et sentralt depot. Spesifikke sidemaler vil bli bygget fra denne stilveiledningen ved å kombinere UI-komponenter og elementer i websider.
UI-komponenter kan være ting som paginering, produktoppføring, bildegalleri, modale vinduer, skjemaelementer, etc., og brukes som byggesteiner for maler. Å holde alt på ett sted er veldig nyttig når det er på tide å teste en bestemt brukergrensesnittkomponent.
Med CSS er det en god praksis å skille komponentstiler i separate filer. For eksempel vil sidestyling være i _pagination.scss
, skjemaelementer i _form.scss
, og alle disse filene vil bli inkludert i en enkelt SCSS-fil med andre filer (variabler, mixin osv.).
Selv om style.scss
kan være sammensatt av dusinvis av 'små filer' når det er flere som jobber med det samme prosjektet, er det lettere å holde rede på endringer (enten ved hjelp av kildekontroll eller ikke) hvis alt er delt inn i mindre biter. Det er viktig å fortsette å opprettholde stilguiden etter at prosjekteringen av nettstedsdesign er i produksjon, ettersom teamet må holde oversikt over alle nettstedskomponenter.
Fra et utviklingssynspunkt er det mange tilnærminger til å skrive modulær CSS. Mest kjent er SMACSS (Skalerbar og modulær arkitektur for CSS), GOD (Block, Element, Modifier) og OOCSS (Objektorientert CSS). Det er ganske mye å lære, selv om du ender opp med å utvikle din egen tilnærming. På dette tidspunktet bør du ha en fin samling av brukergrensesnittkomponenter og websider, som gjør det enkelt å bygge nye websider. Du kan kopiere og lime inn elementer fra stilguiden, og omorganisere dem etter behov.
Siden alt er modulært, trenger du ikke å bekymre deg for design og kodekonsistens; men ikke glem at hvis du justerer en UI-komponent hele systemet, må du oppdatere stilguiden med endringene (eller legge til den nye komponenten). For å holde alt organisert, er det best å bruke en slags mal- / automatiseringsmetode for å jobbe på websider som Gulp eller Grunt .
Nå har du et sentralt arkiv med UI-komponenter, hvert dokument dokumentert og nettsider bygget fra disse komponentene. Fra dette tidspunktet er det mer enn sannsynlig det designere trenger ikke lenger å åpne favorittdesignverktøyene sine, da det meste av 'designet' gjøres direkte i koden og forhåndsvises i nettleseren.
Ikke helt sikker på hvordan en spesifikk endring vil påvirke designet? Nå kan du forhåndsvise designet ditt på forskjellige enheter og nettlesere samtidig for å se hvordan en skrift endres på en overskrift, eller å endre størrelse og farge på en knapp vil påvirke designet.
Når påvirker sidelastingsytelsen når du bruker egendefinerte webskrifter, hvordan vil flere skriftvekter påvirke sidelastingsytelsen? Vi kan teste ytelsen til pågående nettside ved hjelp av tjenester som WebPageTest , og ta informerte beslutninger om faktiske resultater. Vi kan definitivt ikke gjøre det i Photoshop eller Sketch.
Arbeid med HTML og CSS og arbeid i nettleseren er kanskje ikke for alle designere under en nettstedsdesignprosess. Men hvis designere virkelig bryr seg om hvordan arbeidet deres ser ut på forskjellige enheter og skjermstørrelser, må de sørge for at det er perfekt hver gang. Noe som ser fantastisk ut som en statisk designmodell, kan se mindre enn ønskelig ut når den vises i en nettleser på en mobil enhet. Det ville være kunnskapsrike designere å bygge og teste webdesign i et miljø der alle vil se dem ... i nettleseren.
• • •1. Velg et webhotell 2. Registrer et domenenavn 3. Planlegg nettstedet (type, navigering, innhold) 4. Design og bygg nettstedet 5. Publiser nettsted 6. Promoter nettsted 7. Vedlikehold nettsted.
Generelt, ettersom det avhenger av omfanget, kan et typisk nettsted (50-100 sider) ta omtrent 14 uker (oppdagelse 3 uker, design 6 uker, dev 5 uker). Et enkelt 10-15 sider, tilpasset designsted vil ta omtrent 4-6 uker.
Før du går inn i designfasen: 1. vurdere og undersøke (f.eks. Målgruppe, kreativ retning, mål, budsjett, tidslinje). 2. Innhold driver design så brainstorm. 3. Bekreft tekniske krav. 4. Utvikle en oversikt. 5. Lag wireframes for å bestemme plassering av elementer.
Oppdagelse: 1. Forskning (f.eks. Målgruppe, kreativ retning, mål, budsjett, tidslinje). 2. Brainstorm. 3. Bekreft tekniske krav. 4. Utvikle en oversikt. Design: 1. Lag wireframes for å bestemme layout 2. Utvikle visuelle behandlinger (f.eks. Humørbrett, Photoshop mockups, HTML) 3. Kreative anmeldelser med interessenter.
En god nettstedstruktur tilsvarer bedre UX. En konvensjonell nettstedstruktur er avgjørende for SEO og brukervennlighet. Vanligvis formet som en pyramide, bør den ha tydelig navigering og huske brukeren: 1. Hjemmeside 2. Seksjoner 3. Underkategorier 4. Individuelle sider og innlegg.
1. Velg en layouttype med tanke på rekkevidden av enheter som brukes til å vise nettstedet 2. Definer strukturen ved hjelp av et områdekart 3. Identifiser navigasjonsflyt 4. Lag wireframes for å identifisere hierarki.