5.0 Introduktion til del 5: UI/UX-design
Denne del handler om, hvor software møder de mennesker, der bruger det. Det dækker meget: den research, der afslører, hvad brugerne har brug for, den grænseflade og det designsystem, der præsenterer det, de ord, der leder til handling, den tilgængelighed og den sprogunderstøttelse, der gør det brugbart for alle, og den frontendudvikling, der leverer det ind i den rodede virkelighed af rigtige browsere og enheder. Det er fristende at behandle alt dette som pynt, man påfører til sidst. Lad være. Det er her, alt det opstrøms arbejde enten når brugeren eller falder fra hinanden, og det afgøres længe før den sidste skærm er poleret.
For store teams er produktdesign egentlig et koordineringsproblem. Når dusinvis af squads leverer ind i ét fælles produkt, hober uafhængige beslutninger sig op til et rod: duplikerede flows, selvmodsigende terminologi, inkonsistente komponenter og en sprogpipeline, ingen ejer. Rettelsen i hvert kapitel her har den samme form. Forvandl engangsbeslutninger til fælles, styrede aktiver, såsom personas, et designsystem, en indholdsstrategi, et internationaliserings- (i18n) framework, komponentbiblioteker og ydeevnebudgetter, så mange teams, der arbejder hver for sig, stadig tilsammen giver én sammenhængende oplevelse.
Virksomheder og det offentlige hæver indsatsen yderligere. Virksomhedssoftware har ofte fastlåste brugere, og de betaler for dårligt design i træning, fejl og supportbelastning frem for ved at gå. Offentlige tjenester når hele befolkningen (herunder mennesker i krise, på gamle enheder, med lav digital tryghed eller uden nogen alternativ udbyder), så designkvalitet bliver et spørgsmål om lighed og borgerlig tillid. Her er tilgængelighed ikke en bonus, men et juridisk krav: offentlige organer er ved lov forpligtet til at bygge software, som mennesker med handicap kan bruge, og forpligtelser om almindeligt sprog og sprogadgang har ofte også lovens kraft.
Kapitler i denne del
5.1 UX-grundlag: De research-, brugermodellerings- og design thinking-praksisser, der lader en organisation træffe evidensbaserede produktbeslutninger i stedet for at gætte, og giver hvert team det samme kort over brugeren.
5.2 UI-design og designsystemer: Håndværket at forme det, folk ser og rører ved, og det fælles, styrede system af tokens, komponenter og mønstre, der holder tusinder af skærme på tværs af mange teams sammenhængende.
5.3 Tilgængelighed: At bygge software, som mennesker med handicap kan opfatte, betjene, forstå og bruge, behandlet samtidig som en juridisk pligt, en etisk pligt og simpelthen godt design.
5.4 Indholds- og kommunikationsdesign: At forme de ord, beskeder og kommunikation, et produkt bruger til at hjælpe folk med at handle, i almindeligt sprog og en ensartet stemme, fordi ord er grænseflade.
5.5 Internationalisering og lokalisering: Den arkitektur, der lader software tilpasse sig ethvert sprog og enhver region, og den arbejdsgang, der oversætter og kulturelt tilpasser den til hvert locale.
5.6 Frontendudvikling: At bygge det klientvendte lag til et miljø, I ikke kontrollerer, med opmærksomhed på frameworks’ levetid, gengivelsesstrategi, ydeevne og robusthed.
5.7 Udvikling af mobilapplikationer: At bygge til mobile enheder med native, cross-platform og progressive webtilgange; platformes designretningslinjer; offline-, batteri- og fragmenteringsbegrænsninger; distribution via app stores samt mobilsikkerhed og -tilgængelighed.
5.8 Designresearch og brugbarhedstest: At reducere risikoen for at bygge det forkerte gennem generativ og evaluerende research, den rette metode til hvert spørgsmål, brugbarhedstest gjort godt, repræsentativ rekruttering og syntese, der faktisk ændrer beslutninger.
5.9 Servicedesign: At designe hele den service, et menneske oplever på tværs af kanaler og over tid, frontstage og backstage, med servicetegninger og kundeoplevelsesrejser og at bringe organisationen på linje bag servicen, ikke blot en enkelt skærm.
5.10 Design af datavisualisering: At vælge det rette diagram til spørgsmålet og kode data ærligt, anvende grafisk ypperlighed, tilgængelige og farveblindhedssikre paletter og klar annotering, så et diagram informerer en beslutning i stedet for at vildlede.
Sådan hænger kapitlerne sammen
Disse kapitler danner én rød tråd fra forståelse til levering. UX-grundlag (5.1) fastlægger, hvem brugeren er, og hvilket job vedkommende forsøger at få gjort. UI og designsystemer (5.2) giver den forståelse en ensartet visuel form. Indholdsdesign (5.4) leverer de ord, der bærer den. Frontendudvikling (5.6) leverer resultatet. Tilgængelighed (5.3) og internationalisering (5.5) er ikke separate trin, men kvaliteter vævet gennem alle de andre: en tilgængelig, oversættelig oplevelse designes ind i fælles komponenter, indholdsmønstre og kode fra begyndelsen, aldrig skruet på senere. Kapitel 5.3 læner sig især op ad kapitel 5.2 for at løse tilgængelighed én gang i hver komponent og op ad kapitel 5.6 for at bevare den i semantisk, standardbaseret markup.
Delen rækker også ud over guidebogen. Mønstret “aktiver frem for engangsløsninger” her spejler det fælles-platformstænkning, der findes i kapitel 8.4 (platformsudvikling og udvikleroplevelse), og værdierne og arbejdsmåderne i kapitel 1.1 og 1.4 sætter de organisatoriske betingelser, der overhovedet gør designsammenhæng mulig. Tjek af tilgængelighed, visuel regression og ydeevnebudgetter hører hjemme i leveringspipelines i kapitel 8.1 (CI/CD og levering), så kvalitet håndhæves ved hver ændring frem for at blive revideret lige før lancering. Og den realbrugermonitorering (ydeevnedata indsamlet fra rigtige brugeres enheder og netværk), som frontendydeevne afhænger af, hænger direkte sammen med observerbarhedspraksisserne i kapitel 9.2. Gjort godt er det, arbejdet her gør, at systemerne beskrevet andre steder faktisk bliver brugbare for de mennesker, de er til for.