De­sign Thin­king

Wie CIOs als In­no­va­to­ren das Bu­si­ness vor­an­brin­gen.

Computerwoche - - Vorderseite - Von Chris­toph Li­xen­feld, frei­er Jour­na­list und Au­tor in Ham­burg

De­sign Thin­king dreht sich im Kern um mehr als nur um De­sign“, de­fi­niert Chris­toph Mei­nel, Pro­fes­sor für In­ter­net-Tech­no­lo­gi­en und -Sys­te­me am Has­soPlatt­ner-In­sti­tut (HPI) in Pots­dam. „Es geht um ei­nen Pro­zess, der In­no­va­tio­nen mög­lich macht und vor­an­treibt.“Da­mit be­schäf­tigt sich das HPI schon seit Jah­ren. 2007 ent­stand die „School of De­sign Thin­king“, ein Zu­satz­stu­di­en­gang, um in mul­ti­dis­zi­pli­nä­ren Teams be­nut­zer­freund­li­che Pro­duk­te und Di­enst­leis­tun­gen für al­le Le­bens­be­rei­che zu ent­wi­ckeln.

Mei­nel be­trach­tet De­sign Thin­king ins­be­son­de­re aus dem Blick­win­kel der IT-Ent­wick­lung. Da­bei ge­he es vor al­lem „um die Fra­ge, wie man Ide­en ent­wi­ckeln, de­ren Be­deu­tung be­stim­men und die Im­ple­men­tie­rung eva­lu­ie­ren, wie man fest­stel­len kann, wel­che Ide­en et­was tau­gen und wel­che nicht“.

Ide­en zu ha­ben ist leicht, so­lan­ge man sie nicht mit ir­gend­wel­cher Zweck­haf­tig­keit be­las­tet. Kin­der sind beim Spie­len auch des­halb so krea­tiv und ein­falls­reich, weil das Er­son­ne­ne nichts leis­ten muss – au­ßer hübsch zu sein und Spaß zu brin­gen oder bei­des. Un­ter­neh­men wol­len aber nicht spie­len, son­dern Pro­duk­te ent­wi­ckeln, die sich ver­kau­fen. Am bes­ten ge­lingt das, wenn die Pro­duk­te mög­lichst nah an den Wün­schen der po­ten­zi­el­len Kun­den sind. Dass dies sehr häu­fig nicht der Fall ist, zeigt das Bei­spiel Soft­ware: Wir be­nut­zen sie oft, weil es kei­ne Al­ter­na­ti­ven da­zu gibt, und är­gern uns fort­lau­fend über Schwä­chen wie man­geln­de Nut­zer­freund­lich­keit.

Ei­ne wich­ti­ge Ur­sa­che für die­se Un­zu­läng­lich­kei­ten sieht Mei­nel im Ablauf von Ent­wick­lungs­pro­zes­sen in der IT und in der Zu­sam­men­set­zung der Teams. De­sign Thin­king setzt ge­nau an die­sen Schwä­chen an, in­dem es die Pro­zes­se ra­di­kal ver­än­dert. Drei Punk­te sind da­bei von zen­tra­ler Be­deu­tung.

In­ter­dis­zi­pli­nä­re Teams

„Für ei­nen er­folg­rei­chen In­no­va­ti­ons­pro­zess braucht man Men­schen mit ganz un­ter­schied­li­chem Hin­ter­grund“, sagt der Wis­sen­schaft­ler, „Ent­wick­ler, Ma­na­ger, Ver­käu­fer und vie­le an­de­re. In sol­chen Teams muss Au­to­ri­tät im­mer wie­der neu ge­won­nen wer­de. Es gilt zu ver­hin­dern, dass ei­ne eta­blier­te Fi­gur den gan­zen Pro­zess be­stimmt.“Pro­ble­ma­tisch wird das sei­ner Meinung nach mit Men­schen, die ih­ren Job schon seit 20 Jah­ren in der im­mer glei­chen

Wei­se ma­chen. „Sol­che Mit­ar­bei­ter da­zu zu brin­gen, Din­ge auch mal an­ders an­zu­ge­hen, ist ei­ne gro­ße Her­aus­for­de­rung.“In Deutsch­land, fin­det Mei­nel, den­ken wir bei In­no­va­tio­nen im­mer stark tech­no­lo­gisch, fo­kus­sie­ren uns al­so auf ein tech­ni­sches Ziel. Das be­deu­tet, dass die Blick­rich­tung vom Ent­wick­ler zum An­wen­der geht und nicht um­ge­kehrt. Es wird nicht als Ers­tes die ele­men­ta­re Fra­ge ge­stellt, was der spä­te­re Nut­zer über­haupt von ei­nem Pro­dukt er­war­tet und wie er es ge­nau be­nut­zen will.

Ein Bein vor das an­de­re set­zen

Ne­ben dem Be­trach­tungs­win­kel spielt der ite­ra­ti­ve Zu­gang ei­ne wich­ti­ge Rol­le. Wo­bei schritt­wei­ses Vor­ge­hen im De­sign Thin­king ei­gent­lich be­deu­tet, rück­wärts zu lau­fen. Beim klas­si­schen Ent­wick­lungs­an­satz geht es um die Rea­li­sie­rung be­stimm­ter Funk­tio­nen, be­stimm­ter Fä­hig­kei­ten ei­ner Soft­ware. Die Fra­ge, ob der An­wen­der hin­ter­her da­mit auch um­ge­hen kann, ist bis­her oft zweit­ran­gig.

De­sign Thin­king geht den um­ge­kehr­ten Weg: Zu­nächst be­schreibt das Team ein po­ten­zi­el­les Pro­blem, das es zu lö­sen gilt. Es stellt sich da­bei ei­nen kon­kre­ten Job vor, den ein An­wen­der mit ei­nem Stück Soft­ware oder ei­nem Ge­rät er­le­di­gen will. Dann er­schafft es qua­si den da­zu pas­sen­den Men­schen, ver­dich­tet das Pro­blem so­mit zu ei­ner „Per­so­na“. Die­se Ver­mensch­li­chung des Pro­zes­ses die­ne auch da­zu, „Em­pa­thie zu we­cken für die Pro­blem­lö­sung“.

Es geht um die Fra­ge, was die­se ima­gi­nier­te Person sich wünscht, wel­che Kennt­nis­se und Fä­hig­kei­ten sie mit­bringt. Erst nach­dem das ge­klärt ist, be­ginnt die ei­gent­li­che Ent­wick­lungs- und Pro­gram­mier­ar­beit. Die Fra­ge, wie sich ei­ne Soft­ware ver­hal­ten soll, wird al­so von der Pro­gram­mie­rung be­stimm­ter Funk­tio­nen ge­trennt. Mit die­ser Vor­ge­hens­wei­se trägt De­sign Thin­king der Tat­sa­che Rech­nung, dass dem User die Tech­no­lo­gie, die hin­ter ei­ner An­wen­dung steckt, in der Re­gel völ­lig egal ist. Im nächs­ten Schritt un­ter­sucht das Team dann die Ver­hal­tens­wei­sen – und zwar so­wohl die der Soft­ware als auch die des Users – mit Hil­fe von Pro­to­ty­pen, zum Bei­spiel aus Pa­pier. Es geht dar­um, die Be­die­nung der Soft­ware zu mo­del­lie­ren und das De­sign an­schlie­ßend so zu ge­stal­ten, das die fer­ti­ge An­wen­dung auch mit un­er­war­te­ten Her­an­ge­hens­wei­sen von Usern zu­recht­kommt. Schritt­wei­ses Vor­ge­hen, Of­fen­heit für Uner­war­te­tes – all das funk­tio­niert nur mit viel Feed­back. Doch in kon­ven­tio­nel­len Ent­wick­lungs­pro­zes­sen ist das schwie­rig, weiß Mei­nel: „Wenn die Ar­chi­tek­tur im Vor­der­grund steht, sind Zwi­schen­stän­de schwer dar­stell­bar und rück­kop­pel­bar. In kon­ven­tio­nel­len IT-Pro­jek­ten gibt es in der Re­gel lan­ge Pha­sen ganz oh­ne Feed­back.“Mit der Fol­ge, dass die Be­tei­lig­ten erst re­la­tiv spät mer­ken, wenn et­was aus dem Ru­der läuft.

Of­fe­ne Räu­me nut­zen

Sol­che Rou­ti­nen gilt es auf­zu­bre­chen, und da­bei hel­fen auch Äu­ßer­lich­kei­ten. „Die räum­li­chen Ge­ge­ben­hei­ten ha­ben viel Ein­fluss dar­auf, was pas­siert“, rät der HPI-Mann. „Ein Hör­saal eig­net sich zum Bei­spiel nicht da­für, in klei­nen Teams zu dis­ku­tie­ren.“Statt­des­sen kön­ne man mit be­weg­li­chen Whi­te­boards, die im­mer wie­der neu po­si­tio­niert wer­den, für un­ter­schied­li­che Grup­pen­grö­ßen die je­weils pas­sen­de At­mo­sphä­re schaf­fen.

Fa­zit

CIOs und an­de­re Füh­rungs­kräf­te soll­ten wis­sen, was mit De­sign Thin­king mög­lich ist, ent­spre­chen­des Know-how auf­bau­en und ge­eig­ne­te Teams bil­den. Mei­nel zu­fol­ge geht es dar­um, mög­lichst vie­le Mit­ar­bei­ter mit De­sign Thin­king ver­traut zu ma­chen. Und na­tür­lich auch sich selbst. Des­halb soll­ten CIOs im ers­ten Schritt selbst an Work­shops Drit­ter teil­neh­men, um die At­mo­sphä­re und die In­no­va­ti­on­s­at­ti­tü­de von De­sign Thin­king zu spü­ren. „Es geht um Krea­ti­vi­täts­tech­ni­ken, die an­sons­ten an Kunst­hoch­schu­len ge­lehrt wer­den.“

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.