Der er ingen enighed om, hvad en UI-udvikler egentlig er. Halvdelen af internettet placerer rollen under design, den anden halvdel under udvikling, og jobopslagene låner fra begge verdener. Vores holdning er mere enkel: En UI-udvikler er en front-end-udvikler, der også besidder viden om UI-design. Ikke det ene eller det andet. Begge dele.
Det betyder noget, fordi overleveringen fra design til kode er der, hvor kvaliteten af interfacet stille og roligt siver ud. En designfil dækker kun det, nogen har tænkt sig at tegne; alt andet bliver besluttet undervejs af den, der sidder med værktøjerne. En UI-udvikler har begge kompetencer samlet ét sted, så en beslutning bevæger sig fra intention til implementering uden en overlevering. Når arbejdet primært handler om interfacet, betyder det én ansættelse i stedet for to.
Denne artikel er skrevet til to typer læsere. Hvis du overvejer, om du skal finansiere rollen, kan du springe direkte til Hvornår skal man ansætte en UI-udvikler i stedet for en designer og en front-end-udvikler. Hvis du selv er udøveren, er definitionen, færdighederne og de anvendte principper til dig.
En UI-udvikler er en person, der designer og udvikler brugerfladen (User Interface) i en webapplikation. For at forstå, hvad det egentlig indebærer, er vi nødt til at skelne mellem tre begreber, der ofte bliver brugt i flæng: UX, UI og front-end.
Både inden for UI og UX er målet at skabe den bedst mulige brugeroplevelse. Det mål er ikke forbeholdt UX-designere, uanset hvad organisationsdiagrammet måtte sige.
Forskellen ligger i fokusområdet. UX handler om, hvordan en oplevelse føles, og hvad brugeren får ud af den: Det kortlægger på et kognitivt plan, hvordan en person navigerer mod et mål. UI-design omsætter dette kort til noget synligt og beskæftiger sig med udseende, layout, brand-retningslinjer og tilgængelighed.
Så UX-design læner sig op ad brugerresearch og informationsarkitektur. UI-design læner sig op ad det grafiske layout.
UI-udviklere tager udgangspunkt i den vejledning og vision, der er skabt gennem UX-research, og sikrer, at brugerne har de navigationsmuligheder, de skal bruge for at nå deres mål. Menuer, knapper, farver, skriftstørrelse, illustrationer og tekst – alt sammen bygget ud fra designkoncepter. Hvilket fører til det næste spørgsmål: Hvad adskiller UI fra front-end?
Nogle mener, at en UI-udvikler designer produktet. Andre mener, at design også er en del af front-end-udviklerens arbejde, sammen med kodningen, der bringer det til live. Hos Imaginary Cloud mener vi, at det er en blanding af begge dele: En UI-udvikler er en front-end-udvikler med viden om UI-principper og -koncepter. Det er denne viden, der gør dem i stand til at forenkle et projekt i stedet for blot at bygge det, de får serveret.
Det er oprigtigt svært at skelne de to ad, fordi begge arbejder med, hvordan en hjemmeside eller app fremstår på brugerens enhed. En UI-udvikler tilstræber en interaktion mellem bruger og computer, der forbliver enkel og let at navigere i, og det er derfor, stærke designevner og en forståelse for, hvordan grafiske elementer kommunikerer, er værd at tilegne sig.
Front-end-udviklere gør noget lignende, men ikke helt det samme: De integrerer visuelle elementer i hjemmesider og apps, så brugerne kan interagere og navigere ved at implementere designet gennem kodesprog.
En UI-udvikler er altså en kombination af begge verdener. Programmeringsfærdigheder, kreativt design og en dybdegående forståelse for de underliggende koncepter og principper.
UI-udviklere er hverken designere eller front-end-udviklere. Arbejdet ligger midt imellem, og fokus er på en brugerflade, der fungerer og afspejler, hvordan brugerne rent faktisk agerer, frem for hvordan en specifikation forventer, at de gør.
Nogle af de centrale ansvarsområder i rollen:
Hvert af disse trin kræver øje for detaljer og kreativitet, der holdes i balance med funktionalitet, brugeradfærd og forretningsmål.
For den, der finansierer arbejdet frem for at udføre det, er dette en beslutning om teamsammensætning. Ikke en debat om jobtitler.
Omkostningerne ved kløften mellem design og kode. På et traditionelt team beslutter en designer, hvordan en brugerflade skal se ud og fungere, overdrager en fil og gennemgår derefter resultatet. Hver eneste detalje, der var indlysende i designerens hoved, men som aldrig blev tegnet på artboardet – det lærred i et designværktøj, hvor en skærm layoutes – bliver til en rettelse. Hver rettelse er en kommunikationsrunde mellem to personer. En UI-udvikler fjerner dette loop, fordi personen, der implementerer brugerfladen, er den samme, som ved, hvorfor den er specificeret, som den er. Beslutningen behøver aldrig at blive formidlet videre.
Effekten på time-to-market. Fjern overdragelsen, og du fjerner en flaskehals. Det arbejde, der drager størst fordel af dette, er det, der primært består af brugerflade: et marketingsite, et onboarding-flow, et internt værktøj eller en MVP – en første version bygget til at teste en produktidé på rigtige brugere frem for at være komplet.
Leveringsrisikoen. Risikoen ved at opdele rollerne er ikke, at brugerfladen bliver grim. Det er, at responsiv adfærd ved mellemliggende bredder, markørtilstande, fokus-rækkefølge (den rækkefølge, hvori Tab-tasten bevæger sig gennem en side, hvilket er måden, tastatur- og skærmlæserbrugere navigerer på) og loading-feedback ikke er specificeret i en statisk designfil. Tilbage til byggepladsen: Det, som tegningerne ikke viser, må nogen beslutte, mens de står med værktøjet i hånden. En front-end-udvikler, der kender UI-principper, beslutter det bevidst. En, der ikke gør, beslutter det ved et tilfælde.
Tre spørgsmål afgør sagen. Dette er den tjekliste, vi bruger hos Imaginary Cloud, før vi bemander opgaver relateret til brugerflader.
1. Hvor afgrænset er fladen? Tæl de unikke skærme og tilstande, som én person skal kunne overskue på én gang. Et marketingsite, et onboarding-flow eller et internt værktøj kan håndteres af én person. Et produkt med mange flader, der alle skal forblive konsistente med hinanden, kan ikke.
2. Findes der allerede en designretning? Hvis der findes et brand, et komponentbibliotek eller et designsystem at arbejde ud fra, er opgaven trofast eksekvering, og det er netop, hvad en UI-udvikler gør. Hvis selve retningen stadig skal opfindes, er det først og fremmest en designeropgave.
3. Hvor meget dybdegående research kræver produktet? Hvis produktets ubesvarede spørgsmål kan besvares ved at observere, hvordan brugerfladen opfører sig, kan én person klare opgaven. Hvis der er brug for dedikeret brugerresearch, testrunder og et vedligeholdt designsystem, har du brug for en fuldtids-designfunktion.
Afgrænset flade, fastlagt retning, fokus på eksekvering frem for research: Ansæt én UI-udvikler. Hvis to eller flere svar peger i den anden retning, er det din grænse for at ansætte både en designer og en front-end-udvikler. Hybridrollen fjerner en overdragelse. Den erstatter ikke en designfunktion, og enhver, der påstår andet, forsøger blot at sælge dig en billig løsning.
Tag Eurofound, EU-agenturet, hvis database for platformøkonomi havde brug for en brugervenlig front-end. Opgaven var stram: en fungerende grænseflade på seks uger, bygget efter en eksisterende designguide og uden en dedikeret designer tilknyttet. En af vores front-end-udviklere tog i stedet styringen med grænsefladens design, anvendte Eurofounds designguide for at sikre visuel sammenhæng og afstemte løbende valgene med vores egne designere. Den samme person byggede Django-back-enden, der hentede indhold fra den eksisterende database, forbandt front-enden til den og tilføjede kategorifiltre samt fritekstsøgning, så brugerne kunne navigere gennem tusindvis af dokumenter uden at fare vild. Det er hybridrollen i praksis: en afgrænset opgave, hvor designretningen er lagt fast, og hvor eksekvering vægtes højere end ny research. Det er netop i sådanne tilfælde, at én person med begge kompetencer fjerner behovet for en overlevering, frem for at to personer skal koordinere det på tværs af filer. Det er også det, der gør det muligt for en front-end-udvikler at rejse et designspørgsmål direkte under implementeringen i stedet for at skulle sende arbejdet retur.
Læs dette afsnit to gange, hvis du er i gang med at ansætte. Det fungerer også som en guide til, hvad du skal kigge efter hos en kandidat.
Gode UI-udviklere er fortrolige med både design og webudvikling. Ideelt set kan de arbejde med grafiske designværktøjer som Figma, som i dag er førende inden for interface-arbejde, og hvor designsystemer bygges: et delt bibliotek af komponenter og regler, der sikrer, at alle skærmbilleder er konsistente. Sketch bruges stadig, primært på Mac, og du vil støde på Adobe XD i ældre filer, selvom Adobe har sat XD i vedligeholdelsestilstand, så betragt det som forældet frem for et værktøj til nye projekter.
De har også brug for webteknologier. HTML, CSS og JavaScript.
Udover disse er det en fordel at forstå AJAX (det ældre navn for at opdatere en del af en side uden at genindlæse den, hvilket nu håndteres af browserens indbyggede fetch), jQuery (et JavaScript-bibliotek, der forenkler arbejdet med DOM'en, browserens levende træ af elementer på en side, som du primært vil møde ved vedligeholdelse af eksisterende kode frem for i nye projekter) og JSON (det tekstformat, de fleste API'er bruger til dataudveksling). Ved siden af disse findes værktøjer, der er værd at kende i dag: MUI (tidligere Material UI), et React-komponentbibliotek, der implementerer Googles Material Design, CodePen og Sass, en CSS-preprocessor, der tilføjer variabler og genanvendelige blokke. Sass skrives i en syntaks kaldet SCSS, som er den form, der bruges i eksemplerne længere nede.
Så er der den del, som ingen kurser dækker. Et æstetisk og intuitivt blik for det visuelle kan ikke installeres; øvelse og kritik er den eneste vej frem. Designkoncepter og principper omkring farver, typografi, mønstre og afstand er det, der gør, at en udvikler kan forudse brugerens perspektiv i stedet for at gætte sig frem.
Udover at få det til at se godt ud, gør UI-udviklere produkter så intuitive, at brugeren aldrig behøver at tænke over interfacet. Det kræver empati. Empati er det, der gør, at en UI-udvikler kan sætte sig i brugerens sted og gennemskue, hvad de kom for at gøre.
Sandheden er, at UI-udviklere har tendens til at være perfektionister omkring, hvordan ting ser ud og fungerer, og de ved præcis, hvor stor en forskel en "tilsyneladende uvigtig" detalje gør. Det er i detaljerne, at denne rolle beviser sit værd. Hvilket er grunden til, at en god UI-udvikler har et unikt blik for dem.
Rollen er en blanding, så der er mere end én vej ind. En uddannelse inden for grafisk design giver dig det designmæssige fundament: designprincipper, branding og brugerundersøgelser. En datalogisk uddannelse med speciale i front-end giver dig de tekniske færdigheder, herunder programmeringssprog, beregningskoncepter og en praktisk forståelse af, hvordan rollerne i et webudviklingsteam spiller sammen.
Uanset hvilken vej du vælger, mangler du stadig at lære halvdelen af jobbet. Kommer du fra grafisk design, skal du lære at programmere. Kommer du fra udvikling, skal du lære designprincipper. Ingen af delene kræver en formel uddannelse: Kurser og certificeringer, hvad enten de er online eller fysiske, er ofte mere fokuserede og værktøjsspecifikke, og det er den praktiske del, der opbygger en portefølje fra første uge.
Uanset uddannelsesbaggrund er porteføljen det vigtigste bevis. Det gælder både, når du selv bygger den, og når du vurderer andres.
En stærk portefølje viser tankegangen bag arbejdet. Hvorfor dette layout og ikke et andet, hvilke begrænsninger der nødvendiggjorde et kompromis, og hvad udvikleren ville ændre i dag. En svag portefølje viser blot færdige skærmbilleder uden forklaring på, hvordan man er nået frem til dem. Hvis du er ved at sammensætte din egen, så bed andre UI-udviklere og folk uden for branchen om ærlig feedback, da sidstnævnte gruppe reagerer som brugere frem for som fagfæller.
Brugerfladen er det første, en bruger møder. Hvis den ikke er tiltalende og nem at bruge, forlader de måske siden, før de overhovedet når frem til produktets funktioner. Derfor er det en fordel for en front-end-udvikler at lære om UI og designprincipper.
Gevinsten er ikke abstrakt. I et Imaginary Cloud-projekt betød en forbedring af selve brugerfladen alene, at brugen af appen blev tredoblet.
Forståelse for design forbedrer også samarbejdet mellem udviklere og UI/UX-designere, fordi begge parter forstår årsagen bag en given beslutning. At læse aktuelle designbøger og se, hvordan andre brugerflader løser tingene, er den billigste måde at opbygge denne viden på. Som front-end-udvikler hjælper kendskab til UI-principper dig med at:
UI-principper bliver normalt rettet mod design, og der findes masser af lister, der guider dette. De tre nedenfor stammer fra de etablerede sæt: Jakob Nielsens ti heuristikker for brugervenlighed for Nielsen Norman Group, Ben Shneidermans Eight Golden Rules of Interface Design [editor note: add a verified link to a primary Shneiderman source before publishing], og de samlede lister på principles.design. Lad os i stedet tage udgangspunkt i udviklingssiden og se, hvad en front-end-udvikler tilføjer.
Konsistens topper næsten enhver liste, der guider UI-design. Hele platformen skal se ensartet ud, så brugeren kan opbygge en præcis mental model af produktet og hurtigt gennemskue, hvad de kan gøre med det. I designet viser det sig som ensartede former, farvepaletter og defineret typografi.
Konsistens er også nøglen til en smidig implementering, da det giver dig mulighed for at genbruge elementer, adfærd og udseende. Hvor det bliver en udfordring, er på tværs af forskellige vinduesstørrelser.
Definer værdier én gang med SCSS-variabler og mixins
Hvis du får muligheden for at bruge SCSS i stedet for traditionel CSS, så gør det. Variabler lader dig ændre en værdi, der bruges halvtreds steder, uden at skulle lede efter hver enkelt og bekymre dig om den, du overså. Giv den ønskede værdi til en variabel, og brug den derefter, hvor du vil. Det er ideelt til farvepaletten, typografi og tungere ting som skygger eller gradienter.
// _variables.scss
$colour-primary: #0f62fe;
$colour-text: #1a1a1a;
$font-body: "Inter", sans-serif;
$shadow-card: 0 2px 8px rgba(0, 0, 0, 0.12);
.button {
background: $colour-primary;
font-family: $font-body;
box-shadow: $shadow-card;
}For at genbruge mere end blot en enkelt værdi, skal du bruge @mixin og @include. Definer stilblokken én gang med @mixin, og anvend den derefter på hvert målelement med @include.
@mixin card-surface {
background: #ffffff;
border-radius: 8px;
padding: 24px;
box-shadow: $shadow-card;
}
.pricing-card {
@include card-surface;
}
.testimonial-card {
@include card-surface;
text-align: center;
}Brug breakpoints og relative enheder, så layouts holder ved enhver bredde
Når man implementerer et design, er det nemt at tage de præcise værdier, man har fået oplyst, eller noget der ligner. Det ser korrekt ud i starten. Men så trækker du vinduet smallere, og det falder fra hinanden: ting bliver skåret af eller skubbet et sted hen, som ingen havde tiltænkt.
Start med breakpoints, de vinduesbredder hvor et stylesheet skifter til et andet sæt regler. De lader dig ændre stilen på komponenter fra en bestemt størrelse og opad, hvilket er måden, du får en desktop- og en mobilversion af en side på uden at duplikere HTML'en.
For størrelserne derimellem skal du gøre strukturen fleksibel. Det er ikke alle, der browser i fuld skærm. I stedet for præcise bredder, så brug relative længdeenheder, som skalerer et element i forhold til dets container eller viewport frem for i faste pixels. Hvis designet har en side på 2000px med et element, der fylder 1400px og har margener på 300px på hver side, så brug en bredde på 70% og margener på 15% i stedet.
Bootstrap, et CSS-framework, hjælper i begge tilfælde, da dets kolonner tilpasser sig den bredde, der er til rådighed. Forskellen er let at se selv. Byg det samme layout to gange, én gang med procenter og én gang med faste pixelværdier, og træk derefter i vinduet for at gøre det smallere. Procentversionen tilpasser sig og bevarer sine proportioner. Den faste version beholder sine mål og ødelægger layoutet, hvilket skubber indholdet ud af syne eller ned på den forkerte linje.
Et systems effektivitet måles normalt på den tid, en bruger bruger på at fuldføre en opgave, og antallet af klik. Med velkendte termer, veldefinerede lag og en logisk organisering når brugeren hurtigere frem. UI/UX-designet bærer det største ansvar for at guide brugeren. Men som UI-udvikler er der konkrete ting, du kan gøre for at reducere antallet af klik.
Forbind formularlabels med deres inputfelter
Når brugere udfylder en formular, klikker de ofte på navnet på feltet, altså labelen, frem for selve inputfeltet. Hvis labelen ikke er forbundet til inputfeltet, sker der intet ved klikket, og brugeren må klikke igen. Løs det ved at definere et id på inputfeltet og en for-attribut på labelen.
<label for="email">Email address</label>
<input type="email" id="email" name="email">Brug autofocus på det første felt for at spare et klik
Vi bliver ved formularer. Når formålet med en side er at indtaste information, er halvdelen af arbejdet gjort for brugeren, hvis det første felt allerede er valgt. Brug autofocus på det første eller vigtigste felt, så har du sparet et klik. Det virker både på desktop og mobil, hvor det også åbner tastaturet.
Nogle brugere vil stadig trykke på feltet. Men på loginside sparer det et trin i en proces, som folk gentager ofte. autofocus-attributten fokuserer inputfeltet, når siden indlæses, og JavaScript kan gøre det samme ved at vælge elementets id og kalde .focus() (jQuery gør det samme i ældre kodebaser).
<input type="email" id="email" name="email" autofocus>
document.getElementById("email").focus();Gør hele det klikbare område klikbart
Der er få ting, der irriterer brugere mere end en sektion, der ser klikbar ud, men hvor kun teksten reagerer. Det ses ofte i mobilmenuer, og det giver brugeren en grund til at forlade siden. Hvis du har en stor knap med lille tekst indeni, forventes det, at hele knappen aktiverer handlingen, ikke kun det område, hvor teksten står.
En menulinje viser det tydeligt. Hvis du kun lægger linket omkring teksten, skal brugeren ramme ordene; lad linket fylde hele rækken, så reagerer hele rækken. Sæt linket til display: block inde i listeelementet, så det fylder hele bredden og højden.
Brug luft (white space) til at gruppere det, der hører sammen
I en brugergrænseflade bør ting, der fungerer ens, også se ens ud. Elementer, der relaterer til hinanden, placeres sammen, mens urelaterede elementer holdes adskilt. Udover typografi, farve og form er det luft, der skaber denne følelse af sammenhæng. Det giver også siden ro og reducerer mængden af information, der skal bearbejdes på én gang, hvilket gør det lettere at træffe den næste beslutning.
Designer du selv? Betragt luft som en usynlig ramme. Hvor du føler, at du har brug for en linje til at adskille to sektioner, vil luft som regel gøre arbejdet.
Hvis du implementerer en andens design, så respekter proportionerne og mængderne, for der er en grund til, at nogen har valgt dem. Brug relative længdeenheder, så proportionerne bevares, når bredden ændrer sig, og brug præcise højdeværdier. En margin på 47px er præcis det, ikke 45px eller 50px. Vær opmærksom, når du tilføjer margin eller padding til et element, hvis nabo allerede har noget: Lav regnestykket, så afstanden mellem dem bliver præcis, som den var tiltænkt.
Brugere har brug for at vide, hvad de kan gøre, hvad de er i gang med, og hvad de har gjort. Giv feedback om systemets status, når en handling er fuldført, eller når noget tager længere tid end normalt. Uanset hvad der sker, så informer brugeren. Lad aldrig nogen være i tvivl om resultatet af deres egen handling.
Brug den markør, brugeren forventer
Markørikoner er standarder, vi håndterer hver dag. Når du ser en bestemt markør, ved du, hvilken type handling den repræsenterer, og det er netop derfor, en uventet markør skaber forvirring. Klikbar betyder en pegefinger. Kan trækkes betyder en åben hånd, der bliver til en lukket. Tjek markøren på brugerdefinerede elementer, og udnyt de HTML-elementer, der allerede har disse egenskaber defineret.
Brug animation til at vise systemstatus
Animationer er ikke til for at gøre tingene pænere. Når de anvendes på små elementer, skaber de kontinuitet, handling og fremdrift, og en bruger er mere tilbøjelig til at huske, hvad de lige har gjort, hvis de så det ændre sig gradvist i stedet for alt på én gang.
Tænd/sluk-knapper er det tydeligste eksempel. Hvis knappen bare skifter tilstand ved et klik, sidder brugeren tilbage og spekulerer på, om de fik klikket, og hvilken tilstand den var i før. Animer overgangen, så har de set det ske.
Animation er også måden, du rapporterer, hvad der foregår ude af syne. Hvis en handling tager tid, så vis en indlæsningscirkel eller en statuslinje i stedet for en tom side, så forsinkelsen opfattes som arbejde i gang frem for en fejl.
Hvis du arbejder med front-end-udvikling, så tal med UI/UX-designeren. Der er næsten altid forslag, som aldrig kom med på papiret, og som er meget billige at implementere. Når du sidder fast i en specifik opgave, så tag den med tilbage til designteamet sammen med de muligheder, du ser. På den måde bliver begrænsninger og designintentioner løst i fællesskab frem for hver for sig. Participatory design er en struktureret måde at gribe den samtale an på.
Designer du alene? Få alligevel en UI/UX-designer til at kigge det igennem. De vil opdage, hvad der ikke passer ind, om størrelserne er korrekte, og hvilke alternativer du aldrig havde overvejet.
En UI-udvikler er hverken en front-end-udvikler eller en designer, men en blanding af begge, så det underliggende spørgsmål i hele artiklen handler om bemanding. Interface Ownership-testen er vores svar på dette: afgrænset overflade, eksisterende designretning, fokus på eksekvering frem for dybdegående research, og én UI-udvikler eliminerer den overlevering fra design til kode, som en designer og en front-end-udvikler ellers skal vedligeholde. Et produkt, der kræver fuldtids-designresearch og et vedligeholdt designsystem sideløbende med fuldtids-implementering, har brug for begge roller, og ingen test kan overbevise dig om andet.
Fejlen er ikke at vælge forkert mellem dem. Fejlen er at opdele rollerne og aldrig opdage, at responsiv adfærd, fokus-rækkefølge og loading-feedback endte med ikke at blive specificeret af nogen og derfor blev implementeret som standard.
Selvom du forbliver front-end-udvikler, er designfærdigheder alle pengene værd. Konsistens, brugseffektivitet og gennemsigtighed ændrer, hvad en bruger er i stand til at gøre i en applikation – ikke blot hvordan den ser ud – og de bliver implementeret i front-enden, uanset om nogen har specificeret dem eller ej.
Nej, selvom de to overlapper hinanden meget. En front-end-udvikler implementerer en grænseflade. En UI-udvikler implementerer den og besidder den designmæssige viden, der afgør, hvordan den skal fungere, så de beslutninger, som en designfil lader stå åbne, bliver truffet bevidst frem for som standard. Hos Imaginary Cloud betragter vi en UI-udvikler som en front-end-udvikler med UI-principper, ikke som en separat disciplin.
Ja. HTML, CSS og JavaScript er kernen i rollen, sammen med værktøjer som Sass og komponentbiblioteker som MUI. En UI-udvikler, der ikke kan levere selve grænsefladen, er en UI-designer.
Designmæssigt: farver, typografi, afstande, mønstre, tilgængelighed og nok kendskab til brugerresearch til at kunne læse UX-output. Udviklingsmæssigt: HTML, CSS, JavaScript samt nyttige tilføjelser som Sass, AJAX, jQuery og JSON. Under begge dele ligger empati for brugeren og et øje for detaljer, da det er i detaljerne, at rollen for alvor gør en forskel.
Tag vores "Interface Ownership Test": Hvor afgrænset er opgaven, findes der allerede en designretning, og hvor dybdegående research kræver produktet? En afgrænset opgave, en eksisterende retning og fokus på eksekvering frem for research peger på én UI-udvikler, hvilket passer til et marketingsite, et onboarding-flow, et internt værktøj eller en MVP. Hvis to eller flere svar peger i den anden retning, bør du ansætte begge dele.
Til design: primært Figma, mens Sketch stadig findes og Adobe XD kun bruges til ældre filer, typisk med et designsystem for at sikre konsistens på tværs af skærme. Til implementering: HTML, CSS og JavaScript, plus Sass, MUI, CodePen og Chrome DevTools.
I praksis ja, og ofte som en selvfølge frem for som en specifik opgave. Fokus-rækkefølge, markørtilstande, parring af labels og inputfelter, kontrast og adfærd ved forskellige skærmstørrelser bliver alt sammen besluttet under implementeringen. En UI-udvikler, der kender til UI-principper, træffer disse valg med vilje.
Mellem UX-design og front-end-udvikling, i dialog med begge parter. Rollen tager imod vejledning fra UX-research, træffer UI-beslutningerne og implementerer dem, hvilket er grunden til, at kommunikation med designere, front-end- og backend-udviklere er en integreret del af jobbet.
Overvejer du, hvordan du skal strukturere dit front-end- og designarbejde? Se hvordan vi har gjort det i vores cases, eller tag fat i os.
Webudvikler med en særlig kærlighed til front-end. Mor til katte. Jeg forsøger at hjælpe med at redde planeten i min fritid ved at dele miljøvenlige alternativer.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
.webp)
