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

1. Санкт-Петербург
UX SPb
«Кодекс»
10.12.2013
Юрий Солоницын

2. Ежегодная конференция по юзабилити
и проектированию взаимодействия (UX)
www.profsoux.ru
26 апреля 2014 , Санкт-Петербург

3. Важно запомнить!
1. Прежде всего – контекст применения!
2. Догм нет! (даже по ГОСТ)
Догма

4. Документация — UX beyond UI
Качество
обслуживания
Расширяемость
Интеграция
Простота
развертывания
Техническая
поддержка
Документация
Пользовательский
интерфейс (UI)
Качество изготовления
продукта
Обучение
Возможность применения по назначению
= Usability
User Experience / Customer Experience – части компенсируют недостатки друг друга

5. Виды технической документации
Документация
ТЗ, методики испытаний;
Договорная
Проектная
Программная
Пользовательская
Отчеты, пояснительные записки, спецификации,
требования и т.д.
Описания программ и алгоритмов;
КД (чертежи, схемы и т.д.);
Руководства, инструкции, data sheet,
online help и т.д.

6. Документы тоже проектируют
Для кого?
Зачем?
Заинтересованные лица, целевая аудитория.
Уровень подготовки и зона ответственности.
Задачи, решаемые заинтересованным лицом при
помощи документа.
Какие задачи мы ставим перед создаваемыми документами?
Объяснить
Научить
Защитить
От полноты информации зависит успешность применения продукта,
а значит его репутация и репутация разработчиков.

7. Целевая аудитория – Лица, принимающие решение
Что это?
Какими функциями обладает
продукт?
Зачем оно моей
компании?
Чем внедрение поможет нам?
Мы сможем его
применить?
Подойдет ли продукт нашей
компании?
Когда его не надо
применять?
Спасибо, что предупредили!
А то мы бы нарвались …
Важно не просто продать, а продать полезный продукт.

8. Целевая аудитория – Технический персонал заказчика
Что это?
Какими функциями обладает
продукт?
Что мне с ним
делать?
Как правильно развернуть и
настроить?
Как от него
избавиться?
Вдруг станет не нужен или
понадобится обновить?
У меня тут пользователи еще …
Как научить других?
Как мне его не сломать?
Что делать не надо?
Что только не вытворяет админ, если его не предупредить.

9. Целевая аудитория – Пользователи
Что это?
Что мне с ним
делать?
Какими функциями обладает
продукт?
Как использовать?
Как мне его не сломать?
Что делать не надо?
Если продукт предназначен для домашнего
использования, эта группа читателей будет основной.
Понадобится информация о преимуществах продукта
и о его настройке.

10. Целевая аудитория – Техническая поддержка
Что это?
Что с ним можно
делать?
Какими функциями обладает
продукт? Что о нем можно
рассказать?
Как пользователям решить их
задачи? Что делать, если что-то
пошло не по плану? (это и есть
план ;))
О чем надо предупредить?
Что делать не надо?
Квалификация службы поддержки зависит от качества
обучения.

11. Целевая аудитория – Разработчики
Что это?
Что с ним можно
делать?
Как с ним
обращаться,
А то сами уже забыли…
Надо рассказать руководству,
поддержке, отделу маркетинга …
Надо научить сотрудников
поддержки.
О чем надо предупредить?
Что делать не надо?
Проще показать документ, чем самим вспоминать и
объяснять.

12. Зачем? Контекст и еще раз контекст
End-user, SOHO
Enterprise
Наш пользователь один на один с нашим продуктом,
надо ему помочь.
Мы помогаем бизнесу решить его проблемы.
Пользователь – просто часть машины :(
Поможем этой части работать эффективно.
Web
Если полезли инструкцию читать, значит возникли
серьезные проблемы.
Mobile
Вся надежда на интерфейс … хотя Enterprise Mobile
никто не отменял …
Для каждой задачи – не просто типовое, а оптимальное типовое решение.

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

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

15. Многое осталось за кадром
• Внутренние стандарты компании и ГОСТ (стандарт – это совсем не
страшно, если уметь ими пользоваться);
• Какие документы стоит разрабатывать?
• Кто участвует в создании документа?
• Какими инструментами пользуется технический писатель?
• Каким должен быть язык пользовательской документации?
• Как готовить иллюстрации?
• и многое другое

16. Изображения
Источники изображений, в порядке появления:
http://www.publishingtechnology.com/2010/11/user-behaviour-e-journal-sites/
http://www.highestfive.com/money/6-habits-bosses-love/
http://tucson.jobing.com/blog_author.asp?author=38738
http://aonetwork.com/tag/internet/
http://www.powercig.net/pourquoi.php
http://www.timeanddate.com/holidays/world/international-programmers-day
http://ecssba.rutgers.edu/docs/documents.html
http://www.cartoonary.com/monsters-inc-wallpapers/monsters-inc-sulley-and-mike-wallpaper/

17. Спасибо за внимание!
Санкт-Петербург
UX SPb «Кодекс»
10.12.2013
Юрий Солоницын