Ползваемостта зависи от чистотата на кода

Вярно е, че чистият код е важен за качеството на разработвания продукт, но съвсем не е задължително и достатъчно условие за постигане на ползваемост. Често се очаква от специалистите по ползваемост да са инспектори по чистотата на кода. Нещо като по-различен вид технически лица, които правят оценка и одит на качеството на кода.

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

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

Тестване за ползваемост = фокус група

Фокус група и тестване за ползваемост не са синоними. Това са два различни начина за проучване. При тестването за ползваемост се работи с всеки един участник поотделно, а във фокус групите – с една група от няколко души едновременно.

При фокус групите резултатите се изкривяват от феномени, типични за групите от хора. Например във всяка група от хора бързо се обособява лидер, който налага мнението си, а повечето членове желаят да подкрепят неговата гледна точка. Именно за да се избегнат подобни проблеми и изкривяване на резултатите, тестовете за ползваемост се провеждат в индивидуална сесия с всеки участник поотделно.

Тестването за ползваемост се прави, когато продуктът е готов Абсолютно погрешно.

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

Последиците често са доста неприятни. По същество, едно тестване за ползваемост разкрива множество проблеми и не дава отлична оценка. Открити накрая, голяма част от проблемите са доста сложни и скъпи за отстраняване, тъй като изискват преправяне на вече разработени елементи на сайта. Съответно сериозните проблеми остават неотстранени. Освен това показването на проблеми в края на проекта, след като хората, работили по него, са вложили много труд, желание и старание, неминуемо води до пораждането на лоши чувства в екипа. Хората се чувстват обидени от критикуването на работата им.

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

Тестването за ползваемост оскъпява продукта и удължава работата

Прочетохте ли предишния мит? Да, до оскъпяване може да се стигне, ако ползваемостта се сложи в края на проекта, когато всичко вече е готово. Истината е, че работата по ползваемостта на продукта намалява разходите и поевтинява разработката и поддръжката. Основните причини:

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