Всё юзабилити за час
•
17 likes•1,457 views
Презентация доклада Дмитрия Сатина "Всё юзабилити за час", прочитанного им на семинаре "
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Всё юзабилити за час
Similar to Всё юзабилити за час (20)
More from Digital Guru Club
More from Digital Guru Club (20)
Всё юзабилити за час
- 1. Всё о юзабилити за час :) Дмитрий Сатин, USABILITYLAB
- 2. Москва ✓ Эффективность ✓ Продуктивность ✓ Удовлетворённость Киев Пермь Санкт-Петербург
- 3. Что нового в том, что мы делаем?
- 4. Мы не программисты ¡ Программисты пишут ТЗ. ¡ Заказчик подписывает ТЗ, не понимая, что подписывает. ¡ Программисты приносят продукт. ¡ Заказчик хватается за голову. ¡ Программисты показывают его подпись на ТЗ.
- 5. Мы не дизайнеры ¡ Спросите дизайнера, готов ли он дизайном улучшить бизнес клиента. ¡ У дизайнеров, как правило, нет измерений, только чувство вкуса. ¡ Дизайнеры торопятся изменить мир, не всегда понимая бизнес заказчика.
- 6. Мы не маркетологи ¡ Маркетинги подвержены социологии, и часто боятся сфокусироваться на конкретном потребителе. ¡ Маркетологи занимаются привлечением, забывая про то, что удержание выгоднее. ¡ Слишком фокусируются на заимствовании идей у конкурентов.
- 7. UX во всём ¡ Вовлечение всех участников процесса. ¡ Точка сборки различных интересов.
- 8. бизнес люди U технологии
- 9. Мультидисциплинарность команды ¡ Команда, работающая над дизайном, не обязательно должна быть большой, но в ней должны работать специалисты из разных профессий. ¡ Мультидисциплинарность позволяет находить решения, отвечающие требованиям всех заинтересованных сторон, вовремя находя компромиссы при возникновении противоречивых требований.
- 10. Целостность User Experience ¡ Необходимо учитывать как предыдущий опыт использования подобных продуктов и предшествующих версий продукта, так и специфику рекламы и брендинга продукта.
- 11. customer experience user experience usability
- 12. • Дизайна нет • Дизайн не используется в разработке. Дизайнеры работают для себя. • Дизайн как стиль • Дизайн используется только в конце процесса, как оформление и декорация. • Дизайн как процесс • Метод, интергированный на ранних этапах разработки, требует усилий многих специалистов. • Дизайн как инновация • Дизайнер работает совместно с бизнесом над полным или частичным обновлением бизнес-модели.
- 14. Это же так классно!
- 15. "Люди были созданы для того, чтобы их любили, а вещи были созданы для того, чтобы ими пользовались. Мир в хаосе потому, что все наоборот."
- 16. Людей любить! Вещами пользоваться! Но не наоборот!
- 17. Юзабилити (ISO 9241-‐11) § Юзабилити является степенью эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.
- 18. Юзабилити (ISO 9241-‐11) § Юзабилити является степенью эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.
- 19. Юзабилити Инженерия ¡ Повышение эффективности бизнеса за счет повышения эффективности, продуктивности и удовлетворенности пользователей информационных систем. ¡ Возврат от инвестиций в разработку -‐ живые деньги, которые можно посчитать ¡ Это возможно при соответствии функций сайта задачам и потребностям пользователей.
- 20. ROI в юзабилити ¡ Оценка уровня ROI 50 воспользовавшихся 38 юзабилити-‐ услугами. 25 ¡ Опрос проводился 13 агентством E-‐ consultancy в 2007 0 году. 0-‐99% 100-‐299% 300-‐499% 500+%
- 21. Стоимость юзабилити Затраты на юзабилити составляют приблизительно 10% от разработки при условии итеративности разработки и использовании всего спектра методов [юзабилити] на всех этапах проекта.
- 22. Айсберг юзабилити 10% -‐Внешний вид: макет, цвета изображения 30% -‐Функциональность: меню, кнопки, управление 60% -‐Цели и задачи пользователя: действия, навигация, объекты и взаимодействие между ними
- 23. Цена исправления ошибок Анализ 0,1 $ Проектирование 1,0 $ Разработка 10,0 $ Эксплуатация 100,0 $
- 28. Human-‐Centred Design Определение Потребность контекста или идея использования 1 Оценка Определение Решение дизайна требований 4 2 Разработка дизайна 3
- 30. Пользователи, задачи, среда ¡ Продукты, системы и сервисы должны разрабатываться с учетом как тех, кто ими будет пользоваться, так и других заинтересованных групп, включая тех на кого повлияет использование этих продуктов. ¡ Все значимые группы пользователей и заинтересованных в продукте людей должны быть идентифицированы.
- 31. Группы пользователей ¡ Необходимо определить целевые группы пользователей, а также отношение этих групп к предполагаемому продукту. Эти отношения должны быть описаны в терминах ключевых целей и ограничений. ¡ Необходимо определить ключевые характеристики пользователей. ¡ Продукты должны создаваться с учётом того, что их будут использовать люди с различными функциональными возможностями.
- 32. Задачи пользователей ¡ Определить целевые задачи пользователей и общие задачи системы. ¡ Описать характеристики задач, которые могут повлиять на юзабилити и общедоступность. ¡ Определить возможные негативных последствий для здоровья и безопасности в результате некорректного выполнения задачи. ¡ Не описывать задачу исключительно в терминах функций и возможностей продукта.
- 33. Среда и условия ¡ Необходимо определить технические условия и ограничения, в том числе аппаратное и программное обеспечение и др. ¡ Необходимо описать ключевые характеристики физического и социального окружения.
- 34. Вовлечение пользователей ¡ Необходимо активно вовлекать пользователей. ¡ Пользователи, вовлеченные в процесс разработки, должны обладать возможностями, характеристиками и опытом тех, для кого проектируется и разрабатывается продукт.
- 35. Итеративность При проектировании интерактивных систем необходимо применять итерации, как средство последовательного прояснения неясностей.
- 36. Критическая важность оценки ¡ Оценка пользовательских качеств продукта должна проводиться как в процессе проек-‐ тирования, так и в качестве финальной процедуры приемки для установления того, насколько выполнены требования к продукту.
- 37. Улучшения по результатам проверки ¡ Стоимость и ценность предложенных изменений должны быть тщательно оценены и использованы для принятия решений о том, что должно быть изменено. ¡ В плане проекта должно быть предусмотрено время на внесение изменений по результатам обратной связи.
- 38. Общие принципы оценки ¡ Даже самые ранние концепты должны проходить проверку для получения представления о потребностях пользователя. ¡ Если тестирование с привлечением пользователей непрактично или слишком дорого для определенного этапа разработки, то интерфейсы должны быть оценены другими методами.
- 39. Долгосрочный мониторинг ¡ Оценка должна включать долгосрочные наблюдения за использованием продукта, системы или сервиса. ¡ Критерии и измерения для долгосрочного наблюдения должны быть достаточно чувствительными для своевременного выявления сбоев и проблем в системе. ¡ Объем мониторинга должен определяться степенью рисков, связанных с невыполнением требований.
- 63. Не теряйтесь! • Дмитрий Сатин • d.satin@usabilitylab.ru • Твиттер: @dmitrysatin • http://facebook.com/dmitry.satin • UsabilityLab • http://usabilitylab.ru • http://twitter.com/usabilitylab
- 64. История чемодана • Первые чемоданы на колесах были разработаны для членов экипажей. • Никто не планировал революцию в чемоданостроении. • Теперь не осталось чемоданов без колес. • Фокус на целевом потребителе меняет мир!