Komunikaty dla użytkownika

Powsta­ło już wie­le arty­ku­łów mówią­cych o tym jak komu­ni­ko­wać błę­dy by były przy­jaź­niej­sze dla użyt­kow­ni­ka. Więk­szość wytycz­nych do kon­stru­owa­nia komu­ni­ka­tów błę­dów odno­si się do zasad:

• opi­sa­nia błę­du jako wyni­ku nie­pra­wi­dło­wo­ści sys­te­mu, nie użyt­kow­ni­ka,
• uży­wa­nia natu­ral­ne­go języ­ka,
• komu­ni­ko­wa­nia błę­dów za pomo­cą czer­wo­ne­go kolo­ru,
• komu­ni­ko­wa­nia błę­dów w jed­no­li­ty spo­sób za pomo­cą jed­ne­go kolo­ru oraz miej­sca wyświe­tla­nia,
• pod­po­wia­da­nia roz­wią­za­nia błę­du, kie­ro­wa­nia użyt­kow­ni­ka na akcje, któ­re może wyko­nać,
• uni­ka­nia przed­sta­wia­nia błę­dów na wyska­ku­ją­cych popu­pach.

Są to powszech­ne zasa­dy i każ­dy począt­ku­ją­cy pro­jek­tant powi­nien się z nimi zapo­znać. Coraz wię­cej stron sto­su­je dobre prak­ty­ki komu­ni­ka­cji błę­dów, choć zda­rza­ją się jesz­cze takie przy­pad­ki:

http://www.e-osiedlelawendowe.pl/

Jed­nak komu­ni­ka­cja sys­te­mu z użyt­kow­ni­kiem nie koń­czy się na wyświe­tla­niu błę­dów. Odby­wa się na wie­lu innych płasz­czy­znach, o któ­rych nale­ży pamię­tać odda­jąc pro­to­typ do dzia­łu wdro­że­nia. Infor­ma­cje jakie prze­ka­zu­je­my użyt­kow­ni­ko­wi to np. wia­do­mo­ści e-mail potwier­dza­ją­ce zało­że­nie kon­ta, wia­do­mo­ści o zre­ali­zo­wa­nej prze­sył­ce, potwier­dze­nie zapła­ty, wia­do­mo­ści potwier­dza­ją­ce wyko­na­nie akcji, zapy­ta­nia o potwier­dze­nie akcji oraz wie­le innych spe­cy­ficz­nych dla danej stro­ny.

Pro­jek­tu­jąc stro­nę www, sklep czy inny sys­tem nale­ży ziden­ty­fi­ko­wać punk­ty sty­ku komu­ni­ka­cji mię­dzy sys­te­mem, a użyt­kow­ni­kiem. Dla­cze­go to takie waż­ne? Moż­na wyobra­zić sobie pra­cę pro­gra­mi­sty, któ­ry musi prze­nieść zapro­jek­to­wa­ne funk­cjo­nal­no­ści na dzia­ła­ją­cy pro­dukt. Ma mnó­stwo pra­cy i jesz­cze wię­cej pro­ble­mów pro­gra­mi­stycz­nych do roz­wią­za­nia. Dla­te­go nie jest jego zada­niem defi­nio­wa­nie wia­do­mo­ści dla użyt­kow­ni­ka. Jeśli my pro­jek­tan­ci nie prze­ka­że­my kon­kret­nych tre­ści, pro­gra­mi­sta może wsta­wić przy­kła­do­we. Takie tre­ści mogą być nie­do­sto­so­wa­ne do sty­lu nasze­go pro­duk­tu, trud­ne do zro­zu­mie­nia lub po pro­stu typo­wo sys­te­mo­we, czę­sto powo­du­jąc fru­stra­cję i nie­zro­zu­mie­nie. Na przy­kład, pro­jek­tu­jąc sys­tem dla młod­szych użyt­kow­ni­ków musi­my pamię­tać, aby tre­ści wyświe­tla­ne dla nich były pro­ste oraz żeby były dopa­so­wa­ne do ich sys­te­mu men­tal­ne­go.

Jak odkry­wa­my miej­sca komu­ni­ka­cji z użyt­kow­ni­kiem? Kie­dy mamy już per­so­ny, mapy empa­tii, cel i funk­cjo­nal­no­ści nasze­go pro­duk­tu zaczy­na­my okre­ślać przy­kła­do­we sce­na­riu­sze. Pod­czas pro­jek­to­wa­nia struk­tu­ry, sce­na­riu­szy, dia­gra­mów prze­pły­wów może­my mapo­wać momen­ty naszej komu­ni­ka­cji z użyt­kow­ni­kiem. Zda­rza się, że już na pozio­mie two­rze­nia custo­mer jour­ney jeste­śmy w sta­nie zazna­czyć nie­któ­re miej­sca, gdzie będzie­my musie­li komu­ni­ko­wać się z użyt­kow­ni­kiem. Takie miej­sca notu­je­my i wra­ca­my do nich w fazie pro­jek­to­wa­nia.

Reasu­mu­jąc, prze­my­śle­nie i stwo­rze­nie komu­ni­ka­tów przez pro­jek­tan­ta niwe­lu­je nie­po­ro­zu­mie­nia oraz przy­spie­sza pra­cę pro­gra­mi­stów. W rezul­ta­cie nasz pro­dukt jest dopra­co­wa­ny na każ­dym pozio­mie, a korzy­sta­nie z nie­go jest przy­jem­ne dla jego użyt­kow­ni­ków.

Źró­dła:

http://uxwatch.pl/jak-komunikowac-bledy/