Самая фундаментальная концепция юзабилити

Понятие юзабилити включает в себя много элементов.

Это создание удобных в освоении интерфейсов. Это предотвращение ошибок и сокращение времени, требуемого для выполнения задачи.

Существует несколько методов, помогающих улучшить юзабилити интерфейса. Хотя довольно сложно определить концепцию, которая охватывала бы всю идею юзабилити, мне кажется, что в основе всех этих методов лежит какая-то общая концепция. Она заключается в том, что разработчик — это не пользователь.

Я хочу сказать, что люди, создающие интерфейс, отличаются от тех, что его используют.

Разработчики тоже могут быть пользователями. В редких случаях, разработчик, занимавшийся программированием интерфейса может стать одним из тех, кто этот интерфейс будет использовать.

Но из-за высокого спроса на программное обеспечение, мобильные и веб-приложения, скорее всего, окажется, что разработчик почти ничего не знает о целевой аудитории, и никогда не будет использовать приложение, которое создает.

Причина того, почему эта концепция имеет такое значение, заключается в том, что описание работы приложения, программирование и создание дизайна, включают в себя создание предположений о том, как люди будут реагировать и взаимодействовать с элементами дизайна. Техническая структура языков программирования и функциональные требования преобладают над эфемерными пользовательскими целями.

Проблема, как правило, усугубляется тем, что сведения о пользователях и функциональных особенностях предоставляются разработчикам через третьих лиц (продуктовых менеджеров, бизнес-аналитиков, и т.д.), и они почти не контактируют с самими пользователями.

Разработчик = Пользователь

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

Алан Купер, отец языка Visual Basic, берет идею Зимбардо, и говорит, что чтобы стать хорошим программистом, человек должен «сопереживать природе и нуждам компьютера. Но природа и нужды компьютера отличаются от природы и нужд человека, который будет использовать программное обеспечение».

Продуктовые менеджеры и руководители компаний, заказывающие разработку программ, наполняющих нашу жизнь, ничего не контролируют. Всё в руках разработчиков. Купер говорит, что это как «психи, заправляющие психушкой»!

Недавняя дискуссия, прошедшая на Quora, на тему, что программисты знают такого, чего не знают другие, отлично это иллюстрирует. Один веб-разработчик высказывается в пользу Купера, говоря:

Примерно 25% времени, затраченного на написание приложения, уходит на то, чтобы понять, что конечный пользователь может сделать не так.

Например, у меня есть 4 счета к оплате

  • Один, для оплаты подписки на журнал
  • Еще один, для оплаты подписки на спутниковое радио
  • Два, за медицинские расходы, которые мне нужно оплатить через HSA

Издательство, и компания, которой принадлежит спутниковое радио делают деньги не на создании приложений. HSA управляется крупным американским банком, который ближе к бизнесу оплаты счетов, но предоставляет просто ужасный опыт.

  • Надписи на кнопках сбивают с толку (добавить статью расходов и провести оплату)
  • Кнопка «Назад» не работает
  • Номер счета отклоняется, как неправильный
  • Непонятное сообщение об ошибке

Без сомнения, пытаясь оплатить счета, я что-то делал не так. Однако, я, также, не сомневаюсь в том, что проведи банк пользовательское тестирование, они бы обнаружили большинство тех проблем, с которыми я столкнулся. Скорее всего, это предотвратило бы большую часть звонков в службу поддержки.

Чтобы создавать более удобные программы, нужно понимать роли

Купер говорит, что программисты должны создавать дизайны не для самих себя, а для Персон. Персоны — это архетипические пользователи, чьи роли и характеристики представляют отдельную группу пользователей. Они работают как копии реальных пользователей, направляя принятие решений по функциональности и дизайну. Продолжение: http://uxgu.ru/usability-concept/

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.