Projektowanie zorientowane na użytkownika (ang. UCD – User-Centered Design)

Pro­jek­to­wa­nie zorien­to­wa­ne na użyt­kow­ni­ka (ang. UCD – User-Cen­te­red Design) pozwa­la na pro­jek­to­wa­nie przy­ja­znych pro­duk­tów dla poprzez ukie­run­ko­wa­nie pro­ce­su pro­jek­to­we­go na potrze­by final­ne­go odbior­cy.

W UCD w kolej­nych testu­je się (w spo­sób opi­sa­ny wcze­śniej jako testy z użyt­kow­ni­ka­mi) pro­duk­ty otrzy­my­wa­ne w pro­ce­sie kre­acji ser­wi­su, usu­wa wykry­te pro­ble­my i ponow­nie pod­da­je testom.

Testo­wa­niu pod­le­ga­ją:

• makie­ty sys­te­mu,
• pro­jek­ty gra­ficz­ne,
• dzia­ła­ją­cy sys­tem.

Pod poję­ciem makie­ty rozu­miem zarów­no papie­ro­we, pro­ste makiet­ki jak i inte­rak­tyw­ne makie­ty opra­co­wa­ne w Power­Po­int lub HTML. Niżej pre­zen­tu­ję narzę­dzia uła­twia­ją­ce pro­jek­to­wa­nie UCD.

Ana­li­za kon­tek­stu użyt­ko­wa­nia
Ana­li­za ta ma na celu dokład­ne pozna­nie przy­szłych użyt­kow­ni­ków sys­te­mu. Uła­twi to okre­śle­nie wyma­gań co do sys­te­mu.

Musisz odpo­wie­dzieć na pyta­nia:

• kim są użyt­kow­ni­cy sys­te­mu,
• do cze­go będzie słu­żył im sys­tem,
• jakie są umie­jęt­no­ści użyt­kow­ni­ków,
• czy sys­tem lub użyt­kow­ni­cy napo­ty­kać będą na ogra­ni­cze­nia zewnętrz­ne,

By poznać użyt­kow­ni­ków oraz ich wyma­ga­nia możesz posłu­żyć się:

• spo­tka­niem z użyt­kow­ni­ka­mi (pole­cam)
• ankie­ta­mi
• wywia­da­mi indy­wi­du­al­ny­mi z użyt­kow­ni­ka­mi (pole­cam)
• obser­wa­cją pra­cy użyt­kow­ni­ków

Sor­to­wa­nie kart
Meto­da ta uła­twia zapro­jek­to­wa­nie struk­tu­ry ser­wi­su zgod­nej z ocze­ki­wa­nia­mi użyt­kow­ni­ków.
Przy­go­to­wu­jesz kar­to­ni­ki z nazwa­mi ele­men­tów ser­wi­su. Następ­nie użyt­kow­ni­cy zgru­pu­ją podob­ne kar­to­ni­ki w sto­sy. Tym samym w natu­ral­ny spo­sób two­rzą się kate­go­rie dla ele­men­tów ser­wi­su. Użyt­kow­ni­cy mogą tak­że za pomo­cą uło­że­nia sto­sów na sto­le okre­ślać ich wza­jem­ne podo­bień­stwo. Moż­na popro­sić tak­że użyt­kow­ni­ka o poda­nie nazw dla utwo­rzo­nych grup.

Po prze­pro­wa­dze­niu kil­ku testów tego typu nale­ży zasta­no­wić się nad tym na ile pogru­po­wa­nia poczy­nio­ne przez poszcze­gól­nych użyt­kow­ni­ków są do sie­bie zbli­żo­ne.
Szcze­gól­ną uwa­gę nale­ży zwró­cić na pro­ble­ma­tycz­ne ele­men­ty – te któ­rych użyt­kow­ni­cy nie potra­fi­li pogru­po­wać bądź te któ­re były gru­po­wa­ne przez każ­de­go użyt­kow­ni­ka ina­czej.

Sce­na­riu­sze uży­cia (use cases)
Sce­na­riu­sze uży­cia opi­su­ją jak użyt­kow­ni­cy wyko­nu­ją zada­nia na pod­sta­wie typo­wych zadań. Są two­rzo­ne zawsze z per­spek­ty­wy użyt­kow­ni­ka i jego potrzeb.

Sce­na­riu­sze uży­cia naj­le­piej opra­co­wać wraz z final­ny­mi użyt­kow­ni­ka­mi ser­wi­su.

Per­so­ny
Per­so­na to opra­co­wa­ny pro­fil typo­we­go użyt­kow­ni­ka.
By stwo­rzyć per­so­nę piszesz cha­rak­te­ry­sty­kę final­ne­go użyt­kow­ni­ka dla każ­dej gru­py doce­lo­wej ser­wi­su. W opi­sie uwzględ­niasz cha­rak­te­ry­sty­kę oso­by (np. sto­pień zna­jo­mo­ści tech­no­lo­gii) oraz typo­we cele, zada­nia i potrze­by jakie ma na uży­tek per­so­ny reali­zo­wać sys­tem.

Dla zwięk­sze­nia efek­tu moż­na dla wymy­ślo­nej per­so­ny stwo­rzyć nazwi­sko, zdję­cie i kil­ka infor­ma­cji, któ­re „uwia­ry­god­nią ją” (np. hob­by). Wyobraź sobie, że z Two­je­go ser­wi­su korzy­sta two­ja Mama – dobre ćwi­cze­nie, pole­cam 🙂