Я слушал только самый конец доклада, однако могу сказать, что это — хороший доклад.
Он — о том, как прививать программистам культуру создания интерфейсов, заботу о пользователях — которые, преимущественно, воспринимают интерфейсы не так, как программисты. О том, что дизайнерам надо оглядываться на возможности реализации. А еще — о том, что интерфейс живет своей жизнью в ходе разработки, отходя от начальных концепций, и за этим процессам надо следить.
Что касается практических советов, то я услышал один — выделяйте роли, для которых проектируете интерфейс. Хорошо, если они выделяются в исследовании бизнеса, но даже если такой возможности нет, роли «с потолка» лучше, чем их отсутствие. Наверняка были и другие советы — раньше, чем я пришел.
В целом, для меня доклад — относительно понятные вещи. Но по опыту — они понятны далеко не всем разработчикам. И на конференции, по отзывам — не все эти идеи воспринимали, может быть из-за несколько директивной энергетики доклада. Хотя это просто общая энергетика докладчика проявляется, а никак не позиция знающего истину и учащего ей. Мне доклад очень понравился.
Рассказ про проектирование взаимодействия. Мне показались знакомыми основные идеи, озвученные в докладе — читал их в книжке Алана Купера «Об интерфейсе. Основы проектирования взаимодействия». Укажу основные моменты доклада.
В начале процессе проектирования взаимодействия происходит выделение персонажей (ролей) и проектировании интерфейса взаимодействия для них. Персонаж — некий собирательный образ одного из пользователей интерфейса (кстати, по мнению Купера важен полный портрет — пол, возраст, образование, профессия, семейное положение и т. п. Этот персонаж даже получает собственное имя). Затем юзабилисты пытаются построить модель взаимодействия персонажа с разрабатываемой системой.
Ряд проблем при проектировании:
Избыток контролов
Тексты на интерфейсе (формулировки). Считает, что самовольные правки текстов — преступление.
Сообщения об ошибках
Интерфейсное хамство
Недоделанную работу показывать нельзя — можно отвратить пользователя. Если всё-таки приходится — нужно обставить это «ритуалами».
Бесконечные согласования неважных деталей интерфейса с заказчиком — зло. Но в процессе согласований можно получить и действительно важную для проектирования информацию (?)
Результаты обсуждения необходимо фиксировать в модели, а не в виде «бантиков сбоку».
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
