Kein blicK zu­rücK

Mo­der­ne User Ex­pe­ri­ence vs. Be­stands­soft­ware

SCREENGUIDE - - Best Practices - TEXT: Micha­el Jen­dry­schik

Mo­der­ne User Ex­pe­ri­ence (UX) ent­steht nicht, wenn Ent­wick­ler exis­tie­ren­de Lö­sun­gen in neue De­signs gie­ßen. Des­we­gen in­ter­es­sie­ren sich die UX En­gi­neers von Ma­xim­a­go zu Be­ginn ei­nes Pro­jekts über­haupt nicht für die Be­stands­soft­ware.

In Pro­jek­ten küm­mern sich zu­nächst Re­qui­re­ments En­gi­neers um ei­ne An­for­de­rungs­ana­ly­se. Da­bei grei­fen sie auf drei Ar­ten von In­for­ma­ti­ons­quel­len zu: Sta­ke­hol­der, Do­ku­men­te und Be­stands­sys­te­me. Sta­ke­hol­der sind Per­so­nen, die Ein­fluss auf An­for­de­run­gen ha­ben, bei­spiels­wei­se Fach­ex­per­ten oder Nut­zer. Re­le­van­te Do­ku­men­te sind et­wa An­for­de­rungs­do­ku­men­te und Feh­ler­be­rich­te des Be­stands­sys­tems, aber auch Nor­men und Ge­set­zes­tex­te. Be­stands­sys­te­me sind Vor­gän­ger- oder Kon­kur­renz­sys­te­me. Re­qui­re­ments En­gi­neers er­war­ten, in der Ana­ly­se von Be­stands­sys­te­men und Do­ku­men­ten Lö­sun­gen für ei­ne neue An­wen­dung – ei­ne neue App, ei­ne Web­site, ein Shop-Sys­tem oder ei­ne B2BSoft­ware – zu fin­den. Die­se Ar­beits­wei­se führt aber oft in ei­ne Sack­gas­se, da sie im schlimms­ten Fall be­reits be­gan­ge­ne Feh­ler wei­ter­ent­wi­ckelt. Un­se­re UX En­gi­neers von Ma­xim­a­go ha­ben sich des­halb von die­sem Weg ver­ab­schie­det: Wir in­ter­es­sie­ren uns in der ers­ten Pha­se nicht für Be­stands­sys­tem und Do­ku­men­ta­ti­on, wol­len Pflich­ten­heft und An­for­de­rungs­do­ku­men­te nicht se­hen.

WAR­UM PRO­JEK­TE BE­REITS BEI DER ANFORDERUNGSERHEBUNG SCHEI­TERN

Er­folg­rei­che Soft­ware hilft Kun­den, ih­re un­ter­neh­me­ri­schen Zie­le zu er­rei­chen: Ent­we­der direkt oder als Teil ei­ner Ge­samt­lö­sung, die den Kun­den der Kun­den wei­ter­hilft. Des­halb muss der Nut­zungs­kon­text al­len Teil­neh­mern des Ent­wick­lungs­pro­zes­ses klar sein. Wir fra­gen uns, wel­che Funk­ti­on ei­nen ech­ten Nut­zen hat. Sie muss im Nut­zungs­kon­text ein­deu­tig be­grün­det sein, denn feh­len­de oder über­flüs­si­ge Funk­tio­nen be­hin­dern und über­for­dern den Nut­zer – das ge­fähr­det un­ter­neh­me­ri­sche Zie­le. Die­ser Nut­zungs­kon­text kann aus dem Alt­sys­tem oft nur schwer her­aus­ge­le­sen wer­den, weil es nur aus Lö­sun­gen be­steht – gu­ten und schlech­ten. In der eta­blier­ten Ar­beits­wei­se hat sich ge­zeigt, dass sich De­si­gner und Ent­wick­ler an die­sen Lö­sun­gen ori­en­tie­ren, so­bald sie sie ken­nen. Da­durch ent­ste­hen nur sel­ten neue in­no­va­ti­ve Lö­sun­gen. Des­halb in­ter­es­sie­ren sich UX En­gi­neers

in der Ana­ly­se nicht für Lö­sun­gen, son­dern nur für Pro­ble­me in Form von Zie­len und Auf­ga­ben so­wie tat­säch­li­chen An­for­de­run­gen der Nut­zer, die den Ent­wick­lungs­pro­zess an­trei­ben wer­den. Der UX En­gi­neer hin­ter­fragt ge­mein­sam mit dem Kun­den et­wa, ob ei­ne Such­funk­ti­on nö­tig ist, die fast je­de An­wen­dung bie­tet. War­um soll­te der Kun­de die­se Funk­ti­on auch auf sei­ner Web­site oder in sei­ner An­wen­dung an­bie­ten, gibt es da­für ei­nen Grund? „Der Nut­zer braucht die Su­che, um …” Ja, um was? Weil sie je­der bie­tet oder weil das Pro­gramm nicht die rich­ti­ge Funk­ti­on zum rich­ti­gen Mo­ment in­tui­tiv an­bie­tet? Dass sich nutz­lo­se Funk­tio­nen in An­wen­dun­gen ein­schlei­chen, hat meist ei­nen der drei fol­gen­den Grün­de: • Der Maß­stab sind Kon­kur­renz­lö­sun­gen: Funk­tio­nen wer­den ko­piert, oh­ne den Nut­zen zu hin­ter­fra­gen. Vie­le On­li­ne-Shops se­hen zum Bei­spiel wie Ama­zon aus und funk­tio­nie­ren ge­nau­so. In Be­zug auf Selbst­be­schrei­bungs­fä­hig­keit und Er­war­tungs­kon­for­mi­tät ist die Ko­pie schein­bar ei­ne gu­te Lö­sung. Aber ist die Lö­sung ei­nes Markt­füh­rers sinn­voll für ei­nen On­li­ne-Shop, der le­dig­lich ein Ni­schen­pu­bli­kum be­dient? • Es wur­den die fal­schen Sta­ke­hol­der be­fragt: Sta­ke­hol­der hal­ten sich häu­fig für die Re­prä­sen­tan­ten der Nut­zer, aber sie ge­hö­ren oft nicht zur ech­ten Be­nut­zer­grup­pe oder sind fach­lich vor­be­las­tet. Des­we­gen fällt es ih­nen schwer, va­li­de Aus­sa­gen zur Nut­zung zu tref­fen: Der Ver­triebs­mit­ar­bei­ter ei­nes Sen­so­ren­her­stel­lers be­trach­tet die An­wen­dung ei­nes Mit­be­wer­bers ganz an­ders als der Tech­ni­ker, der mit der Sen­so­ren­soft­ware Lecks in sei­ner Pro­duk­ti­ons­an­la­ge sucht. • Es wur­den die rich­ti­gen Sta­ke­hol­der mit den fal­schen Fra­gen be­fragt: Er­fah­re­ne UX En­gi­neers hal­ten sich sehr lan­ge im Pro­blem­raum auf und ver­wen­den viel Zeit auf die Ana­ly­se, um zum Kern des Pro­blems vor­zu­drin­gen. Da­zu be­ob­ach­ten und be­fra­gen sie die Nut­zer. Die UX En­gi­neers ge­hen aber nie­mals so weit, den Nut­zer nach Wün­schen zu fra­gen oder um Lö­sun­gen zu bit­ten. Denn da­zu ist der Nut­zer meist nicht in der La­ge, weil er das Pro­blem nicht un­ab­hän­gig und un­be­fan­gen von der be­ste­hen­den Lö­sung be­trach­ten kann. Da­her müs­sen UX En­gi­neers Be­stands­sys­te­men im­mer skep­tisch be­geg­nen und sich auf die Er­mitt­lung des Nut­zungs­kon­tex­tes kon­zen­trie­ren. Denn dar­aus las­sen sich die tat­säch­li­chen Nut­zungs­an­for­de­run­gen ab­lei­ten.

EIN NEU­ER WEG DER ANWENDUNGSENTWICKLUNG

Die Grund­la­ge un­se­rer Pro­jek­te ist die Nut­zer­per­spek­ti­ve, sie ist mit­ent­schei­dend für den Er­folg ei­nes Un­ter­neh­mens. Des­halb bin­den wir un­se­ren Kun­den be­reits von Pro­jekt­be­ginn an ein: Am An­fang ste­hen Ana­ly­se, Do­ku­men­ta­ti­on und Prü­fung der Pro­dukt­stra­te­gie, des Nut­zungs­kon­tex­tes und der Er­for­der­nis­se. Un­se­re Vor­ge­hens­wei­se glie­dert sich in fol­gen­de Ab­schnit­te: • Her­aus­ar­bei­ten der Un­ter­neh­mens­per­spek­ti­ve und der sich

dar­aus er­ge­ben­den Zie­le • Iden­ti­fi­zie­rung der Nut­zer­per­spek­ti­ve, der Zie­le und nö­ti­gen

Zwi­schen­zie­le in der Wert­schöp­fungs­ket­te des Kun­den • Syn­chro­ni­sie­rung der Per­spek­ti­ven an­hand von kon­kre­ten Mo

ti­va­ti­ons­tech­ni­ken Häu­fig lie­gen die­se In­for­ma­tio­nen be­reits vor, al­ler­dings nicht bei je­dem. Um die­se In­for­ma­tio­nen al­len zu­gäng­lich zu ma­chen, be­gin­nen wir das Pro­jekt mit ei­nem Work­shop. Re­le­van­te Teil­neh­mer sind da­bei das Ma­nage­ment, das die über­ge­ord­ne­ten Zie­le und ope­ra­ti­ven Maß­nah­men kennt; Mar­ke­ting und Pro­dukt­ma­nage­ment, Ver­trieb, Sup­port und Ent­wick­ler, um die Mach­bar­keit fest­zu­stel­len. Und na­tür­lich ech­te Nut­zer, um die Ker­n­an­for­de­run­gen zu er­mit­teln. Am Work­shop soll­ten min­des­tens drei, bes­ser vier oder mehr Per­so­nen teil­neh­men, da­mit aus­rei­chend Ex­per­ti­se an ei­nem Tisch sitzt, aber im­mer noch aus­führ­li­che Dis­kus­sio­nen mög­lich sind. Falls ein Work­shop sechs Per­so­nen über­stei­gen wür­de, tei­len wir ihn auf meh­re­re Ta­ge und Grup­pen auf, um ef­fi­zi­ent zu ar­bei­ten. In die­sem bei Be­darf mehr­tä­gi­gen Work­shop dis­ku­tie­ren die Teil­neh­mer et­wa fol­gen­de Fra­gen: • Was ist die Funk­ti­ons­vi­si­on in ei­nem Satz? • Wer pro­fi­tiert da­von? • War­um ist noch nicht je­der po­ten­zi­el­le Kun­de be­reits Kun­de? • Was sind die zu­künf­ti­gen Ziel­seg­men­te und war­um? • Wie las­sen sich die Be­nut­zer­grup­pen cha­rak­te­ri­sie­ren? • Wel­che An­wen­dungs­fäl­le gibt es in je­dem Sze­na­rio? • Was sind die Aus­lö­ser und Zie­le der An­wen­dungs­fäl­le? • Wel­che Schrit­te durch­läuft der Be­nut­zer? • Wie läuft die Zu­sam­men­ar­beit ver­schie­de­ner Be­nut­zer ab? Als Er­geb­nis er­hal­ten wir ei­ne voll­stän­di­ge und va­li­dier­te Nut­zungs­kon­text­be­schrei­bung und da­mit un­ter an­de­rem • In­for­ma­tio­nen über Pro­dukt­vi­si­on und Wert­schöp­fungs­ket­te; • die (ver­schie­de­nen) Be­nut­zer­grup­pen der An­wen­dung so­wie • de­ren Zie­le, Ar­beits­auf­ga­ben und Auf­ga­ben­ab­fol­gen; • für je­de Nut­zungs­an­for­de­rung ei­ne Be­grün­dung aus Be­nut­zer

sicht in Form ei­nes oder meh­re­rer Er­for­der­nis­se; • In­for­ma­tio­nen über die Rah­men­be­din­gun­gen, un­ter de­nen das Sys­tem ein­ge­setzt wird, dar­un­ter Schnitt­stel­len zu vor­an­ge­hen­den und nach­ge­la­ger­ten Pro­zes­sen; • ei­ne Grund­la­ge für die wei­te­ren Ar­beits­schrit­te im Pro­jekt­ver­lauf, vor al­lem na­tür­lich für die Kon­zep­ti­on; • ei­ne pro­fes­sio­nel­le Ba­sis für die An­ge­bots­er­stel­lung. Un­ab­ding­ba­re Vor­aus­set­zung da­für ist die Be­reit­schaft, dass al­le Rol­len ih­ren Teil bei­tra­gen und sich of­fen auf ei­nen frei­en und von al­len Sei­ten kri­ti­schen Aus­tausch der Per­spek­ti­ven ein­las­sen. Der Vorteil ei­ner un­vor­be­las­te­ten UX-Ent­wick­lung ist of­fen­sicht­lich: UX En­gi­neers er­stel­len neue Nut­zungs­kon­zep­te, oh­ne sich an im schlimms­ten Fall über­hol­ten Ent­wick­lun­gen ori­en­tie­ren zu müs­sen. Denn die­se sind wäh­rend der Kon­zep­ti­on un­be­kannt.

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.