1. Принципи на проектирането на потребителски интерфейс 5 Взаимодействие с потребителя

Разгледаната цялост може да се счита от ниско ниво. Очаква се от проектантите винаги да се стремят да го постигнат в своя потребителски интерфейс. Целостта на високо ниво често е също много желателна. Например може да е уместно да се поддържат едни и същи операции като например печат (Print), копиране (Copy) и др. за всички типове системни слоеве. Въпреки това трябва да изтъкнем, че пълна цялост не е нито възможна нито желателна. Ако например е удобно да изтриваме обекти от desktop-а като ги влачим до кошчето, то би било неестествено да изтриваме текст от текстообработваща програма по този начин.

Принципът за минимизиране на т.нар. елемент на изненадата (Minimal surprise) е също уместен, защото потребителите много се дразнят когато системата се държи по неочакван за тях начин. Докато използват системата, потребителите си изграждат мислен модел за това как тя работи. Ако действие в един контекст водят до някаква промяна, оправдано е да се очаква, че същото действие в друг контекст ще доведе до подобна промяна. Ако се случи нещо съвсем различно, потребителят е както изненадан, така и объркан. Следователно проектантите на интерфейса трябва да гарантират, че подобните действия ще имат и подобен ефект.

Принципът на възстановимост (Recoverability) е важен, защото потребителите неизбежно правят грешки, когато използват системата. Интерфейсът трябва да ги минимизира (например използването на командно меню избягва грешките при писане), но те не могат никога напълно да се елиминират. Потребителските интерфейси трябва да съдържат средства, позволяващи потребителите да възстановяват данните ако сгрешат. Това може да се осъществи по 2 начина:

1. 
   Потвърждение на деструктивни операции. Ако потребителите изберат действие, което е потенциално деструктивно, би следвало от тях да се поиска потвърждение дали те наистина желаят това и едва тогава да се унищожава каквато и да е информация.
   
2. 
   Предоставяне на Undo-средства. Undo възстановява до състояние на системата, каквото е било преди извършеното действие. Множествени нива на undo са още по-полезни, тъй като потребителите не винаги веднага разпознават грешката, която са направили.
   

Принципът за разнородност на потребителите (User diversity) се основава на факта, че много интерактивни системи може да се използват от различни категории потребители. Някои може да са случайни потребители, които прецедентно работят със системата, други може да са опитни (power users), които да използват системата няколко часа всеки ден. Случайните потребители се нуждаят от интерфейси, които да ги ръководят, докато опитните изискват бързи бутони, които да им позволява да работят колкото е възможно по-бързо. Други потребители може да имат различни увреждания и ако е възможно, интерфейсът трябва да бъде приспособим и към тях. Следователно може да е необходимо да се предоставят средства за представяне на увеличен текст, замяна на звук с текст или за уголемени бутони и т.н.

Принципът за разнородни потребители може да бъде в конфликт с други принципи за разработка на GUI, защото някои типове потребители може да предпочитат бързото взаимодействие с програмата вместо (например) да държат на цялостност на интерфейса. По подобен начин, нивото на ръководене на потребителя може да бъде различно за различните категории потребители. Следователно може да се окаже невъзможно разработване на помощ за всички категории. Проектантът на интерфейса трябва неизбежно да направи компромис в зависимост от реалните потребители за съответната система.

2. Взаимодействие с потребителя (User interaction)

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

1. 
   Директно въвеждане (direct manimulation), където потребителят директно работи с обектите на екрана, например за да изтрие файл, потребителят може да влачи в кошчето.
   
2. 
   Избор от меню (menu selection), където потребителят избира команда от списък с възможности (меню). Често в този случай, в това време се избира друг екранен обект и командата работи с него. При този метод, за да се изтрие файл, потребителят го маркира и избира команда "изтрий" (delete).
   
3. 
   Попълване на форми (Form fill-in), където потребителя попълва полета във форма. Някои полета, може да имат асоциирани менюта и формата може да има командни бутони, които при натискане да изпълнят операция. Би изглеждало изкуствено да се изтрива файл от форма-базиран интерфейс (form-based interface). Това би било свързано с изписване на името на файла и последващо натискане на бутон за изтриване.
   
4. 
   Команден език (command language), където потребителят въвежда специални команди и съответни параметри, за да укаже на системата какво да прави. За да изтрие файл, потребителят въвежда delete-команда с името на файла, като параметър.
   
5. 
   Естествен език (natural language). Потребителят използва естествен език. В този случай, за да изтрие файл, потребителят може да напише "Изтрий файла с име ...".
   

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

Потребителските интерфейси в интернет са базирани основно на HTML (описателния език, използван за WEB страници) заедно с езици като Java, която може да асоциира програми с компоненти на страницата. Докато тези WEB-базирани интерфейси често се проектират за случайни потребители, те често използват форма-базирани интерфейси. Възможно е да се конструира интерфейс за директно въвеждане в WEB-страницата, но това все още е сложна програмна задача.

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

Това разделяне на представянето, взаимодействието и елементите, които са замесени в потребителския интерфейс е фундаментално за принципа "Модел-Изглед-Управление" (Model-View-Controller, накратко MVC). Той е сравним с Seeheim-модела, но се използва за интерфейс на обекти, вместо за цели приложения.

3. Представяне на информацията (Information presentation)

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

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

MVC-метода, който е бил достъпен най-напред в Smalltalk, е ефективен начин да се поддържат множество представяния на данни. Потребителите могат да взаимодействат с всяко от тях, посредством стил, който да им съответства. Данните, които се представят са капсулирани в моделен обект. Всеки от тях може да е асоцииран с множество отделни визуални обекти, всеки от които да има собствено представяне на модела на екрана.

Всеки визуален обект има асоцииран контролен обект, който управлява потребителския вход и средствата за взаимодействие. Затова моделът, който представя числови данни, може да има изглед, който да представя данните като хистограма, както и изглед в табличен вид. Моделът може да се редактира с промяна на стойностите в таблицата или с удължаване/скъсяване на стълбовете на хистограмата.

Намирането на най-добрия начин за представяне изисква познаване на самата информация, на компетентността на потребителите и начина по който те използват системата. При решаване как да се представи информацията, дизайнерът трябва да вземе предвид няколко фактора:

1. 
   Дали потребителят се интересува от прецизиране на информацията или от връзки между различните стойности?
   
2. 
   Колко бързо данните се променят? Би ли трябвало промените в стойностите да се индицират веднага на потребителя?
   
3. 
   Трябва ли потребителят да предприеме някакви действия в отговор на промени на информацията?
   
4. 
   Трябва ли потребителят да взаимодейства с изобразената информация посредством интерфейс за директен вход?
   
5. 
   Дали информацията, която се изобразява е текстова или числова? Дали конкретните стойности на елементите са толкова важни?
   

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

Например може да разгледаме система, която записва и сумира месечните продажби на една компания. Следната фигура илюстрира как една и съща информация може да се представи в текстов и в графичен вид.

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

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

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

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

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

Графичното осветяване (graphical highlighting) може също да се използва за привличане на потребителското внимание върху отделни части от екрана. Въпреки това, ако тези промени се случват бързо, визуализацията може да се възприеме като мигане. Това разсейва и дразни потребителите.

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

1. 
   Когато информацията, събрана от множество източници се показва като климатологична карта с изобари и климатични фронтове и др.
   
2. 
   Телефонна мрежа може да се изложи графично като свързани множество възли в мрежов управляващ център.
   
3. 
   Състоянието на химически завод се визуализира с представяне на налягания и температури в свързано множество съдове и тръбопроводи.
   
4. 
   Молекулярен модел се представя и манипулира в 3 измерения (3D), с използването на система за виртуална реалност.
   
5. 
   Множество WEB страници се представя като хиперболично дърво.
   

3.1. Цветове при проектиране на интерфейси

Цветът може да подобри интерфейсите, подпомагайки потребителите да разберат и управляват по-сложни представяния. Въпреки това, някои дизайнери лесно пропускат тази възможност и създават интерфейс, който е визуално неатрактивен и предразполагащ към грешки. Независимо от това, като основен принцип, дизайнерите на интерфейсите трябва да подхождат консервативно в използването на цветовете. Shneiderman (1998) дава 14 основни насоки за ефективно прилагане на цветовете в интерфейсите. Най-важните са:

1. 
   Ограничете броя използвани цветове и бъдете консервативен в използването им. Не е желателно да използвате повече от 4 различни цвята в един прозорец и не повече от 7 за целия интерфейс.
   
2. 
   Използвайте промяна в цвета за да означите промяна на състояние в системата. Ако имаме смяна на цвят на екрана, то това би означавало настъпване на значимо събитие. Така за показателя за горивото, смяната на цвета може да означава че то е на привършване. Цветовото осветяване е особено важно за комплексни екрани, където се визуализират стотици различни елементи.
   
3. 
   Използвайте цветови означения в задачите, които потребителите опитват да изпълнят. Ако те трябва да открият някои аномалии в данните - оцветете съответните данни; аналогично използвайте цветове за да се открият лесно подобия и аналогии.
   
4. 
   Влагайте отделните цветове (color coding) обмислено и обобщавайте схемите на цветоразделяне за цялата система. Ако една част на системата изобразява съобщения за грешки в червено, то и останалите подсистеми трябва да следват това правило. Тогава не би следвало да използвате червено за нищо друго. Ако го направите, потребителят може да го възприеме като съобщение за грешка. Трябва да сте наясно, че някои категории потребители правят предположения за определени цветове.
   
5. 
   Бъдете внимателни в подбора на цветни комбинации (color pairings). Поради физиологията на окото, хората не могат да фокусират червено и синьо едновременно. Естествено, има и други цветови съчетания, които също да са визуално смущаващи или трудни за възприемане. Последователното редуване на тези цветове може да доведе до умора на очите.
   

Един цвят не можа да се използва за две неща. Около 10 процента от хората имат някаква форма на далтонизъм и може да не разберат смисъла, който сте заложили. Човешките възприятия за цвят са различни и има различни конвенции в различните професии за смисъла, който носят определени цветове. Потребителите от различни среди може подсъзнателно да разберат един и същ цвят по различни начини. Например, за шофьора червеното обикновено означава опасност, докато за химика то означава горещо.

4. Система за помощ (User support)

• 
  съобщенията, издавани от системата в отговор на потребителски действия;
  
• 
  своевременната система за помощ (help);
  
• 
  документацията, предоставена заедно със системата.
  

4.1. Съобщения за грешки

Образователното ниво и опита би трябвало да са предвидени когато се разработват съобщенията за грешки.

Пример: Да предположим, че системен потребител е мед. сестра в интензивно отделение. Състоянието на пациентите се следи от компютърна система. За да се разгледат текущите данни (температура, пулс и др.) за даден пациент, системният потребител трябва да избере "Покажи" (Display) и да въведе името на пациента в диалога, както е показано:

В този случай, да предположим, че името на пациента е Pates вместо Bates и въведеното от сестрата име не може да бъде разпознато. Системата генерира съобщение за грешка. Съобщенията за грешки би трябвало винаги да са учтиви, стегнати и съдържателни. Не трябва да бъдат обидни или да издават звукови сигнали, които биха смутили потребителя. Когато е възможно, съобщението трябва да предлага начин за коригиране на грешката. Съобщенията трябва да са свързани с контекстно ориентирана система за помощ.

Следната фигура показва примери за добри и лоши съобщения за грешки:

Съобщението вляво е лошо разработено. Има негативен смисъл (индиректно обвинява потребителя за направената грешка), не е пригодено към уменията на потребителя и нивото му компетентност и не е съобразено с контекста. То не предлага начин за решаване на проблема, Използва термини, специфични за системата (ID) вместо потребителски-ориентиран език. Съобщението вдясно е по-добро. Позитивно е, загатвайки, че проблемът е системен, вместо потребителски. Описва го с термини, от средата на мед. сестра и предлага лесен начин да се коригира грешката единствено с натискането на бутон. Контекстно-ориентирана система за помощ може допълнително да се извика.

4.2. Проектиране на система за помощ (Help system design)

Помощните системи (help systems) би следвало да предлагат много входни точки. Те би трябвало да позволяват на потребителя да влезе в помощната система от върха на йерархията и да проследява принципа за работа. Освен това обаче, те може да влязат в системата за да получат обяснение за системна грешка или да искат информация за определена команда.

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

Може да възникне проблем, когато потребителят влезе в системата след допускане на грешка и впоследствие да продължи, следвайки вътрешните връзки. За кратко време той може безнадеждно да се изгуби. Тогава трябва да напусне системата и да влезе отначало от позната вече входна точка.

Показването на помощната информация в няколко прозореца може да облекчи тази ситуация.

На фигурата е показан екран с три помощни прозореца.

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

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

Прозорецът "История" (History) показва секциите, които вече са били посетени. Би трябвало да е възможно връщане към тях с избиране на елемент от списъка. Навигационния прозорец (Map) е своеобразна карта на разпределението на мрежата на помощната система. Текущата позиция би следвало да е осветена с различен цвят, със сянка или (както е в нашия случай) отбелязана с анотация.

Потребителите трябва да могат да се местят по секциите посредством препратките от настоящата, чрез избор от "История" (за да препрочетат предишна или да сменят направлението) или с маркиране директно от "Карта" (Map).

Помощните системи може да се вграждат като набор от взаимосвързани интернет страници или с използване на обща hypertext система, която може да се интегрира в приложението. Йерархията може лесно да се интерпретира с отделни части от съобщението, които да представляват препратки (links). Интернет системите имат предимството, че могат лесно да се вградят и не изискват специален софтуер. Въпреки това може да се окаже сложно да се свържат към приложението като контекстно-ориентирана помощ.

4.3. Потребителска документация

За да се гарантира това трябва да има поне пет свитъка (или различни глави в общ документ), които да се доставят със софтуерната система.

Тези документи са:

1. 
   Функционално описание (functional description), което би трябвало съвсем накратко да описва услугите, които системата предлага. Потребителите могат да четат този материал като въвеждащо ръководство и да решат дали системата е това от което имат нужда.
   
2. 
   Инсталационно ръководство (installation document), което да подпомага потребителя при инсталацията на продукта. То следва да описва инсталационните дискове, които доставят системата, файловете (или поне структурата от папки) на тях, минималните и препоръчителни хардуерни изисквания и др. От него се очаква да инструктира при инсталацията, а също и да укаже как да се настроят конфигурационните файлове.
   
3. 
   Въвеждащо ръководство (introductionary manual), което да представлява неформално въведение в системата, описвайки нейното "класическо" приложение. То описва как да се навлезе и как крайните потребители могат да извлекат полза от общите системни средства. Препоръчително е да бъде илюстрирано с примери, също и как да се коригират допуснати грешки и как да се върнем обратно към нормален процес. Caroll (1982) предполага, че възстановяването от грешки и минимизиране на информацията, която потребителите трябва да четат (с елиминиране на излишеството) е ефективен начин да се организират въвеждащи ръководства.
   
4. 
   Справочно ръководство (reference manual). То има за задача да опише системните средства и тяхното използване, предоставя списък от системни съобщения и възможни причини, както и описва как да се възстанови работния режим при откриване на грешки.
   
5. 
   Ръководство на администратора (administrator's manual) е необходимо само за някои типове системи. То описва съобщенията, генерирани, когато системата взаимодейства с други такива и как да се реагира в съответните ситуации. Ако работата на системата е пряко свързана с определен хардуер, то би трябвало да обяснява как да се възстановява от хардуерни проблеми, как да се подвържат нови периферни устройства и т.н.
   

5. Оценка на интерфейса (Interface evaluation)

В идеалния случай оценката се води съобразно спецификацията за полезност, базирана на следните атрибути:

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

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

Има много по-прости, по-евтини техники за оценка на потребителски интерфейс, които да открият недостатъците на отделен потребителски интерфейс:

1. 
   Въпросници (questionnaires), които събират информация какво потребителите мислят за интерфейса;
   
2. 
   Наблюдение на потребителите (observation of users) по време на работа със системата "разсъждавайки на глас" за това как те опитват да използват системата за да извършат определена задача;
   
3. 
   Кадри от видеозаписите (video snapshots) от типично използване на системата;
   
4. 
   Включването в софтуера на код, който събира информация за най-използваните средства и най-честите грешки (instrumenting code).
   

Изследване на потребителите с използването на въпросници (questionnaires) е относително евтин начин за оценяване на интерфейса. Въпросите трябва да са по-скоро конкретни отколкото общи. Безполезно е да се задават въпроси като: "Моля, коментирайте полезността на интерфейса!" понеже отговорите може да варират толкова, че да е невъзможно да се обобщят. Вместо това, конкретни въпроси като: "Моля оценете разбираемостта на съобщенията за грешки по скала от 1 до 5 (1 – напълно ясни, 5 - непонятни)!" са много по-добри. Те са едновременно лесни за отговаряне и много по удобни за извличане на информация за подобряване на интерфейса.

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

Методът, базиран на наблюдение (observation) просто включва наблюдение на потребителите докато те работят със системата, следейки за средствата, които използват, грешките, които правят и т.н. Това може да бъде допълнено от сесии с "размисли на глас", където потребителите говорят за това какво опитват да постигнат, как разбират системата и как опитват да използват системата за да изпълнят задачите си.

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

Анализът на записи позволява на дизайнера да разбере, ако интерфейсът изисква твърде често движение на ръката (проблем с някои системи е, че потребителите трябва редовно да местят ръцете си от клавиатурата на мишката и обратно) и да проследи дали е наложително неестествено местене на погледа. Интерфейс, който изисква честа смяна на фокуса може да означава, че потребителят прави повече грешки, защото пропуска части от дисплея.

Прилагането на стробиращ код (instrumenting code), който да събира статистики за използване позволява на интерфейсите да се подобрят по много начини. Могат да се установят най-общите операции. Интерфейсът може да бъде организиран така, че те да бъдат най-бързите за избор. Например ако се използват контекстното и/или падащото меню, най-често използваните операции би следвало да са най-горе, докато деструктивните – в долния край. Стробиращият код позволява още, откриване на команди, предразполагащи към грешки.

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