Подводим итоги митапа
Мы надеемся, эмоции с Techdoc митап уже улеглись, и вы готовы к новой рабочей неделе 😊
А пока поделитесь, пожалуйста, с организаторами вашей обратной связью. Это поможет сделать следующие митапы еще лучше.
А кто не смог быть в четверг, можно посмотреть запись по тем же ссылкам:
Вконтакте
Youtube
P.S. Если вы вдохновились и у вас появилось желание поделиться вашими практиками или рассказать что-то полезное сообществу, скорее к Кате Ушаковой, следующий Techdoc митап пройдет в Ozon😉
Мы надеемся, эмоции с Techdoc митап уже улеглись, и вы готовы к новой рабочей неделе 😊
А пока поделитесь, пожалуйста, с организаторами вашей обратной связью. Это поможет сделать следующие митапы еще лучше.
А кто не смог быть в четверг, можно посмотреть запись по тем же ссылкам:
Вконтакте
Youtube
P.S. Если вы вдохновились и у вас появилось желание поделиться вашими практиками или рассказать что-то полезное сообществу, скорее к Кате Ушаковой, следующий Techdoc митап пройдет в Ozon😉
Google Docs
Techdoc Meetup #5
Поделитесь, пожалуйста, c нами своими впечатлениями!
Ответы на вопросы займут не более 3-х минут и станут для нас ценной информацией, которая поможет сделать следующий митап интереснее для вас!
Ответы на вопросы займут не более 3-х минут и станут для нас ценной информацией, которая поможет сделать следующий митап интереснее для вас!
❤12👏4🤝2
На этой неделе говорим про онбординг. Расскажите, бывал ли у вас такой онбординг, после которого сразу хочется на оффбординг? Или, может, онбордингом вашей компании можно гордиться? Расскажете?
👏2
О плохом онбординге
Рассказываем реальную историю плохого онбординга. В компанию (не нашу) вышел новый технический писатель, других технических писателей в компании нет. На второй день руководитель просит присоединиться к одной продуктовой команде, выяснить их потребность и начать писать инструкции. На вопросы "К кому я могу обратиться из команды, где в офисе их можно найти?", руководитель ответил кратко: "Не знаю, ищи сама....".
И вот стоит техпис посреди огромного опенспейса и не понимает, куда идти, где искать. Информация на портале для сотрудников не помогла. Хорошо, что специалист был самостоятельный, всех нашел, всё разрулил. А что бы сделали вы после такого онбординга?
Рассказываем реальную историю плохого онбординга. В компанию (не нашу) вышел новый технический писатель, других технических писателей в компании нет. На второй день руководитель просит присоединиться к одной продуктовой команде, выяснить их потребность и начать писать инструкции. На вопросы "К кому я могу обратиться из команды, где в офисе их можно найти?", руководитель ответил кратко: "Не знаю, ищи сама....".
И вот стоит техпис посреди огромного опенспейса и не понимает, куда идти, где искать. Информация на портале для сотрудников не помогла. Хорошо, что специалист был самостоятельный, всех нашел, всё разрулил. А что бы сделали вы после такого онбординга?
🤡8😐7👍4
Онбординг или самовыживание?
Онбординг точно должен быть — это наше мнение.
Иначе получится, что выплывать и лавировать должен сам, а потом еще и делать выводы, почему не получилось. Это отнимет гораздо больше времени и нервных клеток, чем сразу услышать о внутренних процессах от коллеги и подстроиться под них.
Но кто тот самый супермен, который расскажет обо всем и сразу? С сожалением придется признать, одного-единственного, кто знает все и сразу, нет. Но безвыходных ситуаций не бывает, поэтому мы проводим многогранный онбординг:
✅ Внутри отдела техписов. Опытный наставник рассказывает о техписательских процессах, помогает разобраться с доступами и техникой, а также всегда может выслушать, понять и подбодрить.
✅ В команде продукта. Один из членов команды (чаще деливери) погружает в продукт, рассказывает о командных процессах, знакомит с командой.
✅ В компании. Есть интерактивная программа, в которой новичку рассказывают о ценностях компании и правилах работы, а также показывают, насколько у нас большая и дружная команда.
Именно благодаря комплексному подходу новички не испытывают жуткий стресс, как герой из предыдущего поста, а отправляются в спокойное и уверенное плавание.
#давайте_про_процессы
Онбординг точно должен быть — это наше мнение.
Иначе получится, что выплывать и лавировать должен сам, а потом еще и делать выводы, почему не получилось. Это отнимет гораздо больше времени и нервных клеток, чем сразу услышать о внутренних процессах от коллеги и подстроиться под них.
Но кто тот самый супермен, который расскажет обо всем и сразу? С сожалением придется признать, одного-единственного, кто знает все и сразу, нет. Но безвыходных ситуаций не бывает, поэтому мы проводим многогранный онбординг:
✅ Внутри отдела техписов. Опытный наставник рассказывает о техписательских процессах, помогает разобраться с доступами и техникой, а также всегда может выслушать, понять и подбодрить.
✅ В команде продукта. Один из членов команды (чаще деливери) погружает в продукт, рассказывает о командных процессах, знакомит с командой.
✅ В компании. Есть интерактивная программа, в которой новичку рассказывают о ценностях компании и правилах работы, а также показывают, насколько у нас большая и дружная команда.
Именно благодаря комплексному подходу новички не испытывают жуткий стресс, как герой из предыдущего поста, а отправляются в спокойное и уверенное плавание.
#давайте_про_процессы
👍11👏4💯2❤1✍1
Когда инструкции не нужны
Любому ли сервису нужны инструкции? Мы считаем, что нет.
Вот минимум три случая, когда инструкции можно не писать:
✅ Понятный интерфейс. Только не по мнению разработчиков: такой вывод можно сделать после UX-тестов и когда мало обращений в поддержку. Более понятным делают интерфейс, например, подсказки прямо в нем, эдакие мини-инструкции, но встроенные в интерфейс. А иногда и они не нужны, если сервис простой, и дизайнер хорошо спроектировал интерфейсы.
✅ Стандартный сервис, знакомый пользователям по аналогичным. Например, в инструкциях не нуждается большинство простых интернет-магазинов, потому что флоу там всегда примерно одинаковый и привычный пользователям: каталог — корзина — адрес доставки — оплата.
✅ Сервис давно существует и не обновляется, новых пользователей почти не появляется. Например, внутренний портал для управления ценами. Мы знаем, что им пользуется ограниченное число сотрудников, и даже если приходит новый, опытные коллеги быстро научат его использовать портал.
Правда, не стоит забывать один нюанс. Даже если интерфейс максимально понятный и привычный, инструкции могут быть нужны для действий вне его. Например, можно не рассказывать, как заказать такси, если все очень просто, но придется рассказать о том, как вернуть деньги за отмененную поездку.
Какие еще кейсы можете назвать? Или считаете, что инструкции нужны всегда?
#давайте_лайфхак
Любому ли сервису нужны инструкции? Мы считаем, что нет.
Вот минимум три случая, когда инструкции можно не писать:
✅ Понятный интерфейс. Только не по мнению разработчиков: такой вывод можно сделать после UX-тестов и когда мало обращений в поддержку. Более понятным делают интерфейс, например, подсказки прямо в нем, эдакие мини-инструкции, но встроенные в интерфейс. А иногда и они не нужны, если сервис простой, и дизайнер хорошо спроектировал интерфейсы.
✅ Стандартный сервис, знакомый пользователям по аналогичным. Например, в инструкциях не нуждается большинство простых интернет-магазинов, потому что флоу там всегда примерно одинаковый и привычный пользователям: каталог — корзина — адрес доставки — оплата.
✅ Сервис давно существует и не обновляется, новых пользователей почти не появляется. Например, внутренний портал для управления ценами. Мы знаем, что им пользуется ограниченное число сотрудников, и даже если приходит новый, опытные коллеги быстро научат его использовать портал.
Правда, не стоит забывать один нюанс. Даже если интерфейс максимально понятный и привычный, инструкции могут быть нужны для действий вне его. Например, можно не рассказывать, как заказать такси, если все очень просто, но придется рассказать о том, как вернуть деньги за отмененную поездку.
Какие еще кейсы можете назвать? Или считаете, что инструкции нужны всегда?
#давайте_лайфхак
👍9🔥2👏1💯1🤨1
Знаем, что многие очень ждут фотографии с Techdoc митапа 🙃
Наконец, можем поделиться ими. Заходите по ссылке, вспоминайте самые позитивные и интересные моменты и ищите себя 😊
Наконец, можем поделиться ими. Заходите по ссылке, вспоминайте самые позитивные и интересные моменты и ищите себя 😊
🍾9❤7👍4
Где искать вопросы для FAQ
Вот несколько очевидных и не очень источников вопросов для раздела «Вопросы и ответы».
✅ Пройдите все сценарии как пользователь. В процессе фиксируйте возникающие вопросы и сомнения.
✅ Покажите коллегам не из продукта. Можно и друзьям, если они согласятся и NDA позволяет. Главное – незамыленный взгляд.
✅ Спросите пользователей. Если есть возможность добраться до конечных пользователей, спросите у них, что им непонятно про продукт и какие проблемы возникают при его использовании. Можно использовать рассылки, формы обратной связи и т.д., только не заспамьте.
✅ Спросите поддержку. Если продукт уже действующий и передан на поддержку, у специалистов, работающих с обращениями, наверняка, уже набрался большой пул частых вопросов.
✅ Почитайте отзывы в магазинах приложений. Если вы работаете над приложением, которое есть в AppStore и Google Play, мониторьте отзывы там. Пользователи часто пишут в них о возникающих проблемах и непонятных моментах.
✅ Добавьте стандартные вопросы. Практически любой FAQ разумно начать с вопросов о том, зачем нужен сервис и кто может им пользоваться. Всегда актуальны вопросы об учетной записи — проблемах с авторизацией, удалении своего аккаунта и т. п.
Есть еще идеи? Делитесь в комментариях.
#давайте_практику
Вот несколько очевидных и не очень источников вопросов для раздела «Вопросы и ответы».
✅ Пройдите все сценарии как пользователь. В процессе фиксируйте возникающие вопросы и сомнения.
✅ Покажите коллегам не из продукта. Можно и друзьям, если они согласятся и NDA позволяет. Главное – незамыленный взгляд.
✅ Спросите пользователей. Если есть возможность добраться до конечных пользователей, спросите у них, что им непонятно про продукт и какие проблемы возникают при его использовании. Можно использовать рассылки, формы обратной связи и т.д., только не заспамьте.
✅ Спросите поддержку. Если продукт уже действующий и передан на поддержку, у специалистов, работающих с обращениями, наверняка, уже набрался большой пул частых вопросов.
✅ Почитайте отзывы в магазинах приложений. Если вы работаете над приложением, которое есть в AppStore и Google Play, мониторьте отзывы там. Пользователи часто пишут в них о возникающих проблемах и непонятных моментах.
✅ Добавьте стандартные вопросы. Практически любой FAQ разумно начать с вопросов о том, зачем нужен сервис и кто может им пользоваться. Всегда актуальны вопросы об учетной записи — проблемах с авторизацией, удалении своего аккаунта и т. п.
Есть еще идеи? Делитесь в комментариях.
#давайте_практику
👍12✍3❤1🔥1
Как писать вопросы и ответы в FAQ. Вредные советы
Создаём раздел вопросов и ответов по вашему продукту, продолжаем тему.
Если вы хотите, чтобы читатель точно убежал со странички вопрос-ответов, сделайте вот что:
✅ Пишите вопросы и ответы на маркетинговом языке. Конечно, ведь любой нормальный пользователь так и спрашивает — «Какие уникальные преимущества есть у вашего сервиса?»
✅ Спрашивайте не как пользователь, а как адвокат на суде — «В какие сроки осуществляется возврат денежных средств по отмененным заказам?».
✅ Пишите про пользователя в третьем лице, ему же будет приятно читать формулировки вроде «Пользователю нужно отправить заявку».
✅ Раз уж пользователь «задал вопрос», вываливайте на него всю информацию сразу. Ну и что, что он спросил, как тратить баллы, расскажите все-все условия вашей программы лояльности.
✅ Задавайте закрытые вопросы, а отвечайте как на открытые, это же так логично. «Можно ли оплачивать заказ картой?» — «В нашем сервисе можно оплачивать заказы наличными, СБП, улыбкой, по QR-коду, стикером, картой, чеками и бонусами».
#давайте_практику
Создаём раздел вопросов и ответов по вашему продукту, продолжаем тему.
Если вы хотите, чтобы читатель точно убежал со странички вопрос-ответов, сделайте вот что:
✅ Пишите вопросы и ответы на маркетинговом языке. Конечно, ведь любой нормальный пользователь так и спрашивает — «Какие уникальные преимущества есть у вашего сервиса?»
✅ Спрашивайте не как пользователь, а как адвокат на суде — «В какие сроки осуществляется возврат денежных средств по отмененным заказам?».
✅ Пишите про пользователя в третьем лице, ему же будет приятно читать формулировки вроде «Пользователю нужно отправить заявку».
✅ Раз уж пользователь «задал вопрос», вываливайте на него всю информацию сразу. Ну и что, что он спросил, как тратить баллы, расскажите все-все условия вашей программы лояльности.
✅ Задавайте закрытые вопросы, а отвечайте как на открытые, это же так логично. «Можно ли оплачивать заказ картой?» — «В нашем сервисе можно оплачивать заказы наличными, СБП, улыбкой, по QR-коду, стикером, картой, чеками и бонусами».
#давайте_практику
😁8👍5🔥1
Нам очень интересно узнать, кто наши подписчики :-) Расскажете в опросе и комментариях?
Anonymous Poll
79%
Я технический писатель
5%
Работаю в IT, но не техпис
11%
Работаю с текстами, но не техпис
5%
Другое
👍3