Чотири рази не адекватний, Комерція, Різне, статті

Брак «юзабіліті» – одна з найгостріших проблем сучасних російських програм. Ми вже навчилися робити якісні, швидкі і надійні продукти, але поки не навчилися робити їх зручними для користувача. В не меншою, якщо не більшою мірою те ж відноситься і до Web-розробкам. Які ж основні помилки, чинені розробниками, і як з ними боротися?


Регулярно займаючись редизайном інтерфейсу програмного забезпечення, ми виявили, що в більшості випадків стикаємося з однотипними проблемами, викликаними настільки ж однотипними промахами розробників при проектуванні ПЗ, а саме:



  1. Інтерфейс не адекватний особливостям користувачів.

  2. Інтерфейс не адекватний середовищі використання системи.

  3. Інтерфейс не адекватний змістовної діяльності користувачів.


  4. Інтерфейс неадекватно відображає об’єкти системи і зв’язки між ними.


Зрозуміло, цим мінуси інтерфейсу вітчизняного ПЗ не вичерпуються – перераховані тільки типові випадки. Крім того, варто зазначити, що ці недоліки, як правило, не існують окремо, і на практиці кожна система має тим чи іншим їх набором.


Нижче ми спробуємо коротко описати кожен з них, причини їх виникнення, приклади прояву і так далі, а також постараємося сформулювати правила, дотримуючись яких можна знизити ймовірність їх виникнення.


Інтерфейс не адекватний особливостям користувачів



Будь розробник, починаючи проектувати систему, завжди визначає апаратні вимоги до неї. Навпаки, вимоги, пов’язані з обмеженням і особливостям користувачів системи, не визначаються майже ніколи. В результаті виходить система, не орієнтована ні на кого. Її інтерфейс в кращому випадку суперечливий (наприклад, один модуль розрахований на досвідчених користувачів, а інший на новачків, хоча обидва модулі призначені для однієї і тієї ж категорії), а в гіршому – підходить тільки тим людям, які свідомо не будуть користуватися системою.


Як приклад можна навести такий випадок. В деякій системі, розрахованої на найширшу аудиторію, в якості основних елементів управління широко застосовувалися складні дерева (treeview), не призначені для тривалої роботи з ними (їх використання вимагає точної моторики, і при тривалій роботі великий відсоток людських помилок). Оскільки спочатку весь інтерфейс системи був спроектований в розрахунку на ці дерева, його переробка виявилася неможливою з економічних причин.


Єдиним вирішенням цієї проблеми є формалізація користувальницьких вимог до системи до початку її проектування, оскільки переробляти готову систему набагато дорожче. При цьому слід скласти список властивостей користувачів, що включає в себе:



  1. Навики роботи з комп’ютером. Хорошим критерієм тут є стаж роботи з комп’ютером.

  2. Знання предметної області. Як правило, це найбільш важка частина, оскільки користувачі у будь-якої системи різні. Крім того, на етапі проектування системи розробники часто самі не володіють знанням предметної області. Цей пункт списку повинен містити, наприклад, такі відповіді: який у користувача досвід роботи з подібними системами, яке знання термінології, яка здатність навчатися і так далі.

  3. Очікування від системи. Якщо проектована система не перша для користувачів, спочатку її відмінності від конкурентів – наприклад, від попередньої версії – будуть сприйняті здебільшого негативно, оскільки переучуватися не подобається нікому (зрозуміло, це не стосується реалізації давно очікуваної функціональності). Тому часто розумно вибрати не найефективніший, але звичне і не потребує перенавчання рішення.

  4. Фізичні параметри користувачів. В залежності від віку та деяких інших факторів фізичні параметри людей змінюються в досить широких межах. Наприклад, інтерфейс, розрахований на людей похилого людей, повинен бути візуально більш контрастним, ніж для молоді, оскільки з віком зір слабшає.

Отриманий список необхідно враховувати при оцінці всіх рішень, прийнятих при розробці системи, інакше інтерфейс не буде відповідати вимогам користувачів.


Інтерфейс не адекватний середовищі використання системи



Крім адекватності особливостям користувачів, інтерфейс повинен бути адекватним середовищі, в якій використовується система. Основні складові цього середовища такі:




  1. Тимчасові обмеження на виконання дії. Якщо заздалегідь відомо, що певна операція повинна виконуватися швидко і / або не сповільнювати інші операції, її інтерфейс потрібно проектувати, враховуючи в Насамперед обмеження швидкості. Якщо не визначити заздалегідь, яка характеристика інтерфейсу в кожному конкретному випадку найбільш важлива, ймовірність її досягнення буде невелика – фактично, задовольнити вимоги до швидкості можна буде тільки випадково.



  2. Наявність перерв у спілкуванні користувачів із системою. Робота з багатьма системами увазі, що користувачі постійно будуть відволікатися. Наприклад, користувач системи управління проектом більшу частину часу працює над самим проектом, звертаючись до комп’ютера лише час від часу. У таких випадках завдання інтерфейсу – допомогти повернутися до роботи з системою: наприклад, показувати користувачеві, що саме змінилося за час його відсутності.



  3. Дозвіл моніторів. На роботу впливає не тільки дозвіл екрана в пікселях, але і його фізичний розмір: якщо фізична дозвіл велике, елементи управління стають занадто малими і нерозбірливими. І якщо система розробляється без урахування цього чинника, велика ймовірність появи так званої «проблеми режиму Large Fonts» (рис. 1).

    Рис. 1

    Рис. 1. Якщо інтерфейс програми не був розроблений у розрахунку на можливе включення режиму Large Fonts,
    всі елементи управління «попливуть». Добре ще, якщо жоден елемент не зникне, будучи закритий іншим.



  4. Швидкість роботи самої системи. На жаль, розробники дуже часто розглядають швидкість роботи як другорядний фактор. Безумовно, у багатьох випадках швидкодія може бути принесено в жертву заради іншої характеристики системи, але в деяких ситуаціях саме воно є найбільш важливим фактором. Наприклад, якщо користувачі очікують високої швидкості роботи (на щастя, вони очікують її нечасто), повільна система стане джерелом значного суб’єктивного незадоволення. Інший приклад: нерідко в автоматичних системах є операції, що виконуються користувачем під час розмови по телефону (Такі багато операцій у брокерів, операторів складів та ін.) Якщо подібна операція буде займати довгий час, проблем розробнику не уникнути.


Як і у випадку неадекватності інтерфейсу особливостям користувачів, ці проблеми легко вирішуються формалізацією відповідних вимог до системи на стадії її проектування.


Інтерфейс не адекватний змістовної діяльності користувачів



Цю проблему без перебільшення можна назвати самою типовою для російського програмного забезпечення. Суть її в тому, що структура користувальницького інтерфейсу приведена у відповідність з інформаційними потоками (структурою об’єктів) всередині самої системи, а не зі структурою реальної діяльності користувачів.


Як наслідок, інтерфейс «зашумлен» інформацією, релевантної об’єкту, з яким працює користувач, але не потрібною йому або зараз, або взагалі (оскільки різним співробітникам може вимагатися різна інформація). Інший прояв цієї проблеми діаметрально протилежно: інтерфейсні елементи (наприклад, що виводиться інформація або блоки введення інформації) є атрибутами різних об’єктів, відповідно розробники розміщують їх на різних екранах, ігноруючи ту обставину, що для виконання типових операцій користувачеві необхідно взаємодіяти одночасно з усіма цими інтерфейсними елементами.


Наведемо типовий приклад. При оптимізації інтерфейсу великий ERP-системи був проаналізований один із діалогів запиту даних. У загальній складності в цьому вікні було п’ятнадцять полів введення і шість перемикачів (Рис. 2). Як показав аналіз інтерв’ю користувачів, в роботі постійно були потрібні тільки два поля введення і два перемикача, а ще одне поле введення потрібно лише зрідка. Таким чином, екран містив п’ятнадцять непотрібних елементів управління, при цьому основні елементи навіть не були розташовані в перших рядах, на них не позиціонувався курсор, і вони ніяк не були виділені. Більш того, більшість користувачів не могло відповісти на питання, що означають деякі з наявних полів.

Рис. 2

Рис. 2. Подібного роду діалогові вікна типові майже у всіх системах автоматизації.
Наш досвід показує, що в більшій частині випадків такі вікна можуть бути помітно спрощені.


Зворотною стороною цієї проблеми можна вважати універсальність: дешевше розробити єдине вікно, з яким буде працювати кілька різних службовців (бухгалтер, директор, менеджер з продажу та т. д.), ніж окремі вікна для кожного з них. Однак універсальність обертається неефективністю інтерфейсу (і, як наслідок, системи в цілому).


Таким чином, інтерфейс повинен в першу чергу визначатися структурою діяльності користувача, а не структурою об’єктів, з якими користувач взаємодіє в процесі роботи.


Інтерфейс неадекватно відображає об’єкти системи і зв’язки між ними



Крім змістовної діяльності користувачів, інтерфейс повинен бути адекватний власне об’єктів системи, що виходить не завжди. Без цього інтерфейс системи не буде однозначний, а неоднозначність призводить до появи людських помилок. Більшість проблем цього роду виникає через вплив наступних факторів:




  1. Взаємне розташування об’єктів на екрані не відповідає їх логічного зв’язку та / або їх важливості
    На жаль, нормою є ситуація, при якій найважливіші об’єкти (і, відповідно, найбільш важливі дії) або затуляють від користувача менш важливими, або перебувають там, де користувач не очікує їх знайти. Наприклад, нам відома програма, що виконує тільки одну функцію, при цьому викликати її можна тільки з меню або за допомогою піктограми на панелі інструментів, а потрібна піктограма не забезпечена підписом і губиться серед інших піктограм панелі. Якби кнопка виклику цієї функції була розміщена ближче до центру вікна, була б добре помітна і забезпечена підписом, легкість роботи збільшилася б на порядок.



  2. В інтерфейсі багато надмірності
    Якщо заздалегідь невідомо, як саме користувачі будуть працювати з системою (а дізнатися це неможливо без тестування прототипу інтерфейсу), у розробників виникає спокуса багаторазово дублювати кошти виклику об’єктів (наприклад, дати можливість перейти до одного й того ж екрану кількома різними способами) в розрахунку на те, що велика кількість цих коштів допоможе користувачеві знайти хоча б одне. Це призводить до того, що користувач, знайшовши небудь метод, змушений згодом фільтрувати всі інші – внаслідок чого в інтерфейсі виникає шум. В деяких випадках виявляється й інша проблема: користувач фіксується на першому знайденому методі і ігнорує всі інші, навіть якщо вони більш ефективні. Таким чином, надмірність, як правило, знижує ефективність інтерфейсу.



  3. Різні частини системи розробляються різними розробниками без узгодження один з одним
    Дуже мало команд розробників володіє внутрішніми стандартами на інтерфейс, а без їх використання організаційно неможливо дотримуватися однакових правил при створенні інтерфейсу.



  4. Інтерфейс розробляється без врахування сформованих стандартів (Окремий випадок попередньої проблеми).


Системний підхід до проектування інтерфейсу, а також використання стандартизованих інтерфейсних бібліотек (до них відносяться не тільки бібліотеки інтерфейсних елементів, але і бібліотеки термінів) здатні успішно вирішити проблеми такого роду, тим більше що ці нехитрі заходи не вимагають від розробників спеціальних навичок.


Висновки


Наведена вище типологія проблем, частково збігаючись з іншими подібними типологіями (наприклад, із стандартів ISO), значно від них відрізняється: ми не ставили перед собою завдання охопити весь можливий коло проблем, але лише позначили найтиповіші з них, характерні для програмних продуктів, що розробляються в Росії. Таким чином, запропонована типологія носить суто практичний характер: використовуючи її, розробники зможуть заздалегідь діагностувати і виправляти можливі (і ймовірні) проблеми при проектуванні користувальницького інтерфейсу систем.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*