Kjære designere,

Dette har vært i gang i årevis. Deler har blitt levert i innlegg og noen skriftlig til forskjellige designere over lang tid.

Imidlertid har jeg alltid vært redd for å publisere den av frykt for at det vil påvirke designeren eller klienten jeg jobber med for øyeblikket. Så før jeg går, vil jeg understreke at dette ikke er en spesifikk klage, men en detaljert liste over 18 års uenighet.

Vi har jobbet sammen i nesten to tiår, og hver PSD-fil du har sendt meg har hatt (mer eller mindre) de samme problemene. Tilgi meg da for uanstendighet med å prøve å lære deg hvordan du gjør jobben din.

Jeg tør ikke lære deg om grafikk eller estetikk. Jeg skal ikke fordype meg i typografi, lesbarhet eller bruk av hvite rom.

I stedet vil jeg forklare hvordan fruktene av arbeidet ditt informerer meg.

Jeg vil minne deg om hva som skal til for å reprodusere piksel-perfekte design på en webside. Jeg vil gjerne fortelle deg hvordan filoppsettet ditt vil bli brukt til dokumentasjon og hvordan bildene du lager, vil bestemme teknologiene som brukes - helt ned til grunnlaget for skalerbarhet og ytelsesnivå.

Jeg vil også demonstrere hva som kan gjøres raskt og enkelt, og hva som vil generere overhead som vil gjennomføre hele produksjonen.

Og fremfor alt vil jeg minne deg på det design som du skaper nå, vil bli en levende ting som samhandler og reagerer, som kommuniserer med tusenvis av forskjellige mennesker, som du trenger å lære og lære av dem på en enklest mulig måte. Både for dette og for dem.

Design for dokumentasjon

Først og fremst vil jeg minne deg på det PSD-filer som du produserer er ikke bare kilden til bildene som kunden skal godkjenne, men også Teknisk dokumentasjon Y kildematerialer for utviklere. Så hold lagene og gruppene dine bestilt, organisert og navngitt .

Kjære designere, i to tiår har du sendt PSD-er med de samme problemene. kvitring

Utvikle designet ditt. Lag en egen fil med konvensjonene du har brukt, eller noter dem i et skjult lag.

Fortell meg hvilke skrifttyper du har brukt til hva. Gi meg beskjed om hvilke farger, avstander og sammenhenger du brukte. Jeg trenger å vite det.

Også, jeg trenger å vite om ekstrapolatet har gjort utformingen av en bestemt funksjon eller ikke.

Det jeg prøver å si er: hvis det i det hele tatt er mulig lage en liten stilguide for produktet du designer.

For vår skyld, når du legger til standard tekstblokker - som titler - legger du til et rektangel bak dem for å indikere rommet rundt dem, som skal tillate deg å plassere dem konsekvent hver gang. Hvis dette er for mye arbeid, angi i det minste hvilket eksempel i dokumentet som er kanon.

Jeg kan ikke fortelle deg hvor ofte jeg finner titler som skal plasseres med øye, så visuell plassering av dem fungerer ikke, men når de måles, avslører de at hver har sitt eget rom.

Det samme gjelder innholdsblokker. Hvis du har en liste over de forskjellige innholdsblokkene, må du plassere den konsekvent.

Jeg vil fortelle deg mer i delen av designe for innhold_, men ikke anta at titlene dine alltid vil være på en enkelt linje, og bruk denne informasjonen i filen.

Jeg kommer stadig over disse titlene med skriftstørrelse på 22 pixel og linjehøyde på 92 px (åpenbart kopiert og limt inn fra hovedsides tittel). Innstillingen du velger er relevant, selv om den ikke endrer den eksporterte filen visuelt.

Designe teknologien

Det er to sider ved dette: Hva kan bli gjort Y hva som er passende for midten.

Mens vi raskt når et punkt der alt vil være teknisk mulig for nettstedsutvikling (jeg kan fremdeles tegne piksel for piksel enn å bruke lerret), en rekke av disse løsningene Nei de er klare til produksjon.

Det faktum at du finner et eksempel der noen lykkes kombinert WebGL 3D med filtermaske CSS uskarphet pluss for en demoside betyr det ikke at du kan bruke vinduet på en enkelt side som et komplett parallakspanel.

Og hvis du virkelig vil gå i forkant, ta kontakt med utvikleren din før sende design til godkjenning. Ellers vil det være vanskelig for kunden å gjøre opp.

Hvis du virkelig vil prøve kantingen og vil gjøre det for moro skyld, kan du kontakte meg privat. Jeg elsker å lage denne typen ting akkurat som deg. Bare ikke legg disse tingene i et budsjettert produksjonsprosjekt.

Utover disse tingene - utover å teste grensene for hva som kan gjøres, prøv å være følsom og fornuftig hva skal gjøres .

Du er ikke grafiker; du er mer enn det, du er en designer.

Ikke bare designer du for å se på en bestemt måte, du må også designe det slik at løpe , kommunisere Y oppføre seg på en bestemt måte .

Å gå for den klisjeen som designere er kjent overalt: Hvor god er en stol hvis ingen kan sitte i den?

Du må innlemme lastehastighet og kjørehastighet og brukervennlighet i designet ditt for å gjøre det til design i stedet for et bilde.

Prøv å få så mye som mulig med bare HTML og CSS.

Prøv å få så mye som mulig med bare HTML og CSS. Unngå å bruke fine funksjoner som er tilgjengelige i Photoshop. Ikke bruk blandingen! Ikke bruk Dristig faux Y Kursiv faux .

Med mindre elementets intensjon er et bilde, må du ikke bruke filtre i det minste - bortsett fra de enkleste skyggene.

Ikke få meg til å beregne eller velge farger fordi du har blandede fargefyll. Vennligst ikke bruk falske gjennomsiktige bilder ved å blande overlegg, jeg trenger virkelig gjennomsiktig bilde på nettstedet.

Hvis vi bruker en front-end, for eksempel et rammeverk ( Støvelhempe , mange av disse spørsmålene vil allerede ha blitt løst, for å lære hvordan det gjøres og hvordan det kan endres. Ikke gå med å designe noe som ikke er relatert.

Hvis designet ditt ikke er i tråd med det rammeverket gjør, implementerer applikasjonen ikke designet. I stedet vil vi ende opp med å selektivt overstyre rammeverket, slik at det ikke kommer i veien for designet vårt og deretter implementerer det fra bunnen av. Arbeidsbelastningen dobles i stedet for halvert.

Og til slutt, ikke bruk mer enn tre skrifter - eller skriftvarianter - på nettstedet. Hvis du trenger seks forskjellige vekter, hver med sine egne glidebrytere og kursive varianter, designer du ikke lenger for nettet.

Design for interaktivitet

Dette er enormt. Og det brevet ble opprinnelig skrevet eksklusivt for dette emnet. Du må virkelig vite og forstå alle måtene brukere og funksjonalitet kan samhandle på.

La oss starte med de enkleste tingene: lenker.

Koblinger har ikke bare to stater.

I navigasjonen jeg mottar, tilbys alltid design for en kobling Y for en aktiv lenke (faktisk side).

I andre tilfeller oppgir du vanligvis utgangspunkt og _over sier.

Hvis du vil være den mest brukervennlige, må du ha forskjellige oppsett for _ statene til base, sveve Y fokuset ( besøkt Y aktiv de er også fine å ha for UX). Og for navigasjonen har en lenke og en aktiv lenke hver alle tidligere stater .

Å, og ikke tør du endre et koblingsoppsett mellom stater (varierende kantbredde, polstring og lignende).

Tilsvarende, hvis det ikke ser ut som en knapp, er det ubegrunnet. Punkt. Det er vanskelig å legge inn et innebygd tekstelement, og uinnrammede tekstbakgrunner vil aldri fungere.

Siden vi skal bruke dette på mobil, må du sørge for at det er nok hvitt mellomrom mellom de forskjellige interaktive elementene, og at hver hitbox være stor nok. Jeg tror minimum 42 pixler på hver akse er normen.

Tegn et usynlig rektangel, eller et skjult lag som vises hitbokser ; Forsikre deg om at de ikke overlapper hverandre, og at brukerinteraksjoner er entydige.

Formelementer er enda verre.

Det vanligste tilfellet jeg ser er med radioknapper og avmerkingsbokser. Standardene er stygge! Så design ditt eget og gi meg en markert og umerket status, og vurder ditt ferdige arbeid.

Imidlertid er det en hel flerdimensjonal tabell over tilstander ved en avkrysningsrute, og hver og en må være visuelt angitt for brukeren.

Vi har følgende tilstander:

• Revidert eller ikke
• Hold inne nei
• Fokal eller ikke
• Aktivert eller ikke
• Feil eller ikke

Hver av disse kan kombineres med de andre.

Deaktivert forhindrer noen kombinasjoner (svever og fokal er vanligvis irrelevante når de er deaktivert), men ikke alle (merket og deaktivert er helt gyldig og en informasjonsstatus for en avkrysningsrute). Så vi ender med 16 på og fire av stater, og gir totalt minst 20 forskjellige stater. For eksempel er statusene du vanligvis gir meg bekreftet-nei-nei-ikke-aktivert og deaktivert-nei-nei-ikke-aktivert i denne innstillingen.

Andre skjemaelementer har kanskje ikke ukontrollert revidert status, men kan være tomme eller ikke-tomme (viser plassholdertekst). De kan også ha en mer kompleks informasjonsstatus slik at feilen eller ikke kan være like kompleks som den nøytrale feilvarslingssuksessen.

Så på toppen av det, bør det være obligatorisk eller valgfritt sammen med tydelig definerte indikatorer og etikettoppsett og design, pluss inndatahjelp og feiltekst.

Og hvis du virkelig vil være brukervennlig, trenger du et skittent sett med uberørte statuser, noe som indikerer at brukeren aldri har gitt dataene eller dataene som allerede er lagret, eller er endret, men ikke lagret, ennå.

Det er vanskelig å designe for interaktivitet. Og hvis du vil endre utseendet til radioknappene, ikke gjør det så lett med to tilstander.

Det jeg sier er: å designe for interaktivitet er vanskelig. Og hvis du vil endre utseendet til radioknappene, ikke gå lett med to tilstander.

Bare et siste punkt om interaktivitetsdesign: bestem hvordan interaksjonen skal se ut. Jeg mener du bestemmer hvilke instrumenter som skal brukes til interaktive elementer, og ikke bruker dem til noe annet.

Nei! Du har ikke lov til å bruke hovedfargemerket ditt for å indikere lenker, spesielt hvis du bruker den samme løsningen for å fremheve viktig innhold!

Design for innhold

Innholdet i hvert ideelle designelement fullt av leppesum det er bra nok til å presentere klienten for et bilde for å få godkjenning for den visuelle stilen. Men innholdsdesign starter eller slutter ikke der.

Når du har en grov ide om hva du vil gjøre med innholdsdesignet ditt, husk at du jobber med dynamisk innhold.

Når du har en grov ide om hva du vil gjøre med innholdsdesignet ditt, husk at du jobber med dynamisk innhold. Det er to tilfeller, du bør se etter hvert innhold:

• Hva om det er for mye av det?
• Hva om det er for lite (eller mangler helt)?

Sjekk hva som skjer hvis tittelen er latterlig kort eller uvanlig lang. Hvordan skal innholdsblokken se ut hvis kritiske elementer mangler? Hva om det ikke er noe bilde?

Hvis det ikke er noe innhold for delen av en side, kan vi ikke slette hele seksjonen - tittel, innhold og alt - eller vi bør beholde delen og se noe sånt som: 'Ingen artikler ennå, prøv igjen senere?' Enda bedre: “Vil du bli varslet når dette innholdet kommer? Abonner på vårt nyhetsbrev!'

Ta avgjørelsene! Deretter Design de tingene!

Hvis du designer en feed eller innhold lastet fra en ekstern eller dynamisk kilde, ikke glem å ta med alle feil og varsler. Faktisk designer du meta-innholdsvarslingssiden for å vise hvordan den ser ut for alle, og følger deretter designkonvensjonene for å varsle brukeren i tilfelle noe går galt.

Unngå knapper med fast bredde og fast høyde på tekstblokker. Og hvis du ikke har sagt det før, hvis du tror det alltid kommer til å være en tekstlinje, tar du feil! Nå, sjekk ut den beste måten å gjøre flerlinje .

Forsikre deg om at det samme innholdet har samme struktur.

Hvis den samme tittelen er synlig flere steder, må du ikke understreke et dristig ord i ett tilfelle og et annet sted!

Faktisk prøver den å unngå strukturer i titler i fullformat. Ikke bryt tekst manuelt på ett sted, men bryt det annerledes på et annet sted. Ikke bryt teksten manuelt!

Disse tingene kan forbedre designet ditt, men husk at innholdet sannsynligvis blir løst med et CMS, og at personen som har ansvaret for å dokumentere det kanskje ikke ser hvordan det ser ut før det blir publisert, eller at de ikke engang har verktøyene til å manuelt bryte den, eller gi format til tekst.

Design den med de samme begrensningene som det endelige innholdet vil ha - tekstbrettene med fast bredde og automatiske ordpakning . Hvis det ser stygt ut slik, er designet ikke bra.

Design for responsivitet

Dette har kommet langt den siste tiden. I det minste i tilfeller der det virkelig er designet for å mobiliseres. Mer og mer har vi latt Bootstrap finne ut av det.

Imidlertid er det alltid noen få enkle prinsipper du bør vite.

Først og fremst er mobil- og stasjonære varianter ikke separate sider. Jeg vet du vet. De er ganske enkelt refleksjoner på samme side.

Det er akkurat det samme som å jobbe med venstrejustert tekst. Setningen endrer ikke rekkefølgen på ordene eller bokstavene bare fordi du har plassert en liten container.

Også innholdsgrupper må deles på tvers av alle oppsett. Når du legger til kolonner, må du sørge for at kolonneskiftene er konsistente.

Konvensjonene dine bør også følge samme struktur for forskjellige versjoner av siden.

Noe som betyr at hvis det er to identiske gjenstander på et skrivebord, må de også være identiske på mobil.

Å, og hvis du vil ha parallaks, gi subtilt et bilde som er stort nok til å bevege seg. Hvis du passer eller beskjærer bildet slik at det er riktig på filen som klienten viser, har jeg ingenting å flytte på.

Design unntak

Selvfølgelig er unntak alltid mulig. I tillegg er de nødvendige for at produktet skal være attraktivt og effektivt. Ikke legg dem til i den første boksen for boksen.

Hvis du finner ut at du løser det samme designproblemet om og om igjen, og dette ikke fungerer, spesielt hvis du går etter en annen løsning hver gang.

Når du har gjort alt ovenfor, bør du oppnå et effektivt, stabilt og konsistent (om noe kjedelig) design. Nå er det på tide å livne opp litt på ting. Når du ser på en hel side, snakk med klienten for å identifisere pengeskudd - varene som gir dem mest penger for pengene.

Vi har vært jobber sammen i mange år, og kundene våre har alltid vært fornøyde med sluttresultatet.

Selvfølgelig kommer jeg til å freak out hvis du savner noen av disse punktene, og når det er berettiget å bruke et komplekst layout, vil jeg fortsette å skrive om gjengivelse av logikk i JavaScript om nødvendig.

Jeg vil gå inn og begrunne det ekstra arbeidet for klienten om nødvendig. Jeg har designet former og interaktivitet på toppen av mottatte oppsett i evigheter, så dette vil ikke være et problem.

Jeg håper bare, etter å ha lest dette, kan du huske noen av disse forslagene neste gang vi samarbeider. Jeg håper de påvirker arbeidet ditt og gir veiledning når du ikke vet hva du skal gjøre. Jeg vil at du skal forstå at forholdet vårt betyr noe for meg, og at jeg ikke har skrevet dette for å skade deg, men for å gjøre forholdet vårt bedre.

Med kjærlighet,

Din front-end utvikler