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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

hsa

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

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

 

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

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

Хотя Персоны действительно помогают сохранять внимание на пользователе, у меня есть два дополнительных предложения:

  1. Разработчики должны наблюдать за пользователями: наблюдение за несколькими пользователями, использующими программное обеспечение еще до момента его релиза — это самый эффективный способ их понять. Существуют лучшие практики, исследования, спецификации, но никакое руководство по стилю не скажет вам, что будет делать настоящий человек, пытаясь выполнить задачу. Именно наблюдением этих пользователей проверяются наши предположения — наблюдением людей, которые не разбираются в хитросплетениях кода, моделях данных, и всех бизнес правилах, которые вошли в дизайн. Затем, проблемы нужно устранить, и попытаться сделать это еще до того, как пользователи начнут заваливать службу поддержки звонками, с просьбой объяснить, как оплатить счет.
  2. Специалисты по юзабилити должны уметь программировать: программирование, или хотя бы знание основ — важный навык в мире UX. Понимание требований баз данных и языков программирования — это лучший способ понять ограничения разработчика. Я сам создал несколько веб-приложений и всегда был одним из предполагаемых пользователей. Каждый раз, используя свою программу, я удивлялся тому, как это я упустил из виду какие-то проблемы навигации, или вспоминал, как хотел вообще всё сделать по-другому еще на стадии частичной функциональности. Смотреть за тем, как другие используют мои программы, было довольно поучительным занятием. Я не хочу сказать, что UX дизайнеры должны превратиться в программистов, я просто говорю, что, понимая все сложности и ограничения создания интерфейсов, можно многое узнать об их улучшении.

Разработчики — это не зло, а UX дизайнеры — не мудрецы. Наблюдение за пользователями, проведение тестов с сортировкой карточек, и выполнение контекстных запросов — это методы, которые помогут нам создать более юзабельный пользовательский опыт. Это, также, методы, у которых есть одна общая, фундаментальная концепция: разработчик — не пользователь.

Перевод статьи Джеффа Сауро