Tesugen

Den senaste tiden har jag läst lite om informationsarkitektur och hur detta inte tas tillräcklig hänsyn till i utvecklingsprojekt. Det hävdas ofta att detta ses som något som kan göras i ett sent skede och av personer utan någon särskild skolning i, eller erfarenhet av informationsarkitektur. Detta är något jag verkligen håller med om och jag sympatiserar med idén att informationsarkitekter behövs i sådana projekt – men det är ändå något jag tycker saknas i argumentationen. Jonas Söderström har skrivit en artikel som jag tycker är väldigt bra, men den är också ett exempel på detta som jag tycker saknas.

Jonas skriver att IT-industrin “i snart 50 år […] konsekvent [har] misslyckats med att leverera produkter i tid och inom budget, eller inte lyckats leverera den förväntade funktionaliteten”. Han fortsätter: “Branschen har länge avundsjukt tittat på byggbranschen, som oftast lyckats leverera fungerande hus i tid.” Jag vet inte om jag tolkar Jonas fel, men jag får intrycket att han menar att problemet är att det inte finns någon informationsarkitekt – någon som fokuserar på “gränssnittet i sin helhet: form, informationsdesign, interaktion” (se artikeln för definitioner av dessa).

Vidare skriver Jonas, och han undrar om han är orättvis när han gör det, att titeln arkitekt används flitigt i andra avseenden: “asp-arkitekt, databasarkitekt, eller javaarkitekt” – och undrar om det inte bara är ett sätt att markera vilka som har längst erfarenhet. När han säger att sådana arkitekter är personer som bara “sätter sig ner och tänker en stund, innan hon börjar programmera” – då tycker jag verkligen att han är orättvis.

Källkod är information som i allra högsta grad är i behov av en arkitektur, av flera olika anledningar. Den i mitt tycke viktigaste anledningen – och som jag tycker inte betonas tillräckligt – är att källkoden behöver vara strukturerad så att användaren av den, dvs. programmeraren, lätt kan orientera sig. Jonas är inte den ende jag har sett som har avfärdat detta arbete som att “hacka kod”. Jag tror att det är viktigt att skapa förståelse för varandras discipliner.

Bara för att ett gränssnitt har en utmärkt informationsarkitektur så betyder inte det att koden bakom kan vara hur svinig som helst. Dålig kod ger en dålig “user experience” om det ofta uppstår fel. Dessutom måste informationsarkitekturen “mappa” väl mot den interna arkitekturen för att överhuvudtaget fungera.

När jag läser Jonas artikel får jag en känsla av att synen är att informationsarkitekten gör sitt arbete uteslutande i inledningen av projektet – en känsla jag fått även av andra informationsarkitekters texter. År det någon trend som är tydlig inom systemutveckling så är det den som går mot att driva projekten inkrementellt och iterativt: dvs. att det inte först görs ett analysarbete, följt av design, följt av implementation, test, dokumentation och leverans. Istället är det en cykel där man gör allt detta i korta iterationer och inte nödvändigtvis sekventiellt.

Jag tror att informationsarkitekterna måste anpassa sig till den iterativa, inkrementella processen, så att gränssnittet kan “utvecklas evolutionärt” under projektets gång – och samtidigt bibehålla sin integritet. Dessutom måste man acceptera det faktum att problemområdet är långt ifrån kristallklart i begynnelsen av ett projekt, och att projektet till stor del handlar om att lära sig om problemområdet och söka effektiva lösningar.

I denna process är det viktigt med nära samarbete mellan kund, informationsarkitekt och utvecklare. Informationsarkitekten kan förutom från kunden få väldigt värdefull information från utvecklarna, i form av att dessa upptäcker nya möjligheter för gränssnittet utifrån sin kunskap om systemets interna möjligheter. (Det omvända är givetvis också sant – dvs. att utvecklarna upptäcker möjliga lösningar utifrån de idéer informationsarkitekten har.)

Den interna arkitekturen är lika mycket en funktion av gränssnittets arkitektur, som den interna är en funktion av gränssnittets. Oförutsedda möjligheter i den ena kan och bör skapa möjligheter i den andra. Den bästa informationsarkitekturen för ett givet system är det som uppstår i en miljö där alla – informationsarkitekter, utvecklare, projektledare, testare, framtida användare, beställare – är öppna för det de lär sig under arbetets gång. Detta förutsätter en cyklisk, inkrementell process där man tänker, skapar och tänker igen efter att ha “känt” på det man har skapat. En process driven av återkoppling.

Jag kan absolut tänka mig en fjärde cirkel i Jonas blomma, innehållande systemarkitektur, eller intern arkitektur. Den interna arkitekturen är i allra högsta grad en del av helheten. Utan den ingen interaktion; ingen sammanställning av data till information att presenteras, osv.

The above was posted to my personal weblog on May 2, 2003. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)
Bloggtoppen.se