Im Activity Design wird die Funk­tio­na­li­tät eines neuen Sys­tems ent­wor­fen. Die zen­trale Frage in die­ser Phase lau­tet: Was kann man mit dem neuen Sys­tem machen?  Ideen zu Kon­zept und Funk­tio­na­li­tät des neuen Sys­tem wer­den in Nut­zungs­ge­schich­ten (activity sce­na­rios) “aus­pro­biert” — immer mit dem Ziel effek­tive, ver­ständ­li­che und zufrie­den­stel­lende Akti­vi­tä­ten ent­wer­fen. Die Gra­fik zeigt die Phase des Activity Design im Überblick:

Im Activity ist fol­gen­des Vor­ge­hen vorgegeben:

1) Aus­gangs­punkt
Aus­gangs­punkt bil­den die Pro­blem­sze­na­rien, sowie die Vor– und Nach­teile (claims) der beschrie­be­nen Situa­tio­nen. Bei der Gestal­tung eines neuen Sys­tem möchte man die posi­ti­ven Aspekte bei­be­hal­ten und gleich­zei­tig die nega­ti­ven Aspekte der Situa­tion mini­mie­ren. Man steht also vor der Frage: Wel­che Auf­ga­ben und Ziele der Akteure können/sollen durch ein Sys­tem unter­stützt wer­den? Wel­che bes­ser nicht?

Dis­kus­sion im Team, Brain­stor­ming, keine ein­ge­schränkt sicht — offen sein für alles, gestal­tung­spiel­raum ausloten

2) Ideen sam­meln
Mit­tels Brain­stor­ming und Dis­kus­sion im Team wer­den weit­räu­mig Ideen für die Gestal­tung der Funk­ti­on­litä­ten des neuen Sys­tems gesam­melt. Wich­tig ist es nicht zu stark an der aktu­el­len Situa­tion zu ori­en­tie­ren, son­dern viel­fäl­tige Gestal­tung­mög­lich­kei­ten in Erwä­gung zu zie­hen. Im Scenario-based Design Pro­zess wer­den haupt­säch­lich zwei Stra­te­gien für die Ide­en­fin­dung beschrieben:

• Meta­pho­ri­sches Brain­stor­ming: Offen­sicht­li­che oder unge­wöhn­li­che Ana­lo­gien zwi­schen rea­len Aktivitäten/Handlungen und Funk­tio­na­li­tä­ten eines Sys­tems her­stel­len. (Was wäre wenn ? Akti­vi­tät? wäre wie … Met­ha­pher ??)
• Zur Ver­fü­gung ste­hen­den Tech­no­lo­gien betrach­ten: Mög­lich­kei­ten, die sich durch bereits beste­hende Tech­no­lo­gien ergeben

In die Ide­en­fin­dung fließt eben­falls Basis­wis­sen aus dem Bereich Human Com­pu­ter Inter­ac­tion mit ein, hier spe­zi­ell zur Gestal­tung von Systemfunktionalitäten.

3) Ideen aus­pro­bie­ren und abwä­gen
Die Ideen für das grund­le­gende Kon­zept und die Funk­tio­na­li­tä­ten eines neuen Sys­tems wer­den in nar­ra­ti­ver Form aus­ge­ar­bei­tet. Dafür wer­den die Pro­blem­se­ze­na­rien in Activity Sze­na­rien umge­formt: Die Geschich­ten beschrei­ben jetzt, wie die Funk­tio­nen des neuen Sys­tems die Akteure und ihre Ziele unter­stüt­zen, bzw. wie sich die Situa­tion dadurch ver­än­dert. Auf diese Weise kann man neue Ideen in einer rea­lis­ti­schen Situa­tion tes­ten, ohne die Bedürf­nisse und das Erleb­nis der Nut­zer aus den Augen zu verlieren.

Eng ver­bun­den mit dem Schrei­ben der Activity Sze­na­rien wer­den die Vor– und Nach­teile der Vor­schläge betrach­tet. Mit­tels Claims Ana­ly­sis iden­ti­fi­ziert man die wesent­li­chen Merk­male des Activity Designs, und lis­tet die mög­li­chen posi­ti­ven und nega­ti­ven Aus­wir­kun­gen auf.

4) Ideen ver­fei­nern
Im Sce­na­rio Based Design Pro­zess sollte fort­wäh­rend ite­ra­tiv gear­bei­tet wer­den.
Activity Sze­na­rien und Claims wer­fen Fra­gen auf (“Was wäre, wenn ?”) wel­che im Team dis­ku­tiert wer­den soll­ten — die dar­aus enste­hen­den Ände­run­gen und neuen Ideen wer­den wie­derum in Activity Sze­na­rien umge­setzt und mit Claims Ana­ly­sis evaluiert.

Fol­gende Metho­den kön­nen außer­dem ange­wandt wer­den um die Details der Activity Sze­na­rien auszufeilen:

• Per­so­ni­fi­ka­tion wich­ti­ger Sys­te­m­ele­mente (POV ana­ly­sis) : Dabei nimmt man die Rolle eines Sys­te­m­ele­ments ein und stellt fol­gende Über­le­gung an: “Wenn ich ? Sys­te­m­ele­ment ? wäre, was könnte ich tun um nütz­lich zu sein?

• Par­ti­zi­pa­tive Gestal­tung mit Nut­zern: gemein­sam mit Nut­zern Aci­ti­vity Sze­na­rien ent­wer­fen und Claims Ana­ly­sis durchführen

(Beschrie­ben nach Rosson & Car­roll 2002, sowie Rosson & Car­roll 2003 )

—————————————————————————————————-

Warum beschränkt man sich im Activity Design auf die Funk­tio­na­li­tät?
In Activity Sze­na­rien beschränkt man sich zunächst dar­auf, zu beschrei­ben, wel­che Akti­vi­tä­ten die Akteure mit den Sys­tem aus­füh­ren — Aus­se­hen und Bedie­nung des neuen Sys­tems wer­den erst in den nächs­ten Pha­sen (Infor­ma­tion Design, Inter­ac­tion Design) ausgearbeitet.

Der Grund dafür: Man stellt die Bedürf­nisse der Nut­zer an erste Stelle. Ziel ist es die­sen Bedürf­nis­sen durch geeig­nete Funk­tio­na­li­tä­ten gerecht zu wer­den. Des­halb kon­zen­triert man sich in der Anfangs­phase der Ent­wick­lung eines Sys­tems auf das “was” und “warum”, ohne sich durch die Detail­fra­gen des “wie genau” ein­schrän­ken zu las­sen. Die­ses Vor­ge­hen führt auch dazu, dass schnel­ler For­schritte in der Ent­wick­lung sicht­bar werden.

Rosson & Car­roll (2002, S. 81) beschrei­ben dies wie folgt:

“(?) By con­side­ring sys­tem func­tio­na­lity first, desi­gners can make pro­gress more quickly — they can focus on what a sys­tem will do, and not worry about how at the same time (Con­stan­tine & Lock­wood 1999). It is hard to to ana­lyze user inter­face needs and choose appro­priate dis­plays and inter­ac­tion tech­ni­ques when you do not yet know what a sys­tem will do (and why). (?)

(?) But most import­antly, it rein­forces the cen­tral goal of desi­gning activi­ties that users will find effec­tive, com­pre­hen­si­ble, and satisfying. (?)”