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