Lyt til lydversionen af denne artikel
Som en standard del af UX-processen skaber designere informationsarkitektur, når de udvikler produkter. Ved at definere alle veje og stier, som brugerne kan tage gennem en app eller et websted, er informationsarkitektur meget mere end blot et sitemap, der viser, hvilken side der fører hvorhen.
I lighed med bygningsarkitekter, der bruger en tegningsplan til at konstruere alle dele af et hus, fra fysiske strukturer til mere komplekse indre funktioner som el og VVS, beskriver informationsarkitektur hierarkiet, navigationen, funktionerne og interaktionerne på et websted eller i en applikation. Og ligesom tegninger er det mest værdifulde dokument, som en arkitekt kan bruge til opførelsen af en bygning, kan informationsarkitektur være det mest kraftfulde værktøj i en designers arsenal.
Det er imidlertid ikke så enkelt at udvikle en sådan som at sætte en liste over funktioner sammen og kortlægge, hvordan de fungerer – lad os undersøge processen.
Hvad er informationsarkitektur, og hvorfor er det vigtigt?
Informationsarkitektur (IA) er ligesom et blueprint en visuel repræsentation af produktets infrastruktur, funktioner og hierarki. Detaljeringsgraden er op til designeren, så IA kan også omfatte navigation, applikationsfunktioner og -adfærd, indhold og flows. Der er ingen fast grænse for størrelsen eller formen af IA; ikke desto mindre bør den omfatte produktets generaliserede struktur, så enhver (teoretisk set) bør kunne læse den og forstå, hvordan produktet fungerer.
Vi vil ofte bruge blueprint-referencen, fordi formålet med de to dokumenter er næsten identisk. Ligesom et blueprint giver IA designere (såvel som produktudviklings- og ingeniørteams) et fugleperspektiv af hele produktet. At have et enkelt dokument, der leverer en enkel og forståelig repræsentation af, hvordan applikationen eller webstedet fungerer, er afgørende for udvikling af nye funktioner, opdatering af eksisterende funktioner og for at se, hvad der er muligt i betragtning af det eksisterende produkt.
Med IA til rådighed bliver det betydeligt lettere at træffe vigtige beslutninger om nye funktioner og implementeringer, at forstå tidslinjer for produktændringer og at følge brugeradfærd gennem flere processer.
Lad os dykke ned i en grundlæggende video for at se, hvordan en IA opbygges.
Hvordan man designer informationsarkitektur
Som en del af UX-processen følger IA-design meget lignende mønstre som flowcharting: Tilføj figurer og forbind dem med linjer på en organiseret måde til et enkelt dokument. Udfordringen ved opbygning af IA ligger i at forstå, hvordan din app eller dit websted rent faktisk fungerer fra brugerens perspektiv, og hvordan du organiserer disse oplysninger i et læsbart og letlæseligt format.
Der er to hovedkrav for rent faktisk at konstruere IA: at organisere det gennem et visuelt hierarki (dvs. et hierarki af funktioner, funktioner og adfærd) og at skabe en legende til visning af forskellige typer funktioner, interaktioner og flows. Med et standardflowdiagram følger formerne specifikke krav (rektangler er processer, diamanter er beslutningspunkter osv.); det er dog ikke et krav at følge denne nomenklatur.
Med andre ord er de vigtigste faktorer for opbygningen af din IA, hvor de enkelte komponenter af arkitekturen er placeret (hierarkisk), og hvordan de er mærket og vist.
Understanding and Showing Visual Hierarchy
Det mest udfordrende aspekt ved at skabe en ny informationsarkitektur er næsten altid at opbygge den hierarkisk. Det er en udbredt misforståelse, at IA skal bygges “oppefra og ned”. Det er næsten altid vanskeligere at gøre, medmindre der er tale om et eksisterende produkt, som f.eks. i videoen ovenfor.
Når IA opbygges fra bunden, er det meget vanskeligt at tegne noget efter det øverste niveau, medmindre dit websted eller din applikation følger et standardformat. Det er som at bede en mekaniker om at bygge en bil fra toppen og nedad i stedet for i dele. Hver del skal konstrueres på forhånd med sin egen forskning, tid til design og udvikling. Det samme er tilfældet med IA.
Avisering af visuelt hierarki er et værdifuldt aktiv for IA, ikke kun fordi det giver bedre kontekst for læseren, men også generaliserer vigtige områder af produktet. Hvis din app’s vigtigste funktion er at bestille en tur (a la Uber eller Lyft), hvilket kan gøres fra hjemmesiden, så vil denne side have de fleste berøringspunkter og den største værdi for produktet. Det samme vil gælde for det visuelle hierarki.
Sitemaps er praktiske til at forstå hierarkiet, da de organiserer siderne numerisk (f.eks. 1.0 Home, 2.0 Payment, 2.1 Add Pay Method, osv.). Eller tænk på eksemplet i nedenstående billede for Duke Universitys bibliotekswebsted, hvor topnavigationen ikke kun er øverst, men også er fremhævet, så den er synlig i hele applikationen.
Hierarki af former, farver og andre visuelle elementer
Ud over hierarkiet gør arkitekturen ovenfor en anden ting godt: Den viser hvert enkelt engagementspunkt unikt efter behov gennem en simpel legende og et par centrale sætninger. Legenden angiver side- og indholdstype, og den angiver variationer mellem farverne på figurer. Dette er vigtigt, for selv om Dukes websted ser ret simpelt ud, går IA kun tre niveauer dybt. Hvert gult rektangel betegner en applikation, så processerne i hver af disse kasser er ikke medtaget i dette dokument!
Selv uden disse dele til rådighed er strukturen af en sådan art, at vi kan forstå, hvordan man navigerer på webstedet alene gennem IA’en. Det stopper, når vi når frem til en applikation inden for webstedet – det behøver det ikke at gøre.
Den nedenstående IA er til et spil. Ved hjælp af fire figurer, ingen farver og smart placerede tekststykker er hver vigtig interaktion forståelig uden prototyper, og endnu vigtigere, den kan forstås af alle, der arbejder på den.
Denne model er ikke perfekt, men den organiserer app-hierarkiet klart og afgrænser, hvad brugeren enten ser eller gør på et hvilket som helst tidspunkt.
De bedste informationsarkitekturværktøjer
Der er masser af softwareprogrammer, der gør det muligt at opbygge en IA, men kun få er enkle og hurtige nok til at gøre oplevelsen behagelig. Eller i det mindste er de nemme at administrere.
Draw.io, der bruges i videoen ovenfor, er helt gratis til personlig og professionel brug og tilsluttes automatisk til Google Drive. Det har også integrationer med Confluence og JIRA, som er betalte. Draw.io er fremragende til flowcharting, oprettelse af brugerflows og informationsarkitektur, og med Drive-funktionaliteten kan flere personer arbejde på det samme dokument og se ændringer live. Der er også en gratis offline-version.
Lucidchart er et andet godt værktøj, der giver en lidt bedre oplevelse end Draw.io og har yderligere fordele som forudbyggede skabeloner, mange flere integrationer, en mobilapp (vurderet til 2,5 stjerner i App Store) og understøttelse af enterprise.
Omnigraffle og Visio er mangeårige grundpiller i branchen og fungerer glimrende til opbygning og vedligeholdelse af et IA-design, selvom Visio kun er online (den ældre offline-version er kun til Windows), mens Omnigraffle kun er til Mac og kræver separate køb for MacOS- og iOS-versionerne. OmniGraffle har den ene fordel i forhold til de store konkurrenter, at det giver mulighed for JavaScript- og AppleScript-automatisering, hvilket for de fleste designere kan være unødvendigt, men typisk sætter fuldtidsansatte informationsarkitekter pris på det.
Alle de værktøjer, der er nævnt ovenfor, er lavet med henblik på hastighed og brugervenlighed, specielt omkring flowcharting, som følger næsten identiske principper som informationsarkitektur. Andre programmer som Balsamiq, MindMeister, MindManager eller XMind tilbyder alle en lignende adfærd, men er bygget til andre større formål, såsom prototyping eller mindmapping.
Best Practices for informationsarkitektur
Selv om der kun er få definerede regler for, hvad der udgør informationsarkitektur, skal du overveje følgende, når du gennemgår processen:
Fokuser ikke på hierarki, fokuser på struktur
Hierarki er justerbart. Hjemmesiden vil altid være hjemmesiden, men hvor den fører hen, hvordan brugerne kommer til disse steder, og alt, hvad der ligger imellem og videre, bestemmes senere.
Alle processer skal være logiske
Selv om IA i UX-processen er til brugerinteraktioner, skal hvert trin på vejen give mening. Registreringsskærme bør ikke føre til indstillinger, en kamerafunktion bør ikke springe til en kortvisning … listen fortsætter.
Husk UX-processen
En almindelig fejl er bare at lave IA, uden ressourcer, forskning eller andre aktiver eller arbejde. Det svarer til at bede en forfatter om at skrive en bog uden en skitse, eller en programmør om at kode en app uden prototyper.
Du er kartografen
Kartografer tager alt om et kort i betragtning, lige fra bjergkæder til statsgrænser. Ligesom kortmagere bestemmer designere, hvad der skal indgå i IA-designet. Individuelle sider, specifik brugeradfærd, kontekst for beslutningspunkter … og så videre.
I sidste ende bestemmer kartografen, hvad der skal på kortet ud fra brugernes behov. Det samme gælder for designere, så konstruer IA’en til slutbrugeren, nemlig produktudviklings- og designteams.
Informationsarkitektur er i konstant forandring og udvikling
For at slå pointen fast endnu en gang, så er alle IA’er bygget til forandring. Produkter udvikler sig, design ændres, brugerne tilpasser sig, og cyklussen fortsætter igen og igen. Du skal ikke tage det for alvorligt, og du skal vide, at der altid vil være plads til forbedringer. Du skal ikke stræbe efter perfektion; opbyg en enkel, tilpasningsdygtig IA.
Min informationsarkitektur er færdig… Hvad nu?
Det er en almindelig opfattelse, at ethvert designarbejde aldrig er helt færdigt, og det er helt sikkert tilfældet med informationsarkitektur. De vokser og skrumper og ændrer sig i takt med, at vores produkter gør det. I modsætning til et blueprint til en bygning vil IA altid udvikle sig på baggrund af alt fra brugerbehov til nye funktioner eller en produktoverhaling. En stor del af strukturen kan forblive den samme og skabe konsistens mellem versioner, så brugerne ikke bliver forvirrede.
Og det er en god ting. At vide, at IA er et flydende dokument – et dokument, der sandsynligvis ændres ugentligt og nogle gange endda dagligt – er en effektiv måde at vedligeholde den overordnede struktur for din app eller dit websted på uden nogensinde at røre ved koden eller skabe nye prototyper. Jo bedre hele produktudviklingsteamet kender IA, jo hurtigere vil alle vide, hvad der er muligt og ikke er muligt, og hvor seriøst ethvert formodet “let arbejde” virkelig er.
Det bringer os til den virkelige skønhed ved informationsarkitektur: Der er ikke noget foruddefineret udgangspunkt. Mens den traditionelle UX-designproces dikterer, at IA’en bygges efter at have gennemført tilstrækkeligt mange brugerstrømme; bevæbnet med masser af bruger- og konkurrenceundersøgelser, kan det også være det første, der gøres … eller det sidste. Prototypeprocessen bringer ofte oplysninger frem om, hvordan visse adfærd eller handlinger skal foregå, som det ville være svært at forestille sig ud fra en logisk eller fantasiløs IA.
Som en praksis i konstant udvikling er IA-design en kunst lige så meget som en færdighed, hvilket til dels er grunden til, at store virksomheder har stillinger som informationsarkitekter. Disse designere er gatekeeperne for massive systemer, og med deres forståelse af produktets vækst over tid er de med til at drive produkt-, design- og ingeniørteams til at træffe de rigtige beslutninger i løbet af årene. Denne organisationsskala er ikke for alle designere, men alle designere kan opbygge en enkel, forståelig informationsarkitektur.
– – – –
Anbefalet læsning om informationsarkitektur
IA for the Web and Beyond
How to Make Sense of Any Mess: Information Architecture for Everybody
Information Architecture Basics
Forskellen mellem informationsarkitektur og UX Design