Komunikaty dla użytkownika

Komunikaty dla użytkownika

Pow­stało już wiele artykułów mówią­cych o tym jak komu­nikować błędy by były przy­jaźniejsze dla użytkown­i­ka. Więk­szość wyty­cznych do kon­struowa­nia komu­nikatów błędów odnosi się do zasad:

  • opisa­nia błę­du jako wyniku niepraw­idłowoś­ci sys­te­mu, nie użytkown­i­ka,
  • uży­wa­nia nat­u­ral­nego języ­ka,
  • komu­nikowa­nia błędów za pomocą czer­wonego koloru,
  • komu­nikowa­nia błędów w jed­no­li­ty sposób za pomocą jed­nego koloru oraz miejs­ca wyświ­et­la­nia,
  • pod­powiada­nia rozwiąza­nia błę­du, kierowa­nia użytkown­i­ka na akc­je, które może wykon­ać,
  • unika­nia przed­staw­ia­nia błędów na wyskaku­ją­cych pop­u­pach.

Są to powszechne zasady i każdy początku­ją­cy pro­jek­tant powinien się z nimi zapoz­nać. Coraz więcej stron sto­su­je dobre prak­ty­ki komu­nikacji błędów, choć zdarza­ją się jeszcze takie przy­pad­ki:

 

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

Jed­nak komu­nikac­ja sys­te­mu z użytkown­ikiem nie kończy się na wyświ­et­la­niu błędów. Odby­wa się na wielu innych płaszczyz­nach, o których należy pamię­tać odd­a­jąc pro­to­typ do dzi­ału wdroże­nia. Infor­ma­c­je jakie przekazu­je­my użytkown­ikowi to np. wiado­moś­ci e-mail potwierdza­jące założe­nie kon­ta, wiado­moś­ci o zre­al­i­zowanej przesyłce, potwierdze­nie zapłaty, wiado­moś­ci potwierdza­jące wyko­nanie akcji, zapy­ta­nia o potwierdze­nie akcji oraz wiele innych specy­ficznych dla danej strony.

 

Pro­jek­tu­jąc stronę www, sklep czy inny sys­tem należy ziden­ty­fikować punk­ty styku komu­nikacji między sys­te­mem, a użytkown­ikiem. Dlaczego to takie ważne? Moż­na wyobraz­ić sobie pracę pro­gramisty, który musi prze­nieść zapro­jek­towane funkcjon­al­noś­ci na dzi­ała­ją­cy pro­dukt. Ma mnóst­wo pra­cy i jeszcze więcej prob­lemów pro­gramisty­cznych do rozwiąza­nia. Dlat­ego nie jest jego zadaniem defin­iowanie wiado­moś­ci dla użytkown­i­ka. Jeśli my pro­jek­tan­ci nie przekaże­my konkret­nych treś­ci, pro­gramista może wstaw­ić przykład­owe. Takie treś­ci mogą być niedos­tosowane do sty­lu naszego pro­duk­tu, trudne do zrozu­mienia lub po pros­tu typowo sys­te­mowe, częs­to powodu­jąc frus­trację i niezrozu­mie­nie. Na przykład, pro­jek­tu­jąc sys­tem dla młod­szych użytkown­ików musimy pamię­tać, aby treś­ci wyświ­et­lane dla nich były proste oraz żeby były dopa­sowane do ich sys­te­mu men­tal­nego.

 

Jak odkry­wamy miejs­ca komu­nikacji z użytkown­ikiem? Kiedy mamy już per­sony, mapy empatii, cel i funkcjon­al­noś­ci naszego pro­duk­tu zaczy­namy określać przykład­owe sce­nar­iusze. Pod­czas pro­jek­towa­nia struk­tu­ry, sce­nar­iuszy, dia­gramów przepły­wów może­my mapować momen­ty naszej komu­nikacji z użytkown­ikiem. Zdarza się, że już na poziomie tworzenia cus­tomer jour­ney jesteśmy w stanie zaz­naczyć niek­tóre miejs­ca, gdzie będziemy musieli komu­nikować się z użytkown­ikiem. Takie miejs­ca notu­je­my i wracamy do nich w fazie pro­jek­towa­nia.

 

Rea­sumu­jąc, prze­myśle­nie i stworze­nie komu­nikatów przez pro­jek­tan­ta niwelu­je nieporozu­mienia oraz przyspiesza pracę pro­gramistów. W rezulta­cie nasz pro­dukt jest dopra­cow­any na każdym poziomie, a korzys­tanie z niego jest przy­jemne dla jego użytkown­ików.

 

Źródła:

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

2 odpowiedzi
  1. Hubert Oleszczuk
    Hubert Oleszczuk says:

    Według mnie kluc­zowe jest dopa­sowanie takiego komu­nikatu do sty­lu strony. Wtedy nawet dzię­ki niemu może­my zostaw­ić pozy­ty­wne wspom­nienia u odbior­cy 😉 Swo­ją drogą pamię­tam, że kiedyś ciekawą stronę z błę­dem 404 miał ser­wis demotywatory.pl.

    Odpowiedz

Odpowiedz

Want to join the discussion?
Feel free to contribute!

Odpowiedz na „Hubert OleszczukAnuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *