Use Cases: Vom Anwender her denken

Wer sich in wel­chem Umfeld auch immer als Tech­ni­k­re­dak­teur geoutet hat, kennt die Aus­sa­gen: „Hä? Anlei­tun­gen? Das lese ich nie! Da steht doch sowie­so nie das drin, was ich wis­sen möch­te.“ – Stimmt. Ich lese sie auch nie und ver­zweif­le oft dar­an, was die Kol­le­gen erstellt haben (oder erstel­len muss­ten). Oft habe ich den Ein­druck, dass kei­ner der Kol­le­gen jemals das Pro­dukt gese­hen oder bedient hat.

Um die pro­vo­ka­ti­ve Ein­lei­tung gleich wie­der abzu­schwä­chen: mir geht es häu­fig auch so, dass das Ergeb­nis mei­ner Tätig­keit nicht ganz mei­nen eige­nen Ansprü­chen genügt.¹ Das­sel­be gilt übri­gens auch für Koch­re­zep­te, denn selbst wer sich akri­bisch an die Rezept­vor­ga­ben hält, endet mit einem ande­ren Kuchen als ange­ge­ben.² Und so sieht es bei Doku­men­ta­tio­nen auch aus: Die abge­bil­de­te Soft­ware hat den But­ton nicht da, wo er angeb­lich ste­hen soll­te (und falls doch, dann heißt er anders), für das Ver­ständ­nis des Anlei­tungs­texts braucht man ein Infor­ma­tik­stu­di­um – und um ein Fahr­rad­rück­licht anzu­klem­men ist ein Spe­zi­al­werk­zeug erfor­der­lich.

Wie kommt es dazu?

Doku­men­ta­tio­nen die­ser Art sind Trau­er­spiel, bei dem beim Anwen­der die Frus­tra­ti­ons­gren­ze schnell über­schrit­ten ist, selbst wenn es der Tech­ni­k­re­dak­teur noch so gut mein­te. Er kann ja nichts dafür, wenn der Pro­dukt­ma­na­ger kurz vor der Aus­lie­fe­rung noch das Inter­face umstellt, weil ihm das bes­ser gefällt, wenn die Pro­gram­mie­rer den But­ton nach der Mit­tags­pau­se anders nen­nen als davor oder es über­haupt kei­ne Fest­le­gung gibt, wie das Bau­teil heißt, das beschrie­ben wer­den soll. Aber wie geht es dann erst dem Kun­den? Wen soll er fra­gen? Den Sup­port?

Vor die­sem Sze­na­rio schre­cken auch vie­le Tech­ni­k­re­dak­teu­re zurück und wursch­teln sich halt irgend­wie durch. Dann wer­den die Sei­ten­zah­len eben von Hand auf jede Sei­te gesetzt, der Kun­de nimmt statt des Spe­zi­al­werk­zeugs ein Taschen­mes­ser und das Rück­licht muss bis zur Ver­schrot­tung des Rads am Rah­men blei­ben…

Aber war­um? War­um haben die Leu­te, die das her­stel­len und beschrei­ben, so wenig Vor­stel­lung von der Ver­wen­dung und dem Gebrauchs­nut­zen des Pro­dukts?

Haben sie. Nur eine ganz ande­re Vor­stel­lung.

Kon­struk­teu­re, Ent­wick­ler und Pro­dukt­ver­ant­wort­li­che haben näm­lich (ver­ständ­li­cher­wei­se) jeweils eine ganz ande­re Sicht auf das Pro­dukt und müs­sen sich wäh­rend der Her­stel­lung ein­an­der annä­hern, um mög­lichst vie­le der jewei­li­gen Vor­stel­lun­gen zu berück­sich­ti­gen. Dum­mer­wei­se taucht der Anwen­der in die­ser Kon­stel­la­ti­on gar nicht auf – außer der Pro­dukt­lei­ter ist selbst Anwen­der.³ Wie aber kommt der Anwen­der ins Spiel? Man kann dem Kun­den ja schlecht noch vor dem Pro­duk­ti­ons­start ein paar Skiz­zen eines Staub­saugers vor­le­gen und dann von ihm ver­lan­gen, dass er dar­an erkennt, wie man den Beu­tel wech­selt. Und selbst Usa­bi­li­ty-Stu­di­en hel­fen hier nicht unbe­dingt wei­ter, denn ers­tens sind sie auf­wän­dig und zwei­tens benö­tigt man dazu bereits funk­tio­nie­ren­de Pro­to­ty­pen – ein immenser Kos­ten­fak­tor.

Es geht manch­mal mit noch weni­ger Auf­wand: Man benö­tigt Anwen­dungs­fäl­le – oder neu­deutsch: „Use cases“.

Ein Anwen­dungs­fall (engl. use case) bün­delt alle mög­li­chen Sze­na­ri­en, die ein­tre­ten kön­nen, wenn ein Akteur ver­sucht, mit Hil­fe des betrach­te­ten Sys­tems ein bestimm­tes fach­li­ches Ziel zu errei­chen. Er beschreibt, was inhalt­lich beim Ver­such der Ziel­er­rei­chung pas­sie­ren kann und abs­tra­hiert von kon­kre­ten tech­ni­schen Lösun­gen. Das Ergeb­nis des Anwen­dungs­falls kann ein Erfolg oder Fehlschlag/​Abbruch sein. (Wiki­pe­dia)

OMG!

Das klingt wesent­lich kom­pli­zier­ter als es ist: Man stellt sich die Fra­ge, was ein Anwen­der tun muss, um ein bestimm­tes Ziel zu errei­chen und wel­che Vor­aus­set­zun­gen erfüllt sein müs­sen.

Mehr nicht? – Nein, mehr nicht.

Die Kunst besteht nun dar­in, die Pro­zes­se (bei­spiels­wei­se den Ein­bau eines Fahr­rad­rück­lichts) so zu beschrei­ben, dass die Tätig­keit (das „Was tun?“) im Mit­tel­punkt steht – und nicht die Art und Wei­se (das „Wie macht man das?“).

Auf­tritt: Tech­ni­k­re­dak­teur

Eigent­lich sind Anwen­dungs­fäl­le unser All­tag, denn egal, ob wir in der Fer­ti­gungs­hal­le ste­hen und eine Wasch­ma­schi­ne inspi­zie­ren oder ob wir die Beta-Ver­si­on einer Soft­ware bekom­men: Wir spie­len dar­an her­um und ver­su­chen uns vor­zu­stel­len, was man damit eigent­lich macht und was man tun muss, dass es das tut, was wir errei­chen wol­len. Wir machen uns Gedan­ken dar­über, was der Anwen­der tun muss, um das Ergeb­nis zu erzie­len, für das er das Pro­dukt gekauft hat.

Bei Hard­ware ist das ja noch ein­fach: Bei einem Die­sel­ag­gre­gat sind die Anwen­dungs­fäl­le noch ver­gleichs­wei­se über­schau­bar. Eben­so bei einer elek­tri­schen Zahn­bürs­te oder einem Staub­sauger. Schwie­ri­ger wird es mit Soft­ware – und es ist erstaun­lich, zu wel­chen intel­lek­tu­el­len Sprün­gen man­che Anwen­der in der Lage sind, um eine Soft­ware so zu ver­wen­den, wie sich das ein Ent­wick­ler nie hät­te vor­stel­len kön­nen…

Wir brau­chen also einen neu­en Blick­win­kel: den des Anwen­ders

Ein­gen­or­det

Im Use case steht die Sicht Anwen­ders („Actor“) im Mit­tel­punkt. Er inter­agiert mit dem Sys­tem, um ein bestimm­tes Ziel zu errei­chen. Dazu führt er ein­deu­ti­ge Schrit­te durch und erhält mit­un­ter Rück­mel­dung vom Sys­tem. Ein Anwen­dungs­fall ist also eine Hand­lungs­ket­te, die vom Anwen­der durch­ge­führt wird und auf die das Sys­tem reagiert – am bes­ten erfolg­reich. Dazu müs­sen gege­be­nen­falls bestimm­te Start­kri­te­ri­en erfüllt sein. Unter­wegs gibt es mög­li­cher­wei­se Abbruch­kri­te­ri­en oder Optio­nen, die auch zum Ziel füh­ren. Und zum Schluss wird ein Ziel­zu­stand erreicht, an den ein neu­er Use case anschlie­ßen kann.⁴

Wie erstellt man denn nun einen Use case?

Die ein­schlä­gi­ge Lite­ra­tur macht einem unbe­darf­ten Tech­ni­k­re­dak­teur dazu das Leben mit Visua­li­sie­run­gen und Beschrei­bun­gen nicht gera­de ein­fach, da sie sich meist auf Geschäfts­pro­zes­se und Soft­ware­pro­zes­se bezieht, die der Tech­ni­k­re­dak­teur nor­ma­ler­wei­se immer nur als fer­ti­ges Ergeb­nis zu sehen bekommt. Hat er sich aller­dings selbst bereits eine Vor­la­ge ange­legt, ist auch der Tech­ni­k­re­dak­teur in der Lage, Schwach­stel­len in den Pro­zes­sen zu ent­de­cken, bevor er sie wort­reich kaschie­ren muss.

Eine Vor­la­ge besteht aus einer Glie­de­rung:

• Titel des Anwen­dungs­falls. Kann die­ser nicht ein­deu­tig beschrie­ben wer­den, ist er zu weit gefasst und man muss einen neu­en Anwen­dungs­fall dar­aus machen.
• Zusam­men­fas­sung („Sum­ma­ry“). In höchs­tens zwei Sät­zen wird das der Pro­zess beschrie­ben, um den es nun geht.
• Nor­ma­ler Ablauf („Basic cour­se of events“). Dies ist die Rei­hen­fol­ge der Schrit­te , die vom Anwen­der durch­ge­führt wer­den, und auf die das Sys­tem reagiert:
  1. Der Anwen­der wählt den Druck­be­fehl im Menü.
  2. Das Pro­gramm zeigt die Druck­op­tio­nen an.
  3. Der Anwen­der stellt die Papier­grö­ße und das Papier­for­mat ein.
  4. Das Pro­gramm zeigt ein Vor­schau­bild des Druck­ergeb­nis­ses mit der ein­ge­stell­ten Papier­grö­ße.
  5. …
• Alter­na­ti­ver Weg („Alter­na­ti­ve path“). In weni­gen Sät­zen wer­den eine oder meh­re­re Optio­nen umris­sen, die unter den glei­chen Aus­gangs­be­din­gun­gen zum glei­chen Ziel füh­ren.
• Abbruch­kri­te­ri­en („Excep­ti­on path“). In weni­gen Sät­zen wer­den die „Bruch­stel­len“ des Pro­zes­ses beschrie­ben, den den Anwen­der dazu brin­gen, den Pro­zess trotz iden­ti­scher Aus­gangs­be­din­gun­gen und Hand­lungs­schrit­te abzu­bre­chen. (Für den Druck eines Doku­ments ist Papier­stau ein Abbruch­kri­te­ri­um.)
• Vor­aus­set­zun­gen („Pre­con­di­ti­ons“). Wel­che Vor­aus­set­zun­gen müs­sen erfüllt sein, damit der Anwen­der den Pro­zess star­ten kann?
• Fol­gen („Post­con­di­ti­ons“). In weni­gen Sät­zen wird beschrie­ben, wel­che Pro­zes­se nun erfor­der­lich sind – oder auch nicht.

Das Ergeb­nis ist ein Sta­pel unter­schied­li­cher Anwen­dungs­fäl­le, die der Her­stel­ler im bes­ten Fall in der Pro­duk­ti­on berück­sich­tigt („Hopp­la! Da fehlt ein Absperr­ven­til!“) oder aber der Tech­ni­k­re­dak­teur als Schnitt­stel­le abfängt, indem er dem Anwen­der beschreibt, wie er sein Ziel trotz­dem errei­chen kann.

Pro­fis wer­den an der Glie­de­rung erkannt haben, dass es aus redak­tio­nel­ler Sicht natür­lich bes­ser ist, die Vor­aus­set­zun­gen vor der Durch­füh­rung zu erwäh­nen. Aller­dings han­delt es sich um einen Use case, nicht um ein Hand­buch, das 1:1 so wei­ter­ge­ge­ben wer­den kann. Im Gegen­teil: Ein Tech­ni­k­re­dak­teur, der bereits vor dem „Schrei­ben“ der Doku­men­ta­ti­on die Zeit und das Hirn­schmalz inves­tiert hat, eine Samm­lung der Anwen­dungs­fäl­le anzu­le­gen, greift wesent­lich tie­fer in das Infor­ma­ti­ons­netz des Pro­dukts ein, denn er kann auch den Pro­dukt­ver­ant­wort­li­chen kom­mu­ni­zie­ren, dass mög­li­cher­wei­se man­che Hand­lun­gen unnö­tig kom­plex oder gar unmög­lich sind.

Ana­lo­gie

Im Grun­de genom­men sind Anwen­dungs­fäl­le die Sze­nen eines Stücks, die sinn­voll inein­an­der grei­fen müs­sen, ohne dass der Zuschau­er und die Dar­stel­ler den Faden ver­lie­ren. Die Scripts der Sze­nen ent­ste­hen aus der engen Zusam­men­ar­beit mit den Pro­dukt­ver­ant­wort­li­chen und ‑erstel­lern. Und dabei steht auch mal der Tech­ni­k­re­dak­teur als Dreh- und Angel­punkt der Pro­dukt­ent­wick­lung im Mit­tel­punkt…

1. Im Lau­fe der Zeit stellt sich das so genann­te „Pare­to-Opti­mum“ ein, bei dem es inner­halb der vor­ge­ge­be­nen Zeit nicht mög­lich ist, die Doku­men­ta­ti­on zu ver­bes­sern, ohne einen Mehr­auf­wand zu betrei­ben, der nicht bezahlt wird. ↩

2. Das ist auch der Grund für die Back­mi­schun­gen, die sozu­sa­gen den kleins­ten gemein­sa­men Nen­ner dar­stel­len: man muss nichts kön­nen, noch nicht ein­mal schme­cken. ↩

3. Aber selbst dann reprä­sen­tiert er ver­mut­lich auf­grund sei­ner Kennt­nis­se nicht den durch­schnitt­li­chen Anwen­der. ↩

4. Für den Tech­ni­k­re­dak­teur klingt das ziem­lich ver­traut, denn er baut Instand­hal­tungs- oder Mon­ta­ge­an­lei­tun­gen idea­ler­wei­se immer so auf. Lei­der blei­ben die­se Erkennt­nis­se den Pro­dukt­ver­ant­wort­li­chen oft ver­bor­gen, solan­ge sie nicht die Doku­men­ta­ti­on lesen. ↩