Czy war­to kopio­wać roz­wią­za­nia od innych?
Czym bench­mar­king UX róż­ni się od ana­li­zy kon­ku­ren­cji?
Czy war­to two­rzyć listę funk­cjo­nal­no­ści swo­ich apli­ka­cji w opar­ciu o inne ser­wi­sy?
Czy jest sens wymy­ślać wszyst­ko same­mu?

Na te pyta­nia odpo­wie nasz arty­kuł, któ­ry jest kon­ty­nu­acją tema­tu o ana­li­zie kon­ku­ren­cji.

Analiza konkurencji a benchmarking

O ile pierw­sza część arty­ku­łu opo­wia­da­ła o bar­dziej stra­te­gicz­nej per­spek­ty­wie (czy­li co powin­no cha­rak­te­ry­zo­wać nasz pro­dukt wzglę­dem kon­ku­ren­cji) o tyle w tym arty­ku­le sku­pi­my się bar­dziej na samych ele­men­tach inter­fej­su. My nazy­wa­my ten etap bench­mar­kin­giem (lub jeże­li woli­cie po pol­sku – zbie­ra­niem inspi­ra­cji) i fak­tycz­nie bar­dziej przy­po­mi­na to zbie­ra­nie skar­bów do skrzyn­ki i selek­cję naj­lep­szych ani­że­li wyli­cze­nia w Exce­lu. A przy­naj­mniej tak powin­no być, bo bar­dzo czę­sto meto­dy ana­li­zy i bench­mar­kin­gu sca­la się w jeden pro­ces, któ­ry nie­wie­le ma wspól­ne­go ze świa­do­my­mi wybo­ra­mi orga­ni­za­cji.

Jak nie robić benchmarkingu

Zawsze gdy doko­nu­je­my jakichś ana­liz (a tym bar­dziej opar­tych na samych aspek­tach wizu­al­nych) war­to zasta­no­wić się, dla­cze­go wyko­nu­je­my taką ana­li­zę i co ma być rezul­ta­tem naszych prac. W prze­ciw­nym wypad­ku bench­mar­king spro­wa­dzi się do mecha­nicz­ne­go prze­glą­da­nia inter­ne­tu i pseu­do­ana­liz, któ­re nie będą współ­grać ze stra­te­gią fir­my. Przy­kła­dem takiej pseu­do­ana­li­zy może być np. spi­sa­nie listy kon­ku­ren­tów i wypi­sy­wa­nie jakie ele­men­ty inter­fej­su bądź funk­cjo­nal­no­ści zna­la­zły się na ich ser­wi­sie. Na przy­kład funk­cja doda­wa­nia do ulu­bio­nych, ety­kie­ty pod pola­mi, blog, duże zdję­cie na stro­nie głów­nej lub menu bocz­ne – z uwzględ­nie­niem, któ­re ser­wi­sy zawie­ra­ją nastę­pu­ją­ce ele­men­ty.

Co wyni­ka z takie­go zesta­wie­nia? Być może oka­że się, że wszy­scy kon­ku­ren­ci sto­su­ją jakąś funk­cjo­nal­ność, na któ­rą sami byśmy nie wpa­dli, ale naj­praw­do­po­dob­niej wpę­dzi nas to w blo­ka­dę kre­atyw­ną i nie­zdol­ność do stwo­rze­nia cze­goś ponad to, co ma kon­ku­ren­cja. Co naj­wy­żej może­my sta­rać się ich doga­niać, ale nigdy ich nie wyprze­dzi­my. Zwłasz­cza w bran­ży inter­ne­to­wej, gdzie od pomy­słu do wdro­że­nia może minąć nawet kil­ka­na­ście mie­się­cy.

Dlaczego nie robić wszystkiego od nowa?

Nawet jeże­li posia­dasz nie­ogra­ni­czo­ną ilość cza­su i pie­nię­dzy, wymy­śla­nie każ­de­go deta­lu pro­duk­tu zupeł­nie od nowa tro­chę nie ma sen­su – było­by to tak zwa­ne wymy­śla­nie koła na nowo. Poza tym ist­nie­je dość spo­ra szan­sa, że wymy­ślisz coś, co może się oka­zać zupeł­nie nie­zro­zu­mia­łe dla użyt­kow­ni­ków – wszak przy­zwy­cza­je­ni są do zupeł­nie innych zna­nych im już roz­wią­zań (chy­ba, że będziesz regu­lar­nie pro­wa­dzić bada­nia – co dodat­ko­wo zwięk­sza kosz­ta i wydłu­ża czas reali­za­cji).

W dużym skró­cie zale­ty wyko­rzy­sta­nia popu­lar­nych wzor­ców pro­jek­to­wych:

• Użyt­kow­nik zna już pew­ne mecha­ni­zmy inter­fej­su, nie musi się ich uczyć;
• Użyt­kow­nik szyb­ciej wyko­na zada­nia, do któ­rych prze­zna­czo­ny jest ser­wis (przy­naj­mniej przy pierw­szych uży­ciach);
• Nie nara­żasz się na tak zwa­ne “prze­kom­bi­no­wa­nie”;
• Zaosz­czę­dzasz pew­ną ilość cza­su na eta­pie pro­jek­to­wa­nia i wdra­ża­nia (a zwłasz­cza wdra­ża­nia, bo pro­gra­mi­stom też łatwiej kopio­wać 😉 ).

Nato­miast wady zwią­za­ne ze sto­so­wa­niem popu­lar­nych wzor­ców są nastę­pu­ją­ce:

• Twój pro­dukt wyglą­da bar­dzo podob­nie do innych, łatwiej o nim zapo­mnieć;
• Za pomo­cą pod­pa­trzo­nych ele­men­tów nie zawsze da się osią­gnąć efekt koń­co­wy, o jaki nam cho­dzi­ło;
• Cię­żej jest zachwy­cić użyt­kow­ni­ka, zwró­cić uwa­gę na sam pro­jekt ser­wi­su.

Jak więc z jed­nej stro­ny nie wpę­dzić się w nie­roz­sąd­ne kopio­wa­nie i co naj­wy­żej prze­cięt­ny pro­dukt, a z dru­giej stro­ny nie wymy­ślać koła na nowo?

Jak znaleźć złoty środek w inspiracjach?

Na potrze­by ustruk­tu­ry­zo­wa­ne­go bench­mar­kin­gu koniecz­nie musi­my wydzie­lić sobie tema­ty, pod któ­re będzie­my zbie­rać przy­kła­dy. Dobrą pod­sta­wą są nie­któ­re kate­go­rie wyod­ręb­nio­ne w ana­li­zie kon­ku­ren­cji, takie jak sza­ta gra­ficz­na, wygo­da wyszu­ki­wa­nia infor­ma­cji, moż­li­wo­ści per­so­na­li­za­cji itp. Dodat­ko­wo moż­na pomy­śleć o takich aspek­tach jak uła­twie­nia w wypeł­nia­niu for­mu­la­rzy, eks­po­zy­cja ofer­ty – rów­nież o obsza­rach spe­cy­ficz­nych dla Two­jej bran­ży (np. kwe­stie spo­łecz­no­ścio­we, wyko­rzy­sta­nie loka­li­za­cji użyt­kow­ni­ka).

Waż­na jest też wie­dza o użyt­kow­ni­ku – to z niej powin­ny się wykla­ro­wać tema­ty do bench­mar­kin­gu. I tak dla każ­de­go tema­tu powin­ni­śmy zna­leźć od 5 do 10 inte­re­su­ją­cych przy­kła­dów i oce­niać je wyłącz­nie pod kątem tego tema­tu. Co bar­dzo waż­ne – przy wybo­rze źró­deł inspi­ra­cji war­to (a nawet trze­ba) wyjść poza swo­ją bran­żę i odwo­łać się do innych, w któ­rych wystę­pu­je spo­ra kon­ku­ren­cja (np. tury­sty­ka, ban­ko­wość, róż­ne­go rodza­ju agre­ga­to­ry). To wła­śnie w nich zatrud­nia się wie­lu pro­jek­tan­tów i mniej rze­czy dzie­je się “przez przy­pa­dek”. W tym tkwi cały sekret sku­tecz­nej inspi­ra­cji – wie­my cze­go potrze­bu­je nasz użyt­kow­nik i szu­ka­my dla nie­go jak naj­lep­szych roz­wią­zań wszę­dzie gdzie się da.

Przy­kła­do­wy graf z inspi­ra­cja­mi oraz listą tema­tów – tak wła­śnie mógł­by wyglą­dać bench­mar­king dla apli­ka­cji do zama­wia­nia bile­tów do kina

Gdy mamy już spo­rą listę roz­wią­zań (któ­re naj­pro­ściej rzecz ujmu­jąc – podo­ba­ją nam się) może­my przy­stą­pić do selek­cji i wybo­ru tych naj­bar­dziej klu­czo­wych.

Jeże­li cho­dzi o selek­cję musi­my mieć na uwa­dze:

• Czy to, co nam się spodo­ba­ło fak­tycz­nie jest potrzeb­ne użyt­kow­ni­ko­wi?
• Czy jeże­li podo­ba­ją nam się kon­kret­ne kom­po­nen­ty inter­fej­su to aby na pew­no są one uży­tecz­ne i będą paso­wać do kon­tek­stu uży­cia w naszym pro­duk­cie?

Podsumowanie

Jako kon­klu­zję tego oraz poprzed­nie­go wpi­su pre­zen­tu­je­my listę grze­chów w ana­li­zie kon­ku­ren­cji:

• Porów­ny­wa­nie się z kon­ku­ren­cją bez wie­dzy, czy docie­ra­my do tej samej gru­py doce­lo­wej;
• Brak jakiej­kol­wiek obser­wa­cji kon­ku­ren­cji;
• Brak wie­dzy o potrze­bach użyt­kow­ni­ka;
• Zakła­da­nie, że w serwisie/aplikacji moż­na umie­ścić nie­skoń­czo­ną ilość funk­cjo­nal­no­ści od kon­ku­ren­cji (“jak komuś się nie spodo­ba to prze­cież nie musi korzy­stać”);
• Zakła­da­nie, że jeże­li u kogoś coś dzia­ła to u nas na pew­no też zadzia­ła;
• Kopio­wa­nie ele­men­tów inter­fej­su bez uprzed­niej kry­ty­ki pod wzglę­dem uży­tecz­no­ści;
• I naj­waż­niej­sze – brak wła­snej stra­te­gii połą­czo­ny ze śle­pym podą­ża­niem za inter­fej­sa­mi kon­ku­ren­cji.

Co do same­go użyt­kow­ni­ka, to pole­ca­my po pro­stu zawcza­su zba­dać jego potrze­by. Co do uży­tecz­no­ści samych kom­po­nen­tów możesz odwie­dzić http://ui-patterns.com/patterns i tam poczy­tać o tym co cechu­je dany pat­tern.

Źródła: 

• https://www.nngroup.com/articles/copying-a-famous-sites-design/
• http://uxdesign.pl/o-innowacji/