​​Исследований пост №1

Для хелпа очень важно, чтобы пользователь нашел статью. Желательно, чтобы в статье был ответ на его вопрос:) Для этого надо расположить статью в очевидном месте в содержании хелпа (дереве) и дать ей понятный заголовок. Это кажется простой задачей, но есть нюанс. Стандартного решения нет.
Чтобы не мучать себя вопросами, мы решили провести тестирование структуры хелпа. Для этого использовали инструмент Treejack. Обычно его используют для проверки информационной архитектуры сайтов, но он подходит для тестирования любых древовидных структур.

Как устроено тестирование
Вам нужно:
1. Загрузить оглавление хелпа (дерево).
2. Подготовить вопросы, ответы на которые нужно найти в хелпе.
3. Задать правильные ответы на вопросы.
4. Найти респондентов, которые пройдут опрос. Нам с этим помогали специалисты по UX-тестированию.

Потом нужно немного подождать и вы получите результат: сколько человек нашли ответ в нужном разделе, сколько времени на это потратили.

Пример
Оглавление хелпа (дерево): в формате .csv.

​​Вопрос:
Вы хотите узнать, сколько стоит курьерская доставка в Тверь, где живет ваша бабушка. В каком разделе вы бы решали эту задачу?

Правильные ответы:
Служба поддержки → Доставка заказов → Сколько стоит доставка в мой город
Условия доставки → Стоимость доставки

Результат:
88% респондентов нашли правильный ответ, для этого им понадобилось 10 секунд.
А еще результаты получаются не только полезны, но и красивы.

#экспериментыналюдях

​Как тестирование бумажной инструкции привело к изменению части устройства

Отличная статья про тестирование продукта вместе с документацией.

Краткий пересказ
Делали сложную железку (подсветку для телевизора), которую пользователь должен был самостоятельно монтировать. Установить должна смочь любая домохозяйка. Решили протестировать на людях железку и две разные инструкции. В итоге переделали все.

Самый сок
* Проблема не всегда в документации, иногда нужно менять сам дизайн и техническое решение.
* Пример инструкции для чего-то нестандартного (я такое коллекционирую).
* Можно посмотреть процесс изменения инструкции.
* То, что люди на тестах не читали инструкцию до конца, еще не означает, что ее не нужно делать.

Послесловие
Меня осенило, что символ ✂️(ножницы с пунктиром) одна из первых символьных инструкций, как и 💾 (дискета). Так?

#экспериментыналюдях #намвсемнужнапомощь

​​Как люди читают онлайн

Nielsen Norman Group опубликовали новую версию исследования о том, как люди читают в интернете. Прошлое исследование было 2006–2013 годах.

Не поменялось

Люди не читают слово за словом, а сканируют текст. Количество времени, которое человек готов потратить на текст, зависит от:
- Мотивации: насколько человеку нужна информация в тексте.
- Типа задачи: ищет человек конкретный факт или исследует тему.
- Уровня фокусирования: насколько человек сосредоточен на данной задаче.
- Личных качеств человека.

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

Новое

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

Обе эти модели встречаются, когда текст обтекает визуальные элементы. При этом визуальные элементы, которые прерывают текст, нарушают и чтение. Даже если человек до этого читал текст линейно и полностью, то после визуального элемента он останавливает чтение и переходит к сканированию. Картинка с примером ниже, чтобы не прерывать вам чтение:)

#экспериментыналюдях

​​Developer experience

В Slack Write the Docs запостили платформу для экспериментов над разработчиками — Haxor. Я eе не пробовала. Мне нравится идея и подход, что-то можно реализовать и без платформы.

Как это работает

1. Вы выбираете задание, которое разработчик должен выполнить с помощью вашего API/SDK. Желательно на час.
2. Платформа подбирает разработчиков.
3. Разработчики выполняют задание и попутно записывают видео.
4. Платформа логирует действия разработчиков: код, который они пишут, и приложения, которые они используют.
В итоге вы получаете отчет с метриками, видео и логами действий разработчиков. Процесс повторяется каждый месяц.

Метрики

В отчете 4 метрики:
- время на выполнение задания;
- % ошибок во время выполнения;
- % выполнивших задание;
- счастье🤩.

И вот счастье — это самая интересная метрика. Она измеряется с помощью опросника, который когда-то придумали в IBM (Computer System Usability Questionnaire или PSSUQ). Разработчики оценивают насколько они согласны или не согласны с 16 утверждениями. Например такими:
- Пользоваться этой системой было просто.
- Было легко найти нужную мне информацию.
- Эта информация была эффективна, помогла мне выполнить задачу.
Получается, счастье разработчика — это когда есть понятная документация.

#экспериментыналюдях

Как пользователи воспринимают контент

Продолжу тему визуальных инструкций или комиксов. Для вдохновения я опубликовала свою подборку визуальных инструкций на Miro. У примеров из подборки разные целевые аудитории. Инструкции Лего — должны быть понятны детям, Икея — любому взрослому, а по починке холодильника — мастеру по ремонту.

Мне интересно, работают ли такие инструкции на самом деле, помогают ли пользователю. И как пользователи воспринимают контент. Например:
- Нужен ли текст, если есть картинка? У Икеи текста почти нет.
- Нужна ли картинка, если есть текст?
- Как быстро можно понять картинку с текстом и без текста?
- Как расположить текст и картинку?
- Помогут ли GIF-ки или короткие видео сделать контент понятнее?

Исследований, которые говорят, как правильно нет. Но вот, что я нашла:

- Делайте четкие и детальные изображения, студенты в исследовании сначала сосредоточились на изображениях, а затем при необходимости обратились к тексту. Будьте кратки с текстом. Студенты предпочитали маркированные пункты с ключевыми терминами, выделенными жирным шрифтом. Инструкции с изображениями более эффективны, чем с видео, потому что в них легче найти конкретную информацию. Источник: Student preference for tutorial design | Mestre.


- Значимые изображения, которые поддерживают текст, полезны и привлекут внимание пользователя. Такие изображения хорошо работают как в зигзагообразном, так и в выровненном макете, потому что пользователи хотят тратить время на просмотр изображений, чтобы понять текст. Источник: Zigzag Image–Text Layouts Make Scanning Less Efficient | Nielsen Norman Group.


- Изображения или GIF-ки для каждого шага инструкции удобнее для пользователя, чем видео. Источник: How to Film and Photograph Online Content for Usability: UX Details for Videos and Images | Nielsen Norman Group.


- Текстовые и графические инструкции более эффективны, чем аудио и видео. Источник: Static vs. dynamic tutorials | Turner, Fuchs, and Todman.


- Видео — это дополнительный источник информации, не все пользователи будут его смотреть. Если у вас нет видео, а пользователям оно нужно, чтобы разобраться, они найдут видео в другом месте. Источник: Videos as Instructional Content: User Behaviors and UX Guidelines | Nielsen Norman Group.

Дополню подборку, когда найду что-то еще. Если знаете хорошие исследования по теме, пишите в комментариях.

#экспериментыналюдях

Про редизайн документации GitLab

GitLab считает, что отличная документация для их проекта — это необходимость. Чтобы сделать свою документацию отличной, они провели исследование о том, зачем пользователи приходят в их документацию и что в ней сейчас не так. Проанализировали эти данные и сделали на основе них редизайн сайта документации.

А еще они опубликовали вопросы и результаты исследования, роадмап документации и то, какие решения уже реализовали.

Исследование и его результаты показывают, что в документации важен не только текст, а еще его структура и организация.

Дальше немного красивых циферок и рандомных фактов.

Нашли ли пользователи в документации то, что искали

- 75 % смогли найти.
- 96% из них сказали, что контент полезный.
Пользователям нравится подробная документация с примерами кода.

Зачем пришли в документацию

- 35% искали инструкцию.
- 24% открыли страницу, которую используют как референс.
Большинство пользователей переходят в документацию из Google или сохраненных страниц.

Проблемы, которые выявило исследование

- Трудно найти информацию. Пользователи часто посещают несколько страниц и читают много текста, прежде чем найти нужный контент. Информацию по решению проблем особенно сложно найти.
- Путаница с версиями GitLab. Эта информация появляется в документации в случайном порядке. Пользователи сбиты с толку инструкциями для разных версий продукта на одной странице документации. Новые пользователи не знают, какую версию GitLab они используют.
- Help и Docs разные сайты. Пользователи не видят разницы между двумя сайтами с документацией и не знают, где искать ответ.
- Пользователям нужна помощь в понимании того, какие из многих инструкций лучше для них и почему.

#экспериментыналюдях #makedocumentationgreat

Ученые узнали, чего на самом деле хотят разработчики от документации

Вот исследования от настоящих ученых из Merseburg University of Applied Sciences:
1. Документация API: Чего хотят разработчики?, 2018 год.
2. Оптимизация документации API: рекомендации и их эффективность, 2020 год.

What do software developers want?

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

Исследование показывает, что разработчики подходят к новым API с двумя разными целями:
- понять, следует ли выбирать API для решения конкретной задачи;
- использовать API для выполнения задач.

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

Дальше мнения разделились:
- одни хотят быстро приступить к работе — сразу начать писать код. Такие разработчики ищут пример, который потенциально может послужить основой для решения их проблемы.
- другие хотят разобраться в API, прежде чем начать работу. Эти разработчики отметили, что они ищут и читают документацию API. Например, они ищут обзор технической архитектуры, объясняющий общие концепции. Но это не значит, что они намерены изучать API в целом. Разработчики подходят к документации с учетом проблемы или задачи.

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

Если разработчики сталкиваются с проблемой, то большинство пойдет гуглить, только 30% будет читать документацию.

Что с этим делать?

На основе первого исследования и исследований других авторов во втором исследовании составили рекомендации по разработке документации API и проверили их эффективность.

То есть ученые взяли реальный API c реальной документацией и переписали документацию. Потом попросили разработчиков выполнить несколько задач c помощью API. При этом одним дали старую документацию, а другим — новую. Меряли точность выполнения задач, время выполнения и время, затраченное на документацию и на ресурсы вне документации.

Получили, что:
- те, кто работал с новой версией документации, сделали меньше ошибок;
- время выполнения задач было примерно одинаковым;
- время чтения документации не отличалось, но те, кто работал со старой версией документации потратили больше времени на чтение других ресурсов, то есть суммарное время на чтение у них больше.

У разработчиков были замечания к обеим версиям документации.

Какие выводы

Рекомендации по разработке документации API, которые описаны в исследованиях, соответствуют best practice в индустрии (как курс Тома Джонсона про API). Нормально делай — нормально будет 🙂

#экспериментыналюдях #developerexperience

Снова про скриншоты

Я собирала исследования про то, как пользователи воспринимают контент и нужны ли им скриншоты вообще. Но в документации часто бывают не просто скриншот, а скриншот с дополнительными элементами, такими как рамочка или стрелочка. Технические писатели добавляют эти элементы, чтобы помочь читателю. Но помогает ли это читателю?
Michael Meng выясняет это в исследовании Effects of visual signaling in screenshots: an eye tracking study.

Как проходило исследование

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

Какие выводы

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

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

Исследование не позволяет сделать выводы о том, какие дополнительные элементы на скриншотах эффективны для направления визуального внимания пользователя, а
какие нет.

#экспериментыналюдях

Знаете ли вы, чего хотят ваши читатели?

Yoel Strimling провел несколько исследований, чтобы понять, что такое “хорошая документация” по мнению читателей и понимают ли это технические писатели.

1. Beyond Accuracy: What Documentation Quality Means to Readers
2. So You Think You Know What Your Readers Want?

Как проходили исследования

В первом исследовании собраны различные методологии, по которым можно оценивать “хорошесть” документации. Из них выбрали методологию Wang and Strong (1996 года) и выделили 4 характеристики, в каждой определили подкатегории:

- Содержание: данные должны обладать качеством сами по себе (точность, достовернось, объективность, надежность).
- Контекст: данные должны рассматриваться в контексте поставленной задачи (объем, полнота, релевантность, своевременность, ценность).
- Представление: данные должны быть хорошо представлены (лаконичнось, согласованность, понятность, интерпретируемость).
- Доступность: данные должны быть легко извлекаемыми (доступность, безопасность).

Читателей попросили выбрать из подкатегорий те, которые они считают самым важным в документации (ссылка на опрос). Во втором исследовании, технических писателей попросили выбрать то, что они думают важно для читателей.

Какие выводы

Для читателей основные характеристики “хорошести” документации это:
- Точность
- Понятность
- Релевантность

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

#экспериментыналюдях

Эмоций разработчиков по отношению к документации

Группа ученых из университета Indian Institute of Technology Tirupati провела эмоциональный анализ комментариев в коммитах, связанных с документацией.

- Understanding Emotions of Developer Community Towards Software Documentation, 2021 год
- Видео версия

Как проходило исследование

Ученые взяли 10 000 комментариев из коммитов, которые относятся к файлам README или файлам с расширением .txt или .md. Проанализировали слова, которые используют разработчики, и связали эти слова с эмоциями. Чтобы распознать эмоции использовали методологию NRC Word-Emotion Association Lexicon. Она позволяет определить 8 эмоций: гнев, ожидание, отвращение, страх, радость, печаль, удивление, доверие. Если какой-то комментарий выражал несколько эмоций, то выбирали более сильную.

Примеры того, какие комментарии соответствуют каким эмоциям, жирным выделены слова, которые характеризуют эмоцию:

- Improve duplicate torrent detection — доверие
- README is better short-n-sweet — радость
- Improved test framework, added missing dependencies — страх
- Make usage instructions more clear — ожидание
- drop support for older versions — печаль
- Location support (backward compatibility broken) — гнев
- plugin-browser-for-bbpress: A stupid bug. Tagged version 0.1.9 — отвращение
- Didn’t expect this to actually become a thing — удивление

Какие выводы

Базируясь на других исследованиях, ученые предполагали, что разработчики испытывают негативные эмоции при обновлении документации, то есть страх, гнев, отвращение или печаль.

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

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

P.S. Я не считаю, что исследование дает полную картину, так как в нем учтены только те, кто внес изменения в документацию. Но мне было интересно узнать их эмоции и понравился подход.

#экспериментыналюдях

​​Какой длины делать обучающие видео?

Компания TechSmith, которая делает Snagit и Camtasia, опубликовала исследование про видео контент. С помощью исследования они пытались понять, почему люди начинают, останавливаются и продолжают смотреть обучающие и информационные видеоролики.

- Исследование Video Viewer Study 2021
- Статья Video Length: How Long Should Instructional Videos Be?
- Статья Video Statistics, Habits, and Trends You Need To Know

Как проходило исследование

В ходе исследования ​​914 человек 20 разных профессий из 6 стран отвечали на вопросы и описывали “отличное” видео, которые они посмотрели недавно и оно помогло им в работе.

Какие выводы

- 83% респондентов предпочитают видеоформат для учебного или информационного контента.

- 71% респондентов смотрят два или более обучающих видео в неделю (на 33% больше, чем в 2018 году).

- Идеальной длины видео не существует, респонденты выбирали разные варианты в диапазоне 3-19 минут, при этом если цель респондента получить новые знания или ему интересна эта область, то он готов смотреть ролики 20-40 минут, если нужно решить проблему — то ролик до 9 минут, а короткие ролики в 1-2 минуты выбрали те, чья мотивация звучала как “Я должен был это посмотреть”.

- Видео выбирают по описанию и названию, а смотрят на Youtube.

- Видео продолжают смотреть, если материал хорошо организован, и перестают смотреть, когда получили нужную информацию или не получили информацию, которую ожидали. Качество видео и видеоэффекты не так важны.

#экспериментыналюдях #самсебережиссер

Про редизайн документации GitLab - 2

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

Между опросами GitLab переделали левое меню навигации и сделали редизайн документации. Эти изменения должны помочь пользователям находить нужные страницы и информацию на них.
Задачи можно найти на роадмапе документации.

Результаты нового опроса

В сентябре 2021 GitLab снова опросили пользователей, чтобы понять, что изменилось. Опрос показал, что:

- пользователям стало сложнее находить информацию (67% нашли то, что искали, в прошлом году было 75%)
- сложнее всего найти информацию по решению проблем, результаты совпадают с прошлым годом
- пользователи все еще считают найденный контент полезным
- выросло число новых пользователей GitLab, которые посещают документацию

Почему пользователям стало сложнее находить информацию

Такое изменение находимости контента могло произойти потому что:

- появилось много новых пользователей
- процесс изменения структуры документации не закончен
- появилось много нового контента без улучшения поиска

#экспериментыналюдях