Westworld, HBO

Design som en udvikler

Længere titel: Design i sketch, som om du bygger brugergrænseflade i et udviklingsmiljø

Først og fremmest er dette den eneste gang, Photoshop vil blive nævnt i denne artikel. Det er 2017 - gør dig selv en tjeneste og download Sketch (eller Figma - Jeg er ligeglad, så længe det ikke er Photoshop).

UI-design er nået langt, og det samme har billedmanipulationsprogrammer (hvis du endda kan kalde dem det i dag). Vi kan huske, at vi oprettede vores første UI'er i GIMP, og nu, hvor vi har fået MacBooks, bruger vi Sketch til næsten alt UI-relateret.

Her er dog ting; Sketch er blevet oprettet med designere i tankerne. Det er bygget med det formål at hjælpe designere med at oprette brugergrænseflader - og du kan oprette temmelig fantastiske ting med det. Men glem ikke, at når du bygger et produkt, slutter din pligt, når dit design sendes, ikke når du "færdiggør" den Sketch-fil.

Dit design skal gennem en udvikler og bygges i et udviklingsmiljø. Det er her problemet ligger; Hvis du ser på Sketch og en UI-builder i et udviklingsmiljø (eller IDE'er, f.eks. Xcode og Android Studio) side om side, vil du ikke se mange ligheder.

Den måde, en udvikler bygger dit design på, er grundlæggende forskellig fra den måde, du som designer opretter det i Sketch. Det lyder lidt dumt, når du sætter det i perspektiv, er det ikke?

Xcode, Sketch og Android Studio (og nogle lynbolte)

Det er dog okay! Denne artikel skal beskrive en designtilgang, som kommer lidt tættere på, hvad en udvikler gennemgår, når de bygger dit design (det er en kamp ...).

Tænk i "Visninger"

Du kender symboler i skitse, ikke? Vi var virkelig glade for at bruge denne funktion, da vi skiftede til Sketch, fordi det kommer så tæt på, hvordan udviklere bygger UI'er. Det meste af tiden, når du ser ting som listeelementer eller handlingslinjer, har de en enkelt kildevisning, der genbruges igen og igen.

Den vigtigste retningslinje for at designe som en udvikler er at tænke på dit design med hensyn til Views. Tænk på en visning som en uafhængig gruppe af elementer, der har definerede grænser og er sorteret i hierarkisk rækkefølge.

Som et eksempel er søgeresultatsskærmen på vores Nimber-app på Android opdelt i to hovedvisninger; den øverste visning, der indeholder handlingslinjen samt et kort med de brugerindtastede placeringer og filtre, og en listevisning med de returnerede søgeresultater.

I Blueprint eller skeletet ovenfor kan du se, hvordan visningsgrænserne er klart defineret i designet. Dette er lag, der er usynlige i Sketch-filen (0% opacitet), men de er yderst nyttige, når du overleverer designet til dine udviklere.

Se nedenfor, hvordan handlingslinjen er opdelt i mindre visninger.

Øverste niveau for visningshierarkiActionBar-visningHandlingselementer med udsynsgrænser med 100% opacitet

Sørg for ikke bare at gruppere dine lag tilfældigt. Definer deres størrelser og afstand på en klar måde (undgå ulige tal) og sorter alt i hierarkisk rækkefølge.

Det samme gælder for lagstilarter, i tilfælde, hvor du har brug for konsekvente streger, afrundede hjørner, drop-skygger, navngiv det.

Denne app kaldet Zeplin hjælper meget her. Lang historie kort: du importerer dit design derinde, og appen udtrækker alle visningsstørrelser, tekststørrelser, farver osv. På en udviklerorienteret måde. Det er et fantastisk værktøj, der bygger bro mellem designere og udviklere, og jeg kan ikke vente med at se, hvad det har for fremtiden.

Når du overleverer dit design, kan udvikleren se på Zeplin og udtrække størrelser, marginer, polstringer fra en enkelt vare og skabe visningen i deres IDE i overensstemmelse hermed.

Design i 1x

Hvorfor er dette lige her oppe ...

Ved at designe i 1x hjælper du først dig selv ved ikke at skulle beregne størrelser i andre skærmdensiteter, men vigtigst af alt er, at både du og udvikleren ender med at bruge de samme tal. På denne måde forhindrer du fejlberegninger, når du overleverer dit design, og holder et konstant sæt værdier.

Dette gælder visningsstørrelser, tekststørrelser, linjehøjder, de fleste tal virkelig ...

Konsekvent farvepalet

Opret én gang, brug altid igen. Prøv at have så få farver som muligt.

Du kan se, at udviklere for det meste bruger navne som Primær, Sekundær, Accent, Aktiveret, Deaktiveret osv. Du kan gøre det samme. Primær og sekundær kan være dine tekstfarver, accent kan være dit brands farve, får du pointen.

I Sketch kan du gemme disse farver i Color Picker, men så vidt jeg ved er der ingen måde at dele dem uden for Sketch-filen. Hvad du kan gøre i stedet er at oprette et tegnebræt med farverne fra din palet sammen med deres navne og hex-koder. På denne måde kan udviklere hurtigt udpakke dem, når de får adgang til dit design via Zeplin, og indsætte dem i appens kode.

Dette er de farver, vi bruger på Nimber-apperne

Design til alle sager

Husk, at udviklere ikke bygger det ideelle brugergrænseflade, men snarere noget, der tilpasser sig det ideelle brugergrænseflade. De skal passe på sager, hvor der ikke er forbindelse, eller der er en serverfejl, eller når der ikke er noget indhold at vise og meget mere.

Så sørg for at designe til ethvert scenarie. Specifikt skal du sørge for at designe hver skærm i dens tomme tilstand, indlæsningstilstand, fejltilstand og den ideelle tilstand. 99% af tiden, disse vil være nok. Denne artikel af Scott Hurff går mere i dybden om tilstande, anbefalet læst.

Skærmstørrelser

Vi lever i en æra med flere skærmstørrelser, så vi er nødt til at designe i overensstemmelse hermed. Dette er en stor aftale, når man designer til Android på grund af dens overflod af enheder, der findes i flere skærmstørrelser.

Den "dove" måde at tackle dette på er at bruge et plugin som f.eks. Sketch-begrænsninger, når du opretter dit design i Sketch. Når du bruger noget lignende, kan du duplikere dine tegnebræt, ændre størrelsen på dem og opdatere tegnebrættet. Utroligt nok tilpasser brugergrænsefladen sig til den passer til den skærmstørrelse.

Den "korrekte" måde at gøre dette på er at designe dit brugergrænseflade til telefonskærme (under 7 tommer), 7 tommer tabletter og 10 tommer tablets. Det er især fantastisk, når du bruger Master-Detail Flows, som er en smuk betegnelse til at kombinere liste og detalje-paneler i et layout, som det nedenfor.

Åh, vil du vide, hvad dette er? Nå, du er heldig!

Ting at huske på

  1. Ikke alle dine brugere vil bruge appen på engelsk. Husk, at tekst muligvis bliver længere (eller kortere) på andre sprog, og du skal tage dette i betragtning, når du designer dine layout.
  2. Du kan ikke cherry pick - du har ikke kontrol over hver pixel. Nogle dele af appen vil uundgåeligt ende med at se mindre end ideel ud på grund af uforudsigelige data.
  3. Prøv at bruge interaktioner, bevægelser, overgange og animationer indbygget i platformen. Dine udviklere vil takke dig.

Sidst men ikke mindst

Kommuniker med dine udviklere! Lad dem uddanne dig. Mens værktøjer som Zeplin og Flinto er en fantastisk måde at dele dit design med udviklere på, har de ikke evnen til at forklare opførselen for hver del af appen. Del viden og stræb efter at opnå det resultat, der er bedst for produktet!

Det er det for denne artikel! Forhåbentlig lærte du noget og gav disse metoder en chance.

God levering! ️

Denne artikel er oprettet af Nimbers designteam, Chris og Andrew. Sørg for at følge os på Twitter!

Og glem ikke at tjekke Nimber selv! Facebook - Twitter

Klik på ♥ ️ for at sprede ordet!