Buchtipp: The Laws of Simplicity – oder: geht’s auch einfacher?

Wer sich häu­fi­ger mit Soft­ware und Betriebs­sys­te­men beschäf­tigt, sowohl aus Sicht des Nut­zers, als auch aus Sicht des Pro­gram­mie­rers, der weiß um die Fall­stri­cke in der Schnitt­stel­len­pro­gram­mie­rung. Nun sind Redak­teu­re per se nicht dazu geeig­net, Benut­zer­freund­lich­keit zu ergrün­den oder zu defi­nie­ren, aber sie tra­gen als Räd­chen im Getrie­be des Erstel­lungs­pro­zes­ses doch Ver­ant­wor­tung, wenn es um die Benutz­bar­keit von Soft­ware geht.

Also neh­men wir mal an, Sie sind in der Ent­wick­lungs­ab­tei­lung bei May­er und Söh­ne, die für eine auf dem Markt befind­li­che Ölpum­pe eine soft­ware­ba­sier­te Steue­rung der Durch­fluss­men­ge bei gleich­zei­ti­ger Über­wa­chung über das Inter­net ent­wi­ckelt. So ein 12-Mann-KMU Betrieb, eine Stüt­ze der deut­schen Wirt­schaft.

Kön­nen Sie sich vor­stel­len? Gut. Um Ihr Pro­dukt zu erstel­len, benö­ti­gen die Pro­gram­mie­rer Ihres Betriebs meist Soft­ware eines Unter­neh­mens aus Red­mond. Gibt’s aus der Packung. Aber auch als Redak­teur ver­wen­den Sie Soft­ware, um eine Soft­ware zu doku­men­tie­ren. Sie sit­zen also zwi­schen zwei (oder mehr) Pro­gram­men: Das Eine muss qua­si mit dem Ande­ren »ver­packt« wer­den. Sie sind als Redak­teur ver­traut mit Ihren Werk­zeu­gen, mit Ihrem Office- oder Lay­out-Pro­gramm, sie kön­nen Tem­pla­tes erstel­len, ken­nen die Tas­ta­tur­kür­zel und kön­nen den Arbeits­ab­lauf ziem­lich klar defi­nie­ren. Was Sie ken­nen, ist die Benut­zer­ober­flä­che Ihres Pro­gramms, mit dem Sie Ihr Geld ver­die­nen. Das ist Ihr Zuhau­se. Womit Sie sich aber nicht so gut aus­ken­nen, ist die Soft­ware, die Sie doku­men­tie­ren sol­len. Sie haben sie nicht geschrie­ben und ken­nen auch den Quell­code nicht.

In bei­den Fäl­len ist die Bild­schirm­ober­flä­che die pri­mä­re Kom­mu­ni­ka­ti­ons­schnitt­stel­le zwi­schen dem Benut­zer und dem Pro­gramm. Wenn SIE den Knopf zum Dru­cken nicht fin­den, kann das Pro­gramm das auch nicht. Das wis­sen auch die Her­stel­ler der Betriebs­sys­te­me, auf denen Ihre Soft­ware zum Ein­satz kom­men soll. Jedes die­ser Betrieb­sys­te­me hat eine eige­ne Phi­lo­so­phie, die der Benut­zer, der damit arbei­tet, auch ken­nen soll­te. Nun gibt es zu allen Betriebs­sys­te­men Gestal­tungs­richt­li­ni­en, wie die Ele­men­te der Benut­zer­schnitt­stel­le aus­se­hen sol­len, wie sie ange­ord­net wer­den sol­len, damit der Benut­zer kei­ne lan­gen Ein­ar­bei­tungs­zei­ten benö­tigt und sofort das Gefühl hat, damit pro­duk­tiv sei­en zu kön­nen. Die­se Richt­li­ni­en ken­nen Sie viel­leicht, um die Tätig­kei­ten und Bild­schirm­ele­men­te kor­rekt zu beschrei­ben, damit der Benut­zer sofort mit dem Hand­buch zurecht kommt: Sie schrei­ben »Wäh­len Sie Dru­cken im Menü Datei« statt »Rufen Sie Datei > Dru­cken auf.« Letz­te­res ist näm­lich Pro­gram­mie­rer-Deutsch, es erfor­dert vom lai­en­haf­ten Benut­zer unnö­ti­ge »Lade­zei­ten«, bis er ver­steht, was er tun soll. Die Trans­fer­leis­tung, die er voll­brin­gen muss, um den Text zu ver­ste­hen, steht ihm für die Aus­füh­rung aber dann nicht mehr zur Ver­fü­gung. Wenn jetzt noch Zeit­druck dazu kommt, kön­nen Sie regel­recht zuse­hen, wie die Frus­tra­ti­on anschwillt.

Aber das ken­nen Sie. Was Sie nicht wis­sen ist, ob der Pro­gram­mie­rer die­se Richt­li­ni­en auch kennt. Kom­men Sie aber nun bloß nicht mit einem 400 Sei­ten star­ken Wäl­zer, den er sich mal anschau­en soll­te. Das wird er nie tun, denn dazu hat er gar kei­ne Zeit. Meist (und das ist nicht abwer­tend gemeint) wirft er eine graue Mas­ke auf den Schirm, klemmt die not­wen­di­gen But­tons dahin, wo er es für rich­tig hält – oft unter dem irr­tüm­li­chen Ein­druck, dass das spä­ter sowie­so noch geän­dert wird (tut es aber nicht, weil die Soft­ware lie­ber neue Fea­tures bekommt als dass die Ober­flä­che ent­rüm­pelt wird) und hängt die Pro­gramm-Rou­ti­nen ein.

Es geht auch anders: »S.H.E«: »Shrink« (Redu­zie­ren), »Hide« (Ver­ste­cken, bzw. Aus­blen­den) und »Embo­dy« (Ver­kör­pern, Aus­drü­cken). Dies ist der ers­te Gestal­tungs­grund­satz in dem Buch »The Laws of Sim­pli­ci­ty« von John Maeda (sie­he auch Text­box rechts). Aber was ist das?

• »Shrink«. Redu­zie­ren Sie die Ober­flä­che auf das Wesent­li­che. Es ist nicht wich­tig, dass der Benut­zer sieht, was man alles mit dem Pro­gramm anstel­len kann, son­dern dass er mög­lichst rasch das tun kann, wozu er das Pro­gramm benut­zen will. Über­le­gen Sie also vor­her, wie die Ober­flä­che aus­se­hen soll, wel­che Funk­tio­nen wich­tig sind und wel­che Funk­tio­nen in Menüs oder Dia­lo­gen ver­steckt wer­den kön­nen. Dann erstel­len sie ein »Mock-Up«, also eine Ober­flä­che ohne die dahin­ter lie­gen­den Pro­gramm-Funk­tio­nen und las­sen Sie von einem Außen­sei­ter kri­tisch tes­ten – bei­spiels­wei­se dem Redak­teur. Erst wenn die Rück­mel­dung posi­tiv ist, begin­nen Sie mit der Benut­zer­ober­flä­che.
• »Hide«. Blen­den Sie die für die Bedie­nung unwich­ti­gen Funk­tio­nen aus. Wenn Sie bei­spiels­wei­se in dem ein­gangs genann­ten Bei­spiel einer Soft­ware zur Durch­fluss­mes­sung die Abtast­ra­te ein­stel­len kön­nen, dass ist das eine Funk­ti­on, die Sie nicht stän­dig ändern. Also gehört sie in ein Menü »Ein­stel­lun­gen« zusam­men mit der Ein­stel­lung der ange­schlos­se­nen Hard­ware, also in der drit­ten Ebe­ne unter der Benut­zer­ober­flä­che, nicht in die Menü­leis­te. Das Dru­cken dage­gen gehört wei­ter oben in die Menü­leis­te in einen But­ton, denn das Aus­ga­be­ge­rät kann sich wäh­rend der Bedie­nung ändern, da will der Benut­zer nicht stän­dig in den Ein­stel­lun­gen her­um­su­chen müs­sen. (Außer­dem kön­nen Sie damit bes­ser die Zugriffs­be­schrän­kun­gen für bestimm­te Funk­tio­nen kon­trol­lie­ren und fest­le­gen.)
• »Embo­dy«. Wenn Sie schon die Ober­flä­che ent­rüm­pelt haben, soll­te der Benut­zer nicht den Ein­druck bekom­men, Sie hät­ten ihm eine Spar­ver­si­on ange­dreht oder er bekä­me nichts für sein Geld. Wer­ten Sie die Ober­flä­che durch pro­fes­sio­nell gestal­te­te But­tons auf geben Sie ihm die Mög­lich­keit, Tei­le der Ober­flä­che an sei­ne Vor­stel­lun­gen anzu­pas­sen (Hin­ter­grund- und Schrift­far­be, am bes­ten als fer­ti­ge Sets). Der Benut­zer hat dadurch ein schnel­les Erfolgs­er­leb­nis. Das erhöht die Moti­va­ti­on. Und macht den Ein­druck von Qua­li­tät und sorg­fäl­ti­ger Arbeit.

Wenn Sie jetzt den­ken, das eben Geschrie­be­ne beträ­fe nur die Pro­gram­mie­rer, dann lie­gen Sie nicht ganz rich­tig. Auch Redak­teu­re kön­nen die­se Grund­sät­ze nut­zen:

• Redu­zie­ren Sie die Text­men­ge, indem Sie Text­stel­len, die für die Benut­zung nicht erfor­der­lich sind, in eine »Info« ver­schie­ben und ver­schlan­ken. Über­le­gen Sie bei jedem Warn­hin­weis und jeder Hand­lungs­an­wei­sung, wie er/​sie sich noch knap­per und prä­zi­ser for­mu­lie­ren lässt.
• Set­zen sie häu­fi­ge Zwi­schen­über­schrif­ten ein und schaf­fen Sie Platz für gedank­li­che Ein­hei­ten. Benut­zen Sie weni­ger Quer­ver­wei­se (sonst muss der Benut­zer stän­dig blät­tern), und ver­zich­ten Sie auf Über­schrif­ten-Num­me­rie­rung, das erhöht nur die Kom­ple­xi­tät. Fas­sen Sie Tätig­kei­ten zusam­men, die der Benut­zer »auf einen Rutsch« erle­di­gen kann.
• Set­zen Sie Far­be ein, nut­zen Sie den Weiß­raum auf der Sei­te (Papier oder Inter­net). Wer­ten Sie Gra­fi­ken auf durch farb­li­che Unter­le­gung oder Her­vor­he­bung rele­van­ter Stel­len. Nut­zen Sie pro­fes­sio­nell wir­ken­de Vor­la­gen und fra­gen Sie zur Not eben auch mal einen Gra­fi­ker um Hil­fe.

Benut­zen Sie Ihren Ver­stand – die Soft­ware hat näm­lich kei­nen.