Чуть попозже опишу

Юзабилити, UX, UI, проектирование/дизайн пользовательского опыта - все эти понятия очень модные в последнее время. Все стараются обращать внимание на пользователей и повышать юзабилити продуктов, но не все делают это в правильном направлении и систематически.
На примерах разберём, как понимание важности юзабилити разрабатываемого сайта позволяет снизить риски на всех этапах разработки и как заложить фундамент к дальнейшей прибыли.

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

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

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

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

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

При создании интерфейса нового продукта project manager становится product manager, сам того не подозревая. На него сваливается груз ответственности за будущий продукт. Конечно, менеджер не несет ответственность за качество предоставляемого сервиса, за общение с клиентами, но то, каким будет представление пользователя о продукте, какие возможности будут у продукта, как пользователь будет взаимодействовать с продуктом, — целиком на плечах менеджера.
Менеджеру приходится по уши проваливаться в предметную область, изучать нюансы, специфику, конъюнктуру рынка. Собирать крупицы пользовательского опыта по косвенным признакам. Приятное отсутствие «у нас так принято» заменяется полной неразберихой. Заказчик хочет одно, пользователи другое, ЛПР третье… стоп-стоп-стоп! так есть отличие project от product или нет?
На примере собственного опыта работы менеджером проектов по созданию интерфейсов новых продуктов я расскажу об этапе принятия ответственности за будущий продукт, о взаимодействии с заказчиком и отличиях создания интерфейса новых продуктов от реновации уже существующих.

Scrum, Kanban, XP, Crystal и прочие еще более редкие фреймворки и методы, что обещают Вам стать agile, уже давно опробованы как в чистом виде, так и в составе ядерных коктейлей, а воз и ныне там. Ваши отделы, продуктовые группы и вся компания целиком все так же далеки от того, чтобы быть agile. Между тем, верхи действительно хотят, а низы однозначно могут и даже обратное все так же верно. Так в чем же дело? В рамках этого доклада мы попытаемся ответить на этот вопрос. Будем говорить о разной степени важности тех или иных элементов больших agile-трансформаций, их влиянии друг на друга и правильно расставленных акцентах и приоритетах. В конце, как обычно, секретный ингредиент успеха.