Interaktionsdesign vs agil utveckling
Published: mars 12, 2009
Tags: artiklar
A list apart har legat i min bokmärkesmapp sen strax innan 2000-talet och har alltid lyckats leverera artiklar som är välskrivna, intressanta och högst relevanta med det jag har arbetat med. Dags att introducera a list apart här på Metamatrix för de som inte känner till den. Så jag tipsar om två brännheta artiklar, den första om interaktionsarkitektur och den andra om agil design.
Informationsarkitektur betyder mycket för de projekt vi genomför, det hjälper oss att sätta den övergripande sturkturen till hur en artefakt ska se ut i grova grad, att bestämma krav till att hjälpa våra utvecklare att förverkliga det vi har tänkt. Men hur lämnar vi över detta till våra kunder? Hjälper vi dem att se nyttan med det sättet vi arbetar? Och är det inte vårt uppdrag att lära kunderna hur de själva kan arbeta vidare med detta?
Läs mer på http://www.alistapart.com/articles/flexiblefueleducatingtheclientonia
Agil utveckling och design, är det något som kan verka ihop på ett bättre sätt? Artikelförfattaren ger några exempel på hur och varför det är möjligt. Design är agil i sin grund och nu är det dags att visa att vi även kan arbeta så löpande. Egentligen så borde agil utveckling omfamnas av designers då det ger ett enkelt verktyg att testa om designen är rätt. Men det finns en rädsla och ett motstånd bland designers, kan det bero på en av den agila utvecklingens grunder, att inte koda förrän kunden har godkänt den funktionen? Och då att en icke-färdig version inte kan förmedla det flöde som designern har tänkt och skissat på sina papper. Sedan kan det vara som så att det kan ta längre än en sprint/iteration att designa en viss specifik sak.
Allt detta är högst relevant och det hela kan kanske kopplas till det som har varit en nackdel med det som kallats agil design. Nackdelen är att en agil design där man inte ska göra mer än kuden säger tenderar till att bli minimalistisk som i kommande iterationer gör det svårare att bygga om gränssnittet, för gränssnitt och flöden är inte lika lätta att refaktorera som kod. Detta är även något som Larry Constantine tänkt på och skrivit ett väl läsvärt paper där han även föreslår en liten metod öfr att lösa det hela.
Men agil design kan även tvinga utvecklare att arbeta på det sätt de alltid har sagt att de arbetat på med skiktade lösningar et. Detta tog t ex Eric Idebro och Illugi Ljótsson upp på ett kort seminarium på WUD förra året, nu saknas just deras presentation från det året. Tanken är att en design som kan behövas ändras i såväl utseende som flöde tvingar utvecklarna att koda rätt redan från början så att koden blir oberoende av arbetsflöde för användarna.
Läs mer på http://www.alistapart.com/articles/gettingrealaboutagiledesign