ABSTRACT: Hvordan forklarer man på to minutter hvad informationsarkitektur er? Læs Christina Wodkes bud, og få samtidig historien om, hvordan en af branchens største profiler arbejder. Fra hendes første hjemmeside til det komplekse virksomhedssite.
Artiklen er oprindeligt publiceret på Sitepoint, "Information Architecture Defined"
December, 2000
Oversat af Anders Schrøder, Redigeret af Stig Andersen
August, 2003
”Du ved - når du er på et site, og ser en masse muligheder for navigation, som man kan klikke på, ikk’? Det er mig, der har besluttet hvilke muligheder, der skal være, hvad de hedder, og hvor de bringer dig hen, når du klikker.”
Yep, det har jeg sagt. Og jeg bliver ofte nødt til at forklare, hvad informationsarkitektur (IA) er – ret ofte. I skrivende stund er alle i hvert fald enige om én ting: Det er et fag, der i fokus. Der er knap så mange, der ved hvad informationsarkitekter laver. Søg på dice.com eller hotjobs.com, og du vil se en besynderlig vifte af kvalifikationskrav, fra kodning i Perl til grafisk design. På et tidspunkt troede jeg, at titlen informationsarkitekt ville udvikle sig ligesom webmaster-titlen: En god titel for små firmaer, der har brug for en medarbejder, der kan lidt af hvert, men dårlig for dem, der har brug for eksperter. Heldigvis er en vedholdende indsats fra nogle få, højt profilerede informationsarkitekter ved at ændre dette, og nu har vi i det mindste indkredset vores arbejdsområde.
Næsten som vores navnebrødre i byggebranchen, designer vi rum, som mennesker kan leve, arbejde og hygge sig i. Den store forskel er det materiale, vi arbejder i: Cement bliver erstattet af tesaurusser, træ med begrebshierarkier og stål med interaktionsdiagrammer. Forvirret? Lad mig fortælle en historie fra den virkelige verden. Nåh ja, ved at gøre det, bliver jeg nødt til at indrømme, at jeg er lidt af et fjols. Jeg håber ikke, at dét ødelægger for meget.
Da jeg lavede min første hjemmeside på Geocities, var der kun én side. Jeg havde billeder af mine venner, lidt historie om mig og et link, så man kunne maile mig. Ret typisk. Der var ingen informationsarkitektur endnu, men så afgjort informationsdesign, som er tæt knyttet til IA. Jeg vidste, at folk, der var kommet til min side ville vide hvad de kigger på. Så jeg skrev en stor H3-overskrift tværs over toppen af siden: ”Velkommen til Christina Wodke’s personlige hjemmeside”. Derefter ville jeg have noget information om mig selv, så jeg puttede historien og nogle billeder på. Endelig tænkte jeg, at hvis folk ville læse alt dét, ville de måske også i kontakt med mig, og så jeg lavede mit mail-link. Underligt nok var designet ret brugercentreret; jeg startede med at spørge mig selv, hvordan folk, der kom forbi siden ville bruge den.
Min næste hjemmeside krævede en noget større indsats. Jeg havde samlet en masse opskrifter, som jeg havde fundet på nettet, mens jeg gennemgik mad-sites for snap.com. Jeg havde også nogle opskrifter fra min familie og nogle jeg havde fundet hos min mands ven fra Frankrig. Jeg ville have dem alle sammen på nettet, så jeg altid havde adgang til dem; hos mine forældre, min kæreste (min nuværende mand) eller hjemme. Da jeg stadig havde til gode at blive en god informationsarkitekt, startede jeg med research – jeg gennemgik alle mine kogebøger for at se, hvordan de var organiserede. Jeg havde en overflod af organisationssystemer at vælge imellem: Efter region, ret, hovedingrediens... ærligt talt vidste jeg ikke, hvilket der var klogest at vælge. Det var dér, jeg brugte et glimrende værktøj for enhver IA’er: Kortsortering. Opskrifterne stod allerede på kartotekskort. Jeg lagde dem ganske enkelt ud på gulvet og begyndte at gruppere dem i ens bunker. Temmelig hurtigt fandt jeg ud af, at jeg burde vælge en organisering efter rettens placering i måltidet: Forret, hovedret, dessert osv. Min opskriftsside. Den side jeg byggede i 1996, har stadig nøjagtigt den samme opbygning, og jeg laver stadig mad efter den, mens jeg sukker over de sammenpressede gif’er og den primitive typografi. Men jeg kan altid finde den opskrift, jeg leder efter.
Her sidste weekend tog jeg over til en IA-kollegas kontor. Vi brugte dagen på at omstrukturere et IT-konsulenthus’ site, med over 2.000 indholdskomponenter. Vi startede på samme måde som med min første hjemmeside: Vi fordybede os i dokumentationen for at finde ud af, hvem brugerne var, og lære deres primære behov at kende. Vi skrev navnene på tre personer, som vi mente ville bruge sitet, og under hvert navn skrev vi deres brugerbehov. Dave, direktøren, som ville vide om han skulle købe produktet. Jill, den potentielle medarbejder, som ville vide om det var et fedt sted at arbejde. Carla, investoren, som ville vide om virksomheden var et hot investeringsobjekt.
Herefter gjorde vi nøjagtigt det samme som jeg gjorde, da jeg lavede mit andet site nogen sinde: Printede listen over indholdskomponenter ud og klippede den op i små lapper. Så gennemførte vi den største kortsortering, jeg nogensinde har lavet. Vi grupperede alle de ens indholdskomponenter og opstillede dem derefter i hierarkisk orden – et begrebshierarki. Derefter lavede vi rollespil; vi forestillede os, at vi var de forskellige modelbrugere, der forsøgte at bru-ge strukturen i hierarkiet. ”Jeg er direktøren Dave. Jeg har brug for at vide, om mit problem bliver løst, hvis jeg køber dette produkt. Hvor kan jeg læse om opgraderinger? Er der anmeldelser af produktet? Hvor lang tid har firmaet været oppe at køre?” og så videre. Vi ændrede lidt på nogle af grupperingerne, og så var vi færdige.
Selvfølgelig er det ikke det eneste, en informationsarkitekt gør ved et site. Det er kun hvad en informationsarkitekt måske laver for et indholdstungt site. Men de grundlæggende principper fremgår: Forstå brugeren. Forstår hvad firmaet tilbyder. Smelt de to dele sammen.
Og gå så ud og gør dit site nemmere at bruge for kunderne…
Christina Wodke er partner i Carbon IQ, et konsulentfirma i San Francisco, der specialiserer sig i brugerfokuseret informationsarkitektur. Hun har grundlagt Boxes and Arrows og var blandt stifterne af Asilomar Institut for Informationsarkitektur.
ABSTRACT: I denne letlæste, men grundige og overskuelige artikel giver Thomas Myer en indføring i informationsarkitekturens verden. Hvad er informationsarkitektur egentlig? Hvad laver en informationsarkitekt? Hvad er hans redskaber? Thomas Myer er informationsarkitekt og skribent. Han har arbejdet for bl.a. Vignette og Cisco Systems samt skrevet for bl.a. IBM DeveloperWorks.
Artiklen er oprindeligt publiceret på IBM developerWorks, "Information architecture concepts; Misconceptions explained".
Juli, 2002
Oversat af Jens Aage Pedersen, Redigeret af Stig Andersen
Juli, 2003
Informationsarkitekten er et væsentligt medlem af et webudviklingsteam, og spiller en afgørende rolle når indholdet på et website organiseres. Denne artikel forsøger at udrede nogle misforståelser vedrørende informationsarkitektur og medvirke til at definere den rolle, en informationsarkitekt spiller i udviklingen af websites.
Hvad er informationsarkitektur egentlig? Er det det samme som informationsdesign? Er det det samme som design, punktum? Når der søges informationsarkitekter synes stillingsopslaget til tider at indebære, at en informationsarkitekt kan være alt fra en databasearkitekt til en visuel designer, som skal dække alle formål, til en overordnet teknisk dokumentarist.
I denne artikel vil jeg besvare nogle af de spørgsmål, der stilles her i introduktionen, måske få bugt med en del forvirring, og videregive nogle kilder til yderligere læsning.
Den bedste måde at forestille sig forskellen på en informationsarkitekt og en designer, er at tænke på det som forskellen på en bygnings arkitekt og dens indretningsarkitekt.
Arkitekten er primært interesseret i struktur, flow, og grundlæggende spørgsmål som placeringen af rørarbejdet og de elektriske systemer. Hvis arkitekten ikke gør sit arbejde ordentligt, risikerer bygningen at falde sammen eller ikke at opfylde de behov, som bygningens brugere eller beboere måtte have. For eksempel kan det være, at der ikke er soveværelser nok.
På den anden side interesserer indretningsarkitekter sig for boligudstyrets farver, placering og stil, for teksturer, overflader og hvordan det hele appellerer til sanserne. De forsøger måske at give rummene et bestemt udtryk, såsom middelhavsstil eller kolonistil, eller sikre sig, at farverne og stilarterne følger et bestemt tema i hele bygningen.
Dermed ik ke sagt, at den ene opgave er nemmere eller sværere end den anden. Blot at de er forskellige. Der vil selvfølgelig altid være overlap (for eksempel interesserer arkitekten sig for det visuelle udtryk, og designeren interesserer sig for flow og adgangsmuligheder), men generelt komplementerer de to discipliner hinanden. Man ville aldrig bede en indretningsarkitekt om at tegne et hus, og man ville næppe nøjes med arkitektens holdning til, hvilke farver man skulle male væggene i sin stue.
Når man overfører billedet til webudvikling, holder parallellerne. Informationsarkitekten har generelt ikke megen erfaring i design af identitet, farver, layout og visse former for visuel kommunikation – på de områder er designeren den sagkyndige. Informationsarkitekten er imidlertid en person, der har en baggrund i kategorisering, XML, produktion og organisering af indhold, interaktionsdesign og navigationsdesign. Deres ekspertiseområde er informationsstrukturer, og resten af denne artikel helliger sig beskrivelsen af, hvornår, hvor og hvordan denne ekspertise anvendes.
Det bedste tidspunkt at bruge en informationsarkitekt på er lige i begyndelsen af udviklingsarbejdet. Ligesom man ikke ville hidkalde en rigtig arkitekt til byggepladsen, lige når taget skulle til at sættes på de vakkelvorne mure, er det generelt en god idé at indforskrive hjælp fra en ekspert, før man løber ind i problemer med et website.
Men ligegyldigt hvornår man inddrager en informationsarkitekt, vil han sædvanligvis ønske at forstå følgende parametre vedrørende projektet:
- Brugernes mål og behov
- Forretnings-/organisationsmål
- Tekniske begrænsninger
- Indholdsmæssige begrænsninger
- Projektmæssige begrænsninger
Forståelsen af brugernes mål og behov kommer ikke bag på nogen af denne artikels læsere, der arbejder med usability. Der er imidlertid andre overvejelser, som Jakob Nielsen-flokken måske ikke er stødt på før. En informationsarkitekts væsentligste anliggende er at bygge informationsstrukturer, der er nemme at forstå og bruge. For at gøre dette må han bringe virksomhedens mål på linie med brugernes mål og på samme tid arbejde inden for de begrænsninger, som ligger i projektet (tidsfrister, ressourcer, budget osv.), tekniske spørgsmål (valg af udviklingssprog, database osv.) og produktionen af indhold (personale, hvor stor en del af staben skal findes internt/ansættes freelance osv.).
For eksempel påvirker valget af et sprog frem for et andet måske måden, som fremstillingsformen håndteres på en content-portal, hvilket kan påvirker den grundlæggende interaktion mellem brugere og indhold. Konkret kan det betyde, at indholdet skal gemmes som én lang side i stedet for at blive brudt op i mindre sider. Et godt eksempel på en indholdsdefineret begrænsning kunne være en lille stab af skribenter, der kun har lidt eller ingen specialekspertise i det emne, websitet handler om. Denne begrænsning går måske stik imod det primære forretningsmål: At skabe et website, hvis redaktionelle dækning går i dybden på området. I det tilfælde bør forretningen måske overveje at ansætte flere skribenter eller øge budgettet til freelancere.
Selv om begge disse emner på overfladen ikke synes at have meget at gøre med, hvordan indholdet organiseres og grupperes på et website, kan de begge have vidtrækkende konsekvenser for brugerens grundlæggende interaktion med indholdet.
Et websites indhold er ikke et statisk objekt: Ikke blot kan struktureringen og præsentationen ændre sig. Der kan også ske forandringer fra dag til dag. Det er afgørende for en vellykket informationsarkitektur, at man er opmærksom på indholdsstrategien og er på linie med forretningsmålene.
Informationsarkitektoniske opgaver foregår som regel i to trin: Først ved brug af en metode, hvor man arbejder oppefra og ned (top-down), efterfulgt af en fremgangsmåde, hvor man arbejder nedefra og op (bottom-up).
Først udfører man som regel en informationsarkitektonisk top-down-vurdering. Som navnet antyder, hjælper denne fremgangsmåde informationsarkitekten til at forstå det store billede og med at arbejde sig ned mod detaljer vedrørende præsentationen, sideflow og indholdsstruktur.
For eksempel er forståelsen af bruger- og organisationsmål én ting, men det er nødvendigt at oversætte dem til en slags samlet billede af websitets indholdsstruktur. Hvis det website, man er ved at bygge er en portal, der formidler oplysninger om og sælger vintersportsudstyr, så får informationsarkitekten brug for at vide, i hvilke termer brugere og købere af den slags udstyr opfatter den slags oplysninger. For eksempel ville snowboards og ski være forskellige produkt- og indholdskategorier. Og skiløb indeholder måske flere forskellige underkategorier, såsom langrend og alpint skiløb. Måden hvorpå websitet er struktureret oppefra kan medvirke til at gøre indholdet nemmere at navigere rundt i.
Herpå følger en bottom-up-vurdering. Den hjælper informationsarkitekten til at forstå de underliggende små stumper, der får det hele til at virke, nemlig metadata og alle de ting, der er forbundet med metadata: Hvad det skal gøre, hvor det skal gemmes, hvordan det skal grupperes, og hvordan de forskellige metadata skal vekselvirke.
Som man kan forestille sig, er metadata det, store dele af aktiviteten på websitet står og falder med, lige fra søgemaskiner og personificering til organisationen af indholdet. Men hvad er metadata? Metadata er, bogstaveligt talt, ”data om data”. Et eksempel: Når vi taler, kan de ord, der kommer ud af vores mund ses som data. Men vores tonefald, vores kropssprog, selv lytterens personlighed eller indstilling kan alle betragtes som metadata. Metadata beriger altså vores forståelse af data.
Lad os viderefører eksemplet med vintersportswebsitet.Websitets ejere vil have, at enhver der læser en artikel om styrtløb skal se beslægtede produkter fra websitets onlinebutik i en højrespalte. En måde at nå frem til dette er ved at oprette en taksonomi for metadata: En slags hierarki af udtryk og begreber, som kan tillægges både indhold og produkter. For eksempel kunne en delvis taksonomi for websitet eventuelt se således ud:
Hvis der oprettes og benyttes en centraliseret taksonomi, er der intet gætværk forbundet med at foretage sammenkoblingen mellem indhold og produkter. Hvis alt indhold og alle produkter tildeles den rette plads i taksonomien, så vil brugere, der læser en artikel mærket ’styrtløb’ i højrespalten se produkter, der ligeledes er mærket ’styrtløb’.
Endvidere kan den samme taksonomi benyttes, hvis websitets ejere et år senere beslutter sig for, at de ønsker at indføre personificering. Man kan bede brugerne om at oprette et login-navn og vælge, hvilken slags indhold og produkter fra klassifikationslisten de benytter eller ønsker at lægge vægt på. Fordi det samme klassifikationssystem bruges i personifceringen og inddelingen af produkter og indhold, opstår der ingen rod. Brugere, der ønsker at se det nyeste snowboard-relaterede indhold og tilsvarende produkter, får alle elementer at se, der er mærket således.
En informationsarkitekt er nødt til at indsamle en masse oplysninger i løbet af et begrænset tidsrum ved brug af metoder som de følgende:
En anden interessant metode er en kortsorterings-øvelse. (se ’Kilder’ senere i denne artikel). Det går grundlæggende ud på at bede deltagerne om at gruppere samhørende begreber (et på hvert sit kort). Resultatet minder om et primitivt organisatorisk skema. Betragtet under ét kan en række af sådanne resultater udgøre grundlaget for den grundlæggende informationsarkitektur for et website.
Det er afgørende, at der ikke finder påvirkning sted under afprøvningen én til én. Informationsarkitekten må ikke diskutere deltagernes handlinger med dem. De må heller ikke rette deltagerne eller yde hjælp. Faktisk bør informationsarkitekten følge et manuskript. Deltagerne bør imidlertid have lov til at tale højt, mens de udfører testen, da oplysninger herfra kan give et godt billede ”bag kulisserne” af, hvordan de navigerer i deres eget konceptuelle rum.
Naturligvis handler jobbet som informationsarkitekt om andet end at indhente information. Informationsarkitekten skal også analysere denne information, syntetisere den, måske forkaste en masse af den, eller blot fokusere på visse dele af den. Og derefter skal han foretage en masse kvalificerede gæt – dette felt er på ingen måde styret af strenge videnskabelige retningslinier. Jesse James Garrett, en fremtrædende informationsarkitekt, siger, at nøglen til hans succes er gode gæt.
Informationsarkitektur er en proces, ikke et slutresultat. Mange websites går i luften med en foreløbig informationsarkitektur, struktur og organisering, der er ”god nok” for nuværende. Selv hvis man udtænkte en perfekt organisation af et website, ville den ikke holde i seks måneder, fordi noget ville ændre sig i løbet af den tid (brugernes behov, forretningsmål osv.), der ville gøre organiseringen begrebsmæssigt uholdbar.
Det bedste værktøj, en informationsarkitekt bringer med sig til opgaven, er et åbent sind. Han arbejder ikke med en fasttømret fortegnelse over maskindele. I stedet er arbejdsområde forbundet med noget langt mere uhåndgribeligt – konceptuelle rum. Det betyder, at man skal tumle med psykologi, kommunikationens natur og sprog (særligt semantik og pragmatik). Fordi så stor en del af arbejdet endvidere er stærkt indholdsorienteret, spiller lunerne forbundet med at finde, frembringe, forfine, producere og vedligeholde indholdet også ind som en faktor.
Fordi informationsarkitekten behersker det førnævnte opgaveområde, er det hans opgave at levere et indblik, at være idémæssig bannerfører. Beslutninger og anbefalinger indvirker ikke blot på den tekniske udvikling, men også på online-forretningspraksis. Hvis brugerne ikke er i stand til at finde det indhold, de har brug for, eller hvis de oplever et website som forvirrende, vender de ikke tilbage. Det kan skade indtægten og selskabets anseelse på markedet.
Mange softwareapplikationer lover at gøre meget (hvis ikke hele) af det arbejde, som informationsarkitkter udfører. Det vil sige forstå indhold og hvordan det kategoriseres, publiceres og håndteres. De fleste af disse værktøjer er rent ud sagt meget primitive, og de lever ikke op til deres potentiale. Dette skyldes primært dette arbejdes beskaffenhed: Menneskelige sprog (og konceptuelle rum) er svære at navigere i, og endnu sværere at rubricere i systemer og processer, der går igen.
Der er ikke plads nok til at diskutere hver eneste type værktøj/software, men forhåbentlig giver den følgende fortegnelse et overblik:
Content management-værktøjer forsøger at gøre arbejdet med at håndtere indhold lettere. Dybest set lader de grupper af personer, der producerer indhold, publicere og håndtere indhold (det være sig i flade filer, databasetabeller, eller begge dele). De fleste af disse værktøjer har imidlertid et ret overfladisk syn på, hvordan livscyklusen for et givet stykke content ser ud (det kan skyldes, at designere af sådanne systemer knap har gjort sig umage med at spørge folk, der arbejder med indholdsproduktion om, hvad deres job går ud på).
De fleste content management-systemer lader én oprette en stump indhold og jonglere rundt med det i en arbejdsgang. Afhængigt af systemet er arbejdsgange enten vanskelige eller lette at oprette og justere i henhold til aktuelle arbejdsgange i afdelingen. Selv de bedste content management-systemer tager ikke hensyn til andre problemer, der er centrale for produktionen af indhold. Såsom research, udarbejdning af kladder, kildebearbejdelse osv. De klarer heller ikke håndteringen af indhold efter publikationen særlig elegant.
Imidlertid betyder antallet af selskaber, der sælger content management-værktøjer, at konkurrencen måske vil føre til, at der i sidste instans kommer et system, som at værd at tage i brug. Min erfaring indtil nu er, at skræddersyede applikationer specifikt fremstillet til en bestemt gruppe personer baseret på open source-teknologier slår den præproducerede software hver eneste gang.
Ligeledes foregiver automatiske kategoriseringsværktøjer at lette besværet ved at kategorisere (tilskrive metadata) til store mængder indhold, såsom ’file repositories’, databasetabeller og selv emailarkiver. Nogle af disse værktøjer kan kun vanskeligt håndtere multimediefiler, billeder og selv komplekse dokumenter som Visio-diagrammer. Og de fatter stadig ikke betydningen af ord. De forstår ikke forskellen på verbet dukke og navneordet dukke. Ej heller formår de at klassificere dokumenter, der taler om øen Java, kaffesorten Java og programmeringssproget Java hver for sig.
De bedste automatiserede kategoriseringsværktøjer lader de personer, der betjener dem skride ind og foretage vurderinger. Et specialdesignet værktøj, som jeg var med til at udarbejde foreslog en liste af potentielle kategorier, som kunne hæftes på et stykke indhold baseret på input fra operatøren af værktøjet. Det var op til operatøren at vælge de rette kategorier fra listen, og hvis der ikke var nogen passende kategorier blandt forslagene, så at vælge fra den komplette fortegnelse.
En anden fremgangsmåde har været at lave værktøjer, der opretter og håndterer thesaurusser. En thesaurus er et informationssøgningsværktøj, der mere eller mindre gør det samme som en synonymordbog. For hvert udtryk i en fortegnelse over ord kan thesaurussen tydeliggøre mor/barn-forhold (hierarkiske spørgsmål) og pege på synonymer (alternative udtryk) og beslægtede udtryk (begreber, der ligger tæt op ad udtrykket). En vellavet thesaurus kan eliminere en stor del af frustrationen ved eftersøgning af information.
Hvis man for eksempel er ved at bygge et e-handelssite, der specialiserer sig i tøjsalg, kan en thesaurus forhindre, at brugerne river sig i håret af bar frustration, hver gang de søger efter ”blazere”, når man i sit system kalder dem for ”jakker”. Med en thesaurus kan man oprette ”blazer” som synonym for ”jakke” og det behørige søgeresultatet vises. På samme måde kan kunder, der ser på en bestemt jakke, i en højrespalte få vist bukser, der passer til en jakke takket være den indbyggede funktionalitet i thesaurssen med beslægtede udtryk.
Mange thesaurus-værktøjer fungerer, fordi de forener det bedste fra begge verdener. En menneskelig operatør får lov at gøre det, han er bedst til: Bruge sin fantastiske hjerne og uudtalte viden om et emneområde. Computeren gør også kun det, den er bedst til: Bruger sin omfattende regnekraft til at gnave sig igennem en masse arbejde i en fart.
Thomas Myer har arbejdet som skribent, multimedieudvikler, webudvikler og informationsarkitekt. Han har skrevet og designet til interaktive projekter for selskaber som Cisco Systems og Vignette og arbejder i øjeblikket som selvstændig konsulent og skribent. Han kan kontaktes på tom@myerman.com.