Главное Свежее Вакансии   Проекты
190 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Стоит прочитать: обзор книги Алана Купера Психбольница в руках пациентов

Роман Егошин, руководитель отдела тестирования ИТ-компании Omega, рассказывает о книге, которая помогает создавать успешные программы и продукты.

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

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

Я перелопатил тонны литературы, но одной из любимых книг стала книга Алана Купера «Психбольница в руках пациентов», написанная в начале нулевых. События книги затрагивают в том числе и девяностые, но это не мешает ей быть актуальной даже в 2020. Поэтому я решил выписать некоторые мысли Алана Купера.

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

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

«Мы даем вам много функций, вы должны быть счастливы», — говорят производители. Но какой от этих функций толк, если пользователь не понимает, зачем они нужны, или не может ими пользоваться ввиду чрезвычайной сложности. Зачастую такое происходит из-за сжатых сроков, установленных топ-менеджментом. В итоге UI/UX делаются в последнюю очередь, после реализации бизнес-логики.

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

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

Люди же вынуждены пользоваться этими плохими программами по нескольким причинам:

  1. Это их рабочий инструмент, и они боятся потерять работу. Обычно это корпоративные пользователи.
  2. Отсутствие альтернатив. Актуально для специфического софта, позволяющего решать определенные задачи.

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

Автор уверен, что нельзя доверять проектирование систем и интерфейсов программистам и менеджерам. Этим должны заниматься специалисты по проектированию UX/UI.

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

Как решить проблему и с чего начать проектирование?


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

Советы по созданию персон от Алана Купера:

  1. Ваш продукт станет куда более успешным, если вы спроектируете его только для одного человека.
  2. Чем конкретнее мы прописываем характеристики персон, тем более эффективны они в процессе проектирования.
  3. Важно не смешивать точное определение персоны пользователя с реальными людьми.

Автор указывает на следующие плюсы такой персонализации:

  1. Одним из ценных моментов использования персон является то, что они задают более реалистичный тон всем дискуссиям об уровне компьютерной грамотности. Степень подготовленности пользователей может варьироваться в очень широких пределах, и персоны позволяют отчетливо это увидеть.
  2. Второй чрезвычайно важной и ценной особенностью персон является их способность выступать в качестве великолепного инструмента коммуникации. Набор образов превращается в систему проектирования, обладающую выразительной силой, позволяющей донести наши представления относительно проектирования. Куда больше они, подобно прожектору, показывают программистам, маркетологам и руководителям, что мы принимаем совершенно верные решения по проектированию.

Как создавать образы персон?


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

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

Как применять персоны?


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

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

  1. программа интересуется мной;
  2. программа относится ко мне с почтением;
  3. программа ведет себя приветливо;
  4. программа обладает здравым смыслом;
  5. программа предугадывает мои потребности;
  6. программа обладает отзывчивостью;
  7. программа не спешит жаловаться на личные проблемы (обходительная программа всегда в курсе происходящего);
  8. программа обладает проницательностью;
  9. программа характеризуется уверенностью в своих силах (обходительная программа концентрируется на важном);
  10. программа позволяет обойти правила;
  11. программа поощряет незамедлительно;
  12. программа вызывает доверие.

Подводя итог по книге, хотелось бы отметить ее практическую ценность и понятную большинству подачу материала. Технологии и принципы разработки ПО ушли вперед, но они ничуть не перечеркнули идеи Алана Купера: появились гибкие методологии Agile, которые прекрасно вписывают в свой концепт этапы прототипирования и проектирования UI/UX. По моему убеждению, для старта в IT эта книга обязательна к прочтению.

Источник

Подробнее об IT-компании Omega

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем