Mats Berglind om RUP-dokumentation av användbarhet
Härom kvällen pratade Mats Berglind om hur han dokumenterar interaktionsdesign i RUP-projekt han jobbat i, främst hos ett par storbanker.
Att dokumentera användbarhet var kanske en torr rubrik på STIMDI-seminariet, den lockade i alla fall bara ett tjog åhörare, men jag kommer nog att ha nytta av det i mitt nuvarande RUP-projekt. Det är alltid nyttigt att se exempel, framförallt som vi behöver skriva specar på två eller tre olika ambitionsnivåer.
Det slog mig i alla fall tydligt att jag till skillnad från Mats aldrig jobbat med RUP direkt ur kartongen. Det har alltid funnits en usability architect-roll definierad, eller så har jag kunnat skapa det utrymmet. Jag är tacksam för det; att vara ren UI designer låter lite begränsat.
Följaktligen hade Mats också skapat lite nya och förändrade artefakter för att få ihop det. Han kallade sitt angreppsätt för en use case-centric approach.
Han använde själva användningsfallet (Use Case) för att dokumentera designen, men jag är tveksam till den lösningen. Jag föredrar att ha ett separat dokument som paras ihop med användningsfallet. Båda är kravdokument, men då kan man frysa dem oberoende av varandra. Och med tanke på uppdateringseländet som brukar råda både före och efter dokumentfrysning är det smidigt att ha den möjligheten.
--
En kul synkronicitet var att han nämnde att han använt surveymonkey för att göra en snabb enkät bland programmerarna på ett projekt. Samma dag hade jag påbörjat min första enkät i verktyget och jag blev imponerad av hur långt jag hann komma på en kvart. Mats gillade också surveymonkey, och programmerarna gillade hans specar.
--
Ett exempel på en aktuell enkät gjord av surveymonkey är vår pågående undersökning om vardagsresande som vi gör inför världsanvändbarhetsdagen om en vecka. Svara gärna på den.
Att dokumentera användbarhet var kanske en torr rubrik på STIMDI-seminariet, den lockade i alla fall bara ett tjog åhörare, men jag kommer nog att ha nytta av det i mitt nuvarande RUP-projekt. Det är alltid nyttigt att se exempel, framförallt som vi behöver skriva specar på två eller tre olika ambitionsnivåer.
Det slog mig i alla fall tydligt att jag till skillnad från Mats aldrig jobbat med RUP direkt ur kartongen. Det har alltid funnits en usability architect-roll definierad, eller så har jag kunnat skapa det utrymmet. Jag är tacksam för det; att vara ren UI designer låter lite begränsat.
Följaktligen hade Mats också skapat lite nya och förändrade artefakter för att få ihop det. Han kallade sitt angreppsätt för en use case-centric approach.
- Navigational map var en översikt i hur olika användningsfall hänger ihop. Med hans webbankexempel där ett användningsfall i stort sett verkar motsvara en sida blev det väldigt likt en sajtkarta. Smidigt! Jag misstänker dock att det kräver ganska små modulära användningsfall för att det ska fungera bra.
- I ett UI Guidelines-dokument samlade han designmönster men också affärsregler som formatteringsregler för olika typer av inputvariabler.
Han använde själva användningsfallet (Use Case) för att dokumentera designen, men jag är tveksam till den lösningen. Jag föredrar att ha ett separat dokument som paras ihop med användningsfallet. Båda är kravdokument, men då kan man frysa dem oberoende av varandra. Och med tanke på uppdateringseländet som brukar råda både före och efter dokumentfrysning är det smidigt att ha den möjligheten.
--
En kul synkronicitet var att han nämnde att han använt surveymonkey för att göra en snabb enkät bland programmerarna på ett projekt. Samma dag hade jag påbörjat min första enkät i verktyget och jag blev imponerad av hur långt jag hann komma på en kvart. Mats gillade också surveymonkey, och programmerarna gillade hans specar.
--
Ett exempel på en aktuell enkät gjord av surveymonkey är vår pågående undersökning om vardagsresande som vi gör inför världsanvändbarhetsdagen om en vecka. Svara gärna på den.
2 Kommentarer:
Vill bara kommentara "Han använde själva användningsfallet (Use Case) för att dokumentera designen, men jag är tveksam till den lösningen."
Anledningen till att jag gjort detta är enkel. Användarna av Use Casen (utvecklare och testare) ville ha det så.
> Användarna av Use Casen (utvecklare och testare) ville ha det så.
Och det är en *mycket* bra anledning. :-)
I de projekt där jag jobbat med RUP har det oftast handlat om betydligt mer invecklade användningsfall, där bara själva kravinsamlingen krävt en hel del jobb för att bli klar. Att dessutom blanda in lösningsberoende design i samma dokument skulle göra dokumenten och framförallt uppdateringsprocesserna allt för tunga.
Skicka en kommentar
<< Tillbaka