UFMn –
Ver­­­ein­facht und ver­­­­­bes­­­sert deine Ar­­­beit als UX De­­si­g­­ner

UX-ArchitekturInteraction DesignUX-Vorgehen

Im UX De­sign wer­den alle Ar­bei­ten im Hin­blick auf den Nut­zer durch­ge­führt. Wie aber ver­hält es sich mit alle den Sta­ke­hol­der? Wie kön­nen sie den Pro­zess ver­ste­hen, ohne dass der UX De­si­g­ner es ihm er­klärt? Das «User­flow Model and No­ta­ti­on» (UFMn) bie­tet dafür eine Lö­sung. Damit kön­nen Pro­zes­se schnell und ein­fach dar­ge­stellt und do­ku­men­tiert wer­den. Die Sta­ke­hol­der kön­nen sich je­der­zeit sel­ber ein Bild über den Pro­zess ma­chen und die Dis­kus­si­o­nen im Ple­num wer­den ein­fa­cher, da alle über das glei­che Wis­sen ver­fü­gen. Ent­de­cke mehr über die Vor­tei­le, die das UFMn im täg­li­chen Ar­beit­s­all­tag bie­tet.

Als UX De­­si­g­­ner lernt man das Vor­­­ge­hen wie in der ISO-Norm 4241-210 be­­schrie­­ben. Es sug­­ge­riert, dass der Nut­­zer al­lei­­ne im Zen­trum un­­­se­res Schaf­­fens steht. Ihm gilt un­­­se­­re Auf­­­merk­­sam­keit und er ist unser An­­sprech­s­par­t­­ner – user cen­te­red de­­sign. Und daher ist der Pro­to­­ty­­­pe unser wich­tigs­tes Ar­te­fakt. Früh be­­gin­­nen wir damit und gip­­felt im Nut­­zer­tes­ting…

… doch in mei­­nem All­­tag sieht an­ders aus. Er ist voll­­ge­­stopft mit Mee­tings mit Sta­ke­hol­­der wie Auf­­­trag­­ge­­ber, Pro­­duct Owner, Sys­tem Ar­chi­tek­ten, Bu­si­­ness Ana­­lys­ten, Pro­jek­t­lei­ter, Ma­­na­ge­­ment, Pro­­dukt Ma­na­­ger, Ent­wick­­ler und UX De­­si­g­­ner aus an­­de­ren Pro­jek­ten. Wahr­­schein­­lich kom­­men auf jeden Test mit einem Nut­­zer min­­des­tens drei Sta­ke­hol­der Mee­tings. Bei je­weils sechs Tes­t­­nut­­zer spre­chen wir schnell von 18 Mee­tings, bei denen der Test Case, Teile davon oder ein De­tail be­spro­chen wer­­den.

DIN EN ISO 9241-210: Mit allen Zusätzlichen Stakeholdern

Und in die­sen Mee­tings wer­den die Lay­outs gleich als Klick-Pro­to­ty­pes ge­zeigt. Die zu­ge­hö­ri­gen In­for­ma­ti­o­nen wie die Per­so­na, der Kon­text oder das Sze­na­rio wer­den vom De­si­g­ner er­klärt. Will sich ein Sta­ke­hol­der selbst ein Bild ma­chen, muss er diese In­for­ma­ti­on über ver­schie­de­ne Repos zu­sam­men­su­chen. Doch wo sind diese Do­ku­men­te zu fin­den? Und wel­che UI‘s sind ak­tu­ell, wel­che nur Skiz­zen? Ohne Un­ter­stüt­zung des De­si­g­ners ist es sehr schwie­rig je nach Si­tua­ti­on un­mög­lich her­aus­zu­fin­den was ak­tu­el­le und was nicht.

Diese Si­tua­ti­on führt dazu, dass

  • ... ein Ein­ar­bei­ten in das Pro­jekt ohne Hilfe sehr schwie­rig und zei­t­in­ten­siv ist.
  • ... die Sta­ke­hol­der ein un­ter­schied­li­ches Bild von den Pro­zes­sen haben. Dies führt zu Miss­ver­ständ­nis­sen.
  • ... Feh­ler in den Pro­zes­sen sind schwie­ri­ger zu ent­de­cken.
  • ... der UX De­si­g­ner zum Fla­schen­hals wird.

Wie «nut­zer­freund­lich» sind deine Ar­te­fak­te für deine Sta­ke­hol­der?

Darum habe ich das «User­flow Model and No­ti­fi­ca­ti­on» ent­wi­ckelt. Das User­flow Model be­in­hal­tet alle wich­ti­gen In­for­ma­ti­o­nen und Er­klä­run­gen, damit sich die Sta­ke­hol­der ein Vor­stel­lung des Pro­zes­ses ma­chen kön­nen. Egal ob Auf­trag­ge­ber, Pro­duct Owner oder Ent­wick­ler – alle fin­den die für sie wich­ti­gen In­for­ma­ti­o­nen im UFMn.

Was ist das «User­flow Model and No­ta­ti­on» (UFMn)

Das «User­flow Model and No­ta­ti­on» ist eine gra­fi­sche No­ta­ti­on zur User­flow Mo­del­lie­rung. Dafür be­dient sich das UFMn bei fol­gen­den No­ta­ti­o­nen und setzt sie zu etwas Neuem zu­sam­men:

  • Busi­ness Pro­cess Model and No­ta­ti­on (BPMN)
  • Mo­ckups
  • Nut­zersze­na­ri­en

Das User­flow Model führt den Be­trach­ter durch die Haupt- und Sub­pro­zes­se. Diese wer­den mit­tels UI-Lay­outs und der Flow-No­ta­ti­on mit­ein­an­der ver­bun­den. Wie­der­ho­len­de Tä­tig­kei­ten wer­den als Schlau­fe dar­ge­stellt. Für De­tail­pro­zes­se oder der Dar­stel­lung von un­ter­schied­li­chen zu­stän­den eines UI-Ele­ments kön­nen Ab­sprün­ge ein­ge­baut wer­den. No­ti­zen und Hin­wei­se sind eben­so mög­lich, wie Ver­wei­se zu in­ter­nen oder ex­ter­nen Pro­to­ty­pen. Zudem wird de­kla­riert, in wel­chem Zu­stand das User­flow Model ist: in Ar­beit, für den Re­view be­reit, zur Um­set­zung frei­ge­ge­ben oder wird nicht um­ge­setzt.

Das User­flow Model ist sehr fle­xi­bel in sei­nem Ein­satz. Das User­flow Model and No­ta­ti­on be­sitzt No­ta­ti­on für fol­gen­de An­wen­dun­gen:

  • Die Flug­hö­he des Se­quenz­dia­gramms ist frei wähl­bar – von High­fly-Pro­zes­sen bis zur Mi­cro­in­ter­ac­ti­on ist alles dar­stell­bar. Die Flug­hö­he be­stimmt der UX De­si­g­ner – je nach Pro­jekt, Pro­jekt­sta­tus und Pro­jek­tan­for­de­run­gen.
  • «Un­sicht­ba­re»-Ele­men­te wie z.B. Ges­ten kön­nen als «Aus­lö­ser» dar­ge­stellt wer­den.
  • Das User­flow Model kann auch Ping-Pong Pro­zes­se von zwei oder meh­re­ren Per­so­nas dar­stel­len und dabei Ab­hän­gig­kei­ten, wenn nötig Da­ten­fluss oder der Ver­sand von E-Mails auf­zei­gen.
  • Das User­flow Model be­in­hal­tet die In­for­ma­ti­o­nen aus den Sze­na­ri­en:
    Best-, Worst- und Edge-Cases kön­nen alle in einem UFM dar­ge­stellt wer­den.
  • Das User­flow Model kann auch tech­ni­sche Pro­zes­se, wel­che im Hin­ter­grund aus­ge­führt wer­den, ab­bil­den. Was in einem UFM an­ge­zeigt wer­den soll, be­stimmt den Nut­zen für die Sta­ke­hol­der.
  • Es kön­nen meh­re­re User­flow Mo­dels «ver­linkt» wer­den. So kön­nen, z.B. Edge-Cases aus dem Haupt-Case aus­ge­la­gert wer­den, oder es kön­nen die Mi­cro­in­ter­ac­ti­ons einer neuen Kom­po­nen­te ver­linkt wer­den. z.B. Scroll-Ver­hal­ten einer Liste.
  • UFMn kommt gut mit dem Was­ser­fall oder in­kre­men­tel­len Ar­bei­ten zu­recht.

Das Mo­dell ist so offen ge­stal­tet, dass es schritt­wei­se ver­bes­sert und an­ge­rei­chert wer­den kann. Die Idee ist, dass man so wenig wie mög­lich, aber so viel wie nötig do­ku­men­tiert. 

Userflow Model FIGMA Demofile Hier zum Downloaden

Was sind die Vor­tei­le für deine Sta­ke­hol­der

  • Alle Pro­jekt­be­tei­lig­ten kön­nen je­der­zeit sich ein Bild des ak­tu­el­len Stands der Pro­zes­se an­se­hen.
  • Alle in der Dis­kus­si­on spre­chen vom Glei­chen und alle kön­nen mit dem Fin­ger auf etwas zei­gen oder kom­men­tie­ren.
  • Jedem Teil­neh­mer ist in­nert kür­zes­ter Zeit klar wie der Pro­zess funk­tio­niert – wenn nicht, weiss man was man nach­bes­sern muss.
  • Die Jira-Story-Schrei­ber müs­sen nicht alles in Text-Form be­schrei­ben. Die Pro­zes­se und Screens kön­nen ein­fach ein­ge­bun­den wer­den.
  • Ent­wick­ler ver­ste­hen die Kom­ple­xi­tät schnel­ler und bes­ser. Die Ge­sprä­che wer­den auf einem an­de­ren Level ge­führt.
  • Die Um­set­zungs­qua­li­tät der User­in­ter­fa­ces und der Pro­zes­se wird sich so qua­li­ta­tiv stei­gern. Jede In­ter­ak­ti­on und auf jede Sta­tus­än­de­rung kann ex­pli­zit hin­ge­wie­sen wer­den.
  • Der UX De­si­g­ner wird nicht zum Fla­schen­hals da die In­for­ma­ti­o­nen ste­hen je­der­zeit zur Ver­fü­gung
  • Der UX Go­ver­nance Auf­wand deut­lich klei­ner.

Meine Vor­tei­le als UX De­si­g­ner

  • Du be­ein­druckst deine Sta­ke­hol­der, wenn du ihnen einen sol­chen Pro­zess prä­sen­tierst.
  • Pro­zes­se er­a­r­bei­te ich be­wuss­ter, de­tail­lier­ter und in hö­he­rer Qua­li­tät.
  • Durch die Über­sicht wird es ein­fa­cher schlan­ke User­pro­zes­se zu bauen.
  • Ab­hän­gig­kei­ten zu an­de­ren Pro­zes­sen, In­ter­ak­ti­o­nen, etc. wer­den sehr früh of­fen­sicht­lich.
  • Du ent­deckst ein­fa­cher In­kon­sis­ten­zen in dei­nen De­si­gns.
  • Du kannst Kol­le­gen deut­lich schnel­ler ein­ar­bei­ten.

… und das Beste daran ist, du sparst Zeit. Deine Mee­tings sind deut­lich kür­zer und es braucht we­ni­ger!!!

UFMn im De­tail

Im nächs­ten Ar­ti­kel zeige ich, wel­che Ele­men­te das «User­flow Model and No­ta­ti­on» dir zur Ver­fü­gung stellt und wie man ein UFMn in Figma auf­baut.

Hier geht es zum nächs­ten Ar­ti­kel: UFMn – So geht «User­flow Model and No­ta­ti­on»