Приглашаем на Techdoc митап #5
Как и обещали, рассказываем про долгожданное мероприятие для технических писателей. Уже слышали про серию Techdoc митап?  3 октября пройдет очередная встреча, на которой поговорим про работу в режиме аврала, автопроверки по стайлгайдам и синергию редактора, дизайнера и исследователя. А сейчас активно идут репетиции докладов, обсуждаются вопросы круглого стола. 

В этот раз на круглом столе в обсуждении примут участие эксперты из X5Tech, Ozon, Яндекс.Маркета, Cloud и Лаборатории Касперского. Уверены, тема, которую мы обсудим, вдохновит вас на новые свершения на работе. Уже интересно?

Зарегистрироваться

#давайте_анонс

Как подписать скриншот

А нужно ли? В ГОСТ действительно их подписывают: Рис. 1 или Рисунок 1. В коммерции подписи к рисункам — большая редкость. Да и сами скриншоты вставляют нечасто.

Что делаем мы: оставляем открытыми только важные скрины, без которых пользователю будет сложно разобраться. Таких скринов остается не так много, 1-2 на страницу, и их мы никак не подписываем. А все дополнительные примеры убираем под каты. Теперь читатели, которым все понятно, читают и идут дальше. А те, у кого остались вопросы и нужны визуальные подсказки, открывают каты и смотрят.

А вот каты мы, конечно, подписываем, причем содержательно. Пользователь должен знать, что увидит при нажатии. Несколько примеров, как мы договорились подписывать каты: Посмотреть пример, Как это выглядит в интерфейсе, Где находится кнопка.
#давайте_практику

Больше примечаний богу примечаний

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

Вот что важно соблюдать, чтобы примечания работали:
✅ Не больше 1-2 примечаний на экранную страницу, иначе они перестают привлекать внимание и замусоривают текст.
✅ Не злоупотреблять «красными» примечаниями, помещать в них только действительно критичную информацию. Остальное пишем или просто в тексте, или используем более нейтральные виды примечаний.
✅ Не добавлять слова вроде «ВНИМАНИЕ!» или «Очень важно!!!». А также не использовать капслок, цветные шрифты и восклицательные знаки. Само выделение уже достаточно привлекает внимание.

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

А вы используете примечания в документации? Расскажите о вашей практике!
#давайте_практику

На TechDoc митапе дарят вот такие улетные стикеры.

Но тем, кто не смог добраться, наверное, интереснее ссылки на онлайн-трансляцию.
Делимся ими с вами!

Кто тоже здесь сегодня онлайн или оффлайн, ставьте сердечки или плюсики в комментах :-)

Ссылки на трансляцию:
Вконтакте 
Youtube 

Бывало, коллеги? 😁
Кидайте свои мемчики о работе в комментарии 🙂

#давайте_мем

Подводим итоги митапа

Мы надеемся, эмоции с Techdoc митап уже улеглись, и вы готовы к новой рабочей неделе 😊
А пока поделитесь, пожалуйста, с организаторами вашей обратной связью. Это поможет сделать следующие митапы еще лучше.
А кто не смог быть в четверг, можно посмотреть запись по тем же ссылкам:
Вконтакте 
Youtube
P.S. Если вы вдохновились и у вас появилось желание поделиться вашими практиками или рассказать что-то полезное сообществу, скорее к Кате Ушаковой, следующий Techdoc митап пройдет в Ozon😉

На этой неделе говорим про онбординг. Расскажите, бывал ли у вас такой онбординг, после которого сразу хочется на оффбординг? Или, может, онбордингом вашей компании можно гордиться? Расскажете?

О плохом онбординге
Рассказываем реальную историю плохого онбординга. В компанию (не нашу) вышел новый технический писатель, других технических писателей в компании нет. На второй день руководитель просит присоединиться к одной продуктовой команде, выяснить их потребность и начать писать инструкции. На вопросы "К кому я могу обратиться из команды, где в офисе их можно найти?", руководитель ответил кратко: "Не знаю, ищи сама....".

И вот стоит техпис посреди огромного опенспейса и не понимает, куда идти, где искать. Информация на портале для сотрудников не помогла. Хорошо, что специалист был самостоятельный, всех нашел, всё разрулил. А что бы сделали вы после такого онбординга?

Онбординг или самовыживание?

Онбординг точно должен быть — это наше мнение.

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

Но кто тот самый супермен, который расскажет обо всем и сразу? С сожалением придется признать, одного-единственного, кто знает все и сразу, нет. Но безвыходных ситуаций не бывает, поэтому мы проводим многогранный онбординг:

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

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

Когда инструкции не нужны

Любому ли сервису нужны инструкции? Мы считаем, что нет.

Вот минимум три случая, когда инструкции можно не писать:

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

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

✅ Сервис давно существует и не обновляется, новых пользователей почти не появляется. Например, внутренний портал для управления ценами. Мы знаем, что им пользуется ограниченное число сотрудников, и даже если приходит новый, опытные коллеги быстро научат его использовать портал.

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

Какие еще кейсы можете назвать? Или считаете, что инструкции нужны всегда?

#давайте_лайфхак

Что есть, то есть... 😁
Кидайте свои мемчики о работе в комментарии 🙂

#давайте_мем