Тестване за ползваемост

Тестването за използваемост е изследователски метод, при който реални или представителни потребители се опитват да изпълнят специфични задачи, използвайки продукт, прототип или уебсайт, докато наблюдател записва къде успяват, къде се затрудняват и как описват преживяването си, обикновено като мислят на глас, докато работят. За разлика от анкетите или анализите, които отчитат какво са правили или казвали потребителите след факта, тестването за използваемост наблюдава поведението директно и в контекст, което го прави един от най-директните начини за установяване дали даден интерфейс е наистина лесен за разбиране и използване, а не просто се предполага, че е такъв от екипа, който го е създал.

Методът е важен, защото проблемите с интерфейса, които са невидими за хората, които са ги проектирали, често са очевидни за потребителите, които го използват за първи път – празнина, често обяснявана с проклятието на знанието, при която дизайнерите и заинтересованите страни, които са дълбоко запознати с даден продукт, се затрудняват да забележат неяснотата, с която новият потребител се сблъсква веднага. Широко цитирани изследвания за използваемост установяват, че тестването с едва петима участници обикновено разкрива голяма част, често цитирано като приблизително 85 процента, от проблемите с използваемостта, присъстващи в даден интерфейс, поради което тестването за използваемост обикновено се провежда с малки, итеративни кръгове от участници, а не с мащабни проучвания, което позволява на екипите да тестват, коригират и тестват отново бързо, вместо да чакат да съберат голяма извадка, преди да направят каквито и да било промени.

Тестването за използваемост се провежда в няколко формата: модерирано тестване, при което фасилитатор насочва участник през задачи в реално време, лично или чрез видео, и може да задава последващи въпроси, за да изясни объркващи моменти; немодерирано дистанционно тестване, при което участниците изпълняват задачи самостоятелно, използвайки платформа за тестване, като екранът и гласът им се записват за по-късен преглед, предлагайки по-бързо и по-евтино събиране на данни с цената на невъзможност за проучване на реакциите в момента; и партизански тестване, неформален, нискобюджетен подход, който събира бърза обратна връзка от наличните участници, като колеги или минувачи, полезен за ранно валидиране, когато пълно проучване все още не е необходимо. Тестовите сесии обикновено са структурирани около специфични, реалистични сценарии на задачи, а не около отворено проучване, а успехът се оценява с помощта на мерки като процент на завършване на задачите, време за изпълнение на задачата, брой грешки и субективна оценка на участника за лекота на използване, често събирани чрез стандартизиран инструмент като Скалата за използваемост на системата.

Често срещано погрешно схващане е, че тестването за използваемост и A/B тестването служат на една и съща цел, когато всъщност те отговарят на различни въпроси на различни етапи: тестването за използваемост идентифицира защо потребителите се затрудняват с даден интерфейс, преди той да бъде изграден или пуснат широко, обикновено върху прототип или вече работещ, но невалидиран дизайн, докато A/B тестването измерва кой от няколко вече изградени варианта се представя по-добре в голям мащаб, след като е наличен трафик. Чест капан в самото тестване за използваемост е набирането на участници, които не са представителни за действителната целева аудитория, като например тестване на работен процес на корпоративен софтуер с участници, които не са запознати с основния бизнес процес, което води до подвеждащи точки на триене, които не биха се появили при истинските целеви потребители. Воденето на участниците чрез съвети или предложения по време на сесия, вместо да им се позволи да се затрудняват и да наблюдават тези затруднения честно, е друга често срещана грешка, която подкопава валидността на констатациите.

В рамките на CRO и UX При консултантски ангажименти, тестването за използваемост често се използва както за диагностика, за да се разбере защо съществуващ поток се представя зле, така и за валидиране преди широкомащабно пускане на редизайн, като се тества нов прототип с малка група представителни потребители, за да се открият основни проблеми с използваемостта, преди да се ангажират ресурси за разработка и тестване с пълен A/B тест. Констатациите от тестването за използваемост обикновено се синтезират в приоритизиран списък с проблеми, често класирани по тежест и колко участници са се сблъскали с всеки един от тях, който след това се подава директно към промените в дизайна или експерименталните хипотези, които съставляват по-широката пътна карта за оптимизация на клиента.

Конкретен пример демонстрира ефективността на метода: екип, който тества преработена страница с настройки на акаунта с петима участници, може да забележи, че четирима от петимата не успяват да намерят опцията за промяна на предпочитанията си за известия, като всеки от тях независимо търси на едно и също грешно място в интерфейса. Това единично, силно последователно откритие, получено от малък и евтин кръг от тестове, обикновено е достатъчно основание за преместване на настройката преди стартирането, без да е необходимо по-голямо и по-отнемащо време проучване, за да се потвърди това, което вече е наблюдавано като надеждно и многократно неуспешно при почти всеки тестван участник.