Поддержка будет довольна — топ-5 советов для описания проблем и решений
Один из самых распространенных типов документа в инструкциях для поддержки — описание проблем и решений.
Мы собрали топ-5 советов, как описать проблемы и решения так, чтобы этот документ был полезен коллегам.
Совет #1
Публикуйте страницу с проблемами и решениями отдельно от пользовательской документации.
Это упростит поиск по всему документу и сделает его структуру более понятной, ведь со временем документ точно станет больше.
Совет #2
Описывайте только сами проблемы и их пошаговый путь решения.
Информацию о том, как работать с сервисами, получить доступ, к кому обратиться с вопросами, вынесите на отдельные страницы. Сотрудники поддержки уже могут иметь доступ к сервисам, знать, как с ними работать — лишняя информация будет отвлекать.
Совет #3
Каждая проблема — отдельный законченный кейс.
Если в разных проблемах повторяются одни и те же действия, дублируйте их. Ребята из поддержки решают только одну проблему и не должны ходить по всему документу, чтобы проанализировать ее и найти решение.
Совет #4
Отдельным шагом укажите перечень того, что нужно приложить к инциденту для передачи на следующую линию поддержки. Так вы сэкономите время и силы коллег из поддержки и поможете получить тикет, не требующий уточнений.
Совет #5
Проблемы и решения сортируйте от частых к редким и от общих к частным.
Если проблем больше 10, то однотипные проблемы формируйте в блоки, например, по разделам приложения, где возникает проблема.
Все это поможет быстрее найти проблему и решить ее.
Делитесь своими советами. Что вам важно в документации для поддержки?
#давайте_лайфхак
Один из самых распространенных типов документа в инструкциях для поддержки — описание проблем и решений.
Мы собрали топ-5 советов, как описать проблемы и решения так, чтобы этот документ был полезен коллегам.
Совет #1
Публикуйте страницу с проблемами и решениями отдельно от пользовательской документации.
Это упростит поиск по всему документу и сделает его структуру более понятной, ведь со временем документ точно станет больше.
Совет #2
Описывайте только сами проблемы и их пошаговый путь решения.
Информацию о том, как работать с сервисами, получить доступ, к кому обратиться с вопросами, вынесите на отдельные страницы. Сотрудники поддержки уже могут иметь доступ к сервисам, знать, как с ними работать — лишняя информация будет отвлекать.
Совет #3
Каждая проблема — отдельный законченный кейс.
Если в разных проблемах повторяются одни и те же действия, дублируйте их. Ребята из поддержки решают только одну проблему и не должны ходить по всему документу, чтобы проанализировать ее и найти решение.
Совет #4
Отдельным шагом укажите перечень того, что нужно приложить к инциденту для передачи на следующую линию поддержки. Так вы сэкономите время и силы коллег из поддержки и поможете получить тикет, не требующий уточнений.
Совет #5
Проблемы и решения сортируйте от частых к редким и от общих к частным.
Если проблем больше 10, то однотипные проблемы формируйте в блоки, например, по разделам приложения, где возникает проблема.
Все это поможет быстрее найти проблему и решить ее.
Делитесь своими советами. Что вам важно в документации для поддержки?
#давайте_лайфхак
❤26🔥8✍2
Вначале было НЕ слово
Работа технического писателя с новым сервисом начинается вовсе не с первого слова в документации, а с анализа этого самого сервиса.
Что нужно знать о сервисе, чтобы написать хорошие инструкции?
Сервис доступен всем желающим или ограниченной аудитории (например, сотрудникам компании)?
Массовый сервис скорее потребует подробных инструкций, поскольку сложно предсказать, насколько «продвинутые» пользователи будут с ним работать. Для внутреннего же сервиса иногда достаточно описать только самые сложные сценарии или составить FAQ.
Какие сценарии предусмотрены для пользователей?
Дерево пользовательских сценариев станет как раз основой для структуры документации. К тому же, чем более сложный и запутанный пользовательский путь, тем подробнее нужна документация.
Насколько понятный интерфейс?
Если интерфейс знаком пользователям по другим сервисам — например, создание заказа, удаление аккаунта — описывать его подробно не нужно.
Если в интерфейсе есть подсказки — например, при заполнении форм — возможно, вместо инструкций стоит поработать над их текстами.
Включает ли пользовательский путь внешние действия, то есть действия вне сервиса?
Например, в каком-то из сценариев пользователю нужно отправить email или позвонить. В таком случае эти действия тоже нужно описать в инструкциях.
Есть ли в сервисе разные роли и насколько сильно различаются их возможности и интерфейсы?
Так можно понять, сколько комплектов инструкций понадобится, в какой степени тексты из инструкций для одной роли можно переиспользовать для других.
Есть ли у продукта свой Tone of Voice?
Если да, придется это учитывать. Например, говорить с пользователем в инструкциях на «ты», если в самом продукте так принято.
#давайте_практику
Работа технического писателя с новым сервисом начинается вовсе не с первого слова в документации, а с анализа этого самого сервиса.
Что нужно знать о сервисе, чтобы написать хорошие инструкции?
Сервис доступен всем желающим или ограниченной аудитории (например, сотрудникам компании)?
Массовый сервис скорее потребует подробных инструкций, поскольку сложно предсказать, насколько «продвинутые» пользователи будут с ним работать. Для внутреннего же сервиса иногда достаточно описать только самые сложные сценарии или составить FAQ.
Какие сценарии предусмотрены для пользователей?
Дерево пользовательских сценариев станет как раз основой для структуры документации. К тому же, чем более сложный и запутанный пользовательский путь, тем подробнее нужна документация.
Насколько понятный интерфейс?
Если интерфейс знаком пользователям по другим сервисам — например, создание заказа, удаление аккаунта — описывать его подробно не нужно.
Если в интерфейсе есть подсказки — например, при заполнении форм — возможно, вместо инструкций стоит поработать над их текстами.
Включает ли пользовательский путь внешние действия, то есть действия вне сервиса?
Например, в каком-то из сценариев пользователю нужно отправить email или позвонить. В таком случае эти действия тоже нужно описать в инструкциях.
Есть ли в сервисе разные роли и насколько сильно различаются их возможности и интерфейсы?
Так можно понять, сколько комплектов инструкций понадобится, в какой степени тексты из инструкций для одной роли можно переиспользовать для других.
Есть ли у продукта свой Tone of Voice?
Если да, придется это учитывать. Например, говорить с пользователем в инструкциях на «ты», если в самом продукте так принято.
#давайте_практику
🔥16👍9💯5❤3
И что тогда? А если нет?
Эти простые вопросы помогут вам понять, будут ли вопросы у пользователей. Задавайте их себе во время работы над инструкциями — по ответам вы поймёте, где у пользователя точно возникнут трудности.
Для пошаговых инструкций главный вопрос — «И что тогда?». Задайте его к каждому шагу, чтобы убедиться, что инструкция выполнима. Пользователь выполняет шаг 1 — и что тогда? Тогда он делает шаг 2 — и что тогда? Так по цепочке нужно дойти до ответа «И на этом всё» и сравнить то, к чему пришли, с целевым результатом пользователя. Если действительно получили нужный результат — отлично, работаем дальше. А если нет, возвращайтесь по цепочке обратно, чтобы понять, на каком шаге свернули не туда.
Особенное внимание обращайте на слово «если» — к предложению с этим словом всегда задавайте вопрос «А если нет?». Потому что именно это точно спросит пользователь.
Посмотрим на примере, как это работает.
Это был еще один лайфхак из серии о том, как находить слабые места в своих текстах и безжалостно их ликвидировать. Продолжение следует.
#давайте_перепишем
#давайте_лайфхак
Эти простые вопросы помогут вам понять, будут ли вопросы у пользователей. Задавайте их себе во время работы над инструкциями — по ответам вы поймёте, где у пользователя точно возникнут трудности.
Для пошаговых инструкций главный вопрос — «И что тогда?». Задайте его к каждому шагу, чтобы убедиться, что инструкция выполнима. Пользователь выполняет шаг 1 — и что тогда? Тогда он делает шаг 2 — и что тогда? Так по цепочке нужно дойти до ответа «И на этом всё» и сравнить то, к чему пришли, с целевым результатом пользователя. Если действительно получили нужный результат — отлично, работаем дальше. А если нет, возвращайтесь по цепочке обратно, чтобы понять, на каком шаге свернули не туда.
Особенное внимание обращайте на слово «если» — к предложению с этим словом всегда задавайте вопрос «А если нет?». Потому что именно это точно спросит пользователь.
Посмотрим на примере, как это работает.
Если вы используете подключение через сеть Х, обратитесь к администратору.А если нет? Если пользователь использует другое подключение или вообще не может подключиться? Давайте перепишем и дадим ответы сразу на все вопросы, чтобы пользователю не пришлось тратить время на поиски ответов. Добавим контакты администратора и сразу укажем, что делать во всех других ситуациях:
Если вы используете подключение через сеть Х, обратитесь к администратору. Иначе создайте
заявку на портале поддержки.
Это был еще один лайфхак из серии о том, как находить слабые места в своих текстах и безжалостно их ликвидировать. Продолжение следует.
#давайте_перепишем
#давайте_лайфхак
❤25🔥15✍6👍3
Release Notes, которые читают
Они похожи на личный дневник продукта: честный, лаконичный и полезный. Но на практике он часто превращается в кладбище однотипных фраз, которые никто не читает, — «исправлены ошибки, повышена стабильность».
Помните, что RN — это текст для конкретной аудитории. Для:
• пользователей — понимать, что изменилось;
• поддержки — знать, откуда берутся внезапно недовольные пользователи;
• маркетинга — рассказать миру, что продукт движется вперед;
• команды продукта — вспомнить через полгода, что же мы тогда выкатывали.
Как превратить релизноутсы в эффективный инструмент?
✅ Читабельно за 30 секунд
Говорите с пользователями на человеческом, а не техническом языке. Минимум текста — максимум пользы.
✅ Бойтесь расплывчатости
Называйте вещи своими именами. Если баг был болезненным — пользователи оценят честность.
✅ Рассказывайте, зачем
Причина превращает сухой факт в пользу.
✅ Думайте о структуре
Даже в релизноутсах есть структура — чтобы ориентироваться в тексте, как в меню любимого кафе.
— Главные изменения — влияет на жизнь пользователя.
— Улучшения — удобные мелочи.
— Исправления — все, что перестало раздражать.
— Технические детали — дополнение, если ваша аудитория технари.
✅ Добавляйте нотку бренда
Если у продукта есть ToV — используйте его.
✅ Начинайте работу задолго до релиза
• просите команду оставлять комментарии к задачам;
• собирайте обратную связь от поддержки;
• участвуйте в планировании релизов;
• создавайте шаблоны, которые экономят время команде.
#давайте_практику
Они похожи на личный дневник продукта: честный, лаконичный и полезный. Но на практике он часто превращается в кладбище однотипных фраз, которые никто не читает, — «исправлены ошибки, повышена стабильность».
Помните, что RN — это текст для конкретной аудитории. Для:
• пользователей — понимать, что изменилось;
• поддержки — знать, откуда берутся внезапно недовольные пользователи;
• маркетинга — рассказать миру, что продукт движется вперед;
• команды продукта — вспомнить через полгода, что же мы тогда выкатывали.
Как превратить релизноутсы в эффективный инструмент?
✅ Читабельно за 30 секунд
Говорите с пользователями на человеческом, а не техническом языке. Минимум текста — максимум пользы.
«Добавили поддержку СБП» — понятно.
«Реализована функциональность интеграции с СБП» — скучно и длинно.
✅ Бойтесь расплывчатости
Называйте вещи своими именами. Если баг был болезненным — пользователи оценят честность.
Плохо: «Исправлены некоторые баги, повышена стабильность».
Хорошо: «Исправили проблему, из-за которой приложение закрывалось, когда вы открывали профиль».
✅ Рассказывайте, зачем
Причина превращает сухой факт в пользу.
«Что: Добавили новые фильтры в поиске.
Зачем: Чтобы вы быстрее находили нужные товары».
✅ Думайте о структуре
Даже в релизноутсах есть структура — чтобы ориентироваться в тексте, как в меню любимого кафе.
— Главные изменения — влияет на жизнь пользователя.
— Улучшения — удобные мелочи.
— Исправления — все, что перестало раздражать.
— Технические детали — дополнение, если ваша аудитория технари.
✅ Добавляйте нотку бренда
Если у продукта есть ToV — используйте его.
Формально: «Добавлена поддержка СБП»
Дружелюбно: «Мы подружились с СБП — расплачиваться в одно касание стало проще»
Игриво: «Один клик — и оплачено. Да, мы тоже этого ждали»
✅ Начинайте работу задолго до релиза
• просите команду оставлять комментарии к задачам;
• собирайте обратную связь от поддержки;
• участвуйте в планировании релизов;
• создавайте шаблоны, которые экономят время команде.
#давайте_практику
❤21🔥16✍4👏4👍3
Три правила для UX текстов
Мы собрали интересные, на наш взгляд, правила, на которые можно опираться, когда пишешь тексты для интерфейсов.
👍 Тексты в интерфейсе — это всегда диалог с пользователем. И все тексты на экране должны быть связаны как части этого диалога. Пользователь должен понимать, для чего он нажимает на кнопку и что его ждет дальше на следующем шаге.
👍 Не манипулируйте читателями и не высказывайте оценочных суждений. Говорите о реальных последствиях того или иного действия. «Если не поставишь лайк посту, где-то загрустит котик» — звучит мило, но не всем понравится чувствовать себя обязанными. И часть читателей, вообще, может любить песиков.
👍 Уточните заранее, планируется ли локализация. Если да, учитывайте длину текста на разных языках. Возможно, где-то придется привлечь дизайнера и поправить макеты.
Конечно, это не все правила. Дополняйте своими в комментариях.
#давайте_лайфхак
Мы собрали интересные, на наш взгляд, правила, на которые можно опираться, когда пишешь тексты для интерфейсов.
👍 Тексты в интерфейсе — это всегда диалог с пользователем. И все тексты на экране должны быть связаны как части этого диалога. Пользователь должен понимать, для чего он нажимает на кнопку и что его ждет дальше на следующем шаге.
👍 Не манипулируйте читателями и не высказывайте оценочных суждений. Говорите о реальных последствиях того или иного действия. «Если не поставишь лайк посту, где-то загрустит котик» — звучит мило, но не всем понравится чувствовать себя обязанными. И часть читателей, вообще, может любить песиков.
👍 Уточните заранее, планируется ли локализация. Если да, учитывайте длину текста на разных языках. Возможно, где-то придется привлечь дизайнера и поправить макеты.
Конечно, это не все правила. Дополняйте своими в комментариях.
#давайте_лайфхак
👍10🔥9✍6❤2
Когда вы пользуетесь инструкциями, как чаще всего вы ищете в них информацию?
Anonymous Poll
59%
Встроенным поиском
16%
Ищу в Google/Яндекс и перехожу по ссылке на документацию
54%
Ищу по структуре/меню документа
3%
Свой вариант (расскажу в комментариях)
👍4🤓4✍3
Организаторы Techwriter Days выложили в открытый доступ видео выступления Кати Горбуновой и Насти Московкиной, двух авторов нашего канала.
Делимся и с вами!
https://vkvideo.ru/video-223804668_456239155
Делимся и с вами!
https://vkvideo.ru/video-223804668_456239155
VK Видео
TechWriter Days 2 — Как улучшить тексты компании через внутреннюю школу технических писателей
Анастасия Московкина, Екатерина Горбунова Когда продуктовых команд больше 300 и технических писателей на всех не хватает, вместо массового найма, мы приняли решение разработать свою школу технических писателей и научить коллег закрывать потребность в текстах…
🔥18❤9👍6❤🔥2
Настало время для елки техписа!
🎄🎄🎄
Новый год — это волшебное время, когда мы ждем чуда, дарим друг другу подарки и создаем уют в доме. Одна из любимых традиций многих семей — украшение елки собственными силами. Ведь именно этот процесс позволяет каждому почувствовать себя частью праздника и создать особенную атмосферу дома.
Каждый украшает свою елку по-своему. Кто-то каждый год покупает новый комплект игрушек в одном цвете, кто достает с антресоли коробку со старыми советскими игрушками, кто-то украшает конфетами и мандаринами…
А давайте нашу новогоднюю елку украсим пожеланиями нашему сообществу на новый год?
После новогодних праздников всем пожеланиям присвоим номерки и с помощью рандомайзера разыграем небольшой сувенир от «Давайте перепишем!»
Начнем: Мы желаем всем нам амбициозных и интересных задач в новом году!
🎄🎄🎄
Новый год — это волшебное время, когда мы ждем чуда, дарим друг другу подарки и создаем уют в доме. Одна из любимых традиций многих семей — украшение елки собственными силами. Ведь именно этот процесс позволяет каждому почувствовать себя частью праздника и создать особенную атмосферу дома.
Каждый украшает свою елку по-своему. Кто-то каждый год покупает новый комплект игрушек в одном цвете, кто достает с антресоли коробку со старыми советскими игрушками, кто-то украшает конфетами и мандаринами…
А давайте нашу новогоднюю елку украсим пожеланиями нашему сообществу на новый год?
После новогодних праздников всем пожеланиям присвоим номерки и с помощью рандомайзера разыграем небольшой сувенир от «Давайте перепишем!»
Начнем: Мы желаем всем нам амбициозных и интересных задач в новом году!
🎄25🔥8🍾3❤2👏1
Кружка техписа и воспоминания о Новом годе
Как обещали, подводим итоги нашего новогоднего розыгрыша!
Беспристрастный рандомайзер выбрал победителя, номер 16 (смотрите видео в комментариях).
И это оказалась @Katushka_13. Екатерина, поздравляем!
Поздравляем! Дарим вам вот такую кружку техписа :)
Скоро напишем вам в личные сообщения, чтоб узнать, куда отправить.
Как обещали, подводим итоги нашего новогоднего розыгрыша!
Беспристрастный рандомайзер выбрал победителя, номер 16 (смотрите видео в комментариях).
И это оказалась @Katushka_13. Екатерина, поздравляем!
Поздравляем! Дарим вам вот такую кружку техписа :)
Скоро напишем вам в личные сообщения, чтоб узнать, куда отправить.
🎉20👏13🎄10❤1😁1🤩1
Канцеляризм: найти и уничтожить
Наверное, никого из техписов не нужно убеждать, что канцеляризмам не место в инструкциях. Ведь мы пытаемся сделать их максимально краткими и дружелюбными для читателей. Но заметить их не всегда просто.
Собрали для вас список слов и выражений, которые, на наш взгляд, чаще всего проползают в наши тексты незамеченными и делают его более сухим и сложным для восприятия.
“Является”
Как переписать: чаще всего можно заменить на тире.
“Требуется”
Как переписать: лучше всего заменить на повелительное наклонение.
“Данный”
Как переписать: обычно можно просто пропустить.
“В настоящий момент”
Как переписать: пропустить или заменить на “временно” или конкретный срок, если нужно это подчеркнуть.
“В целях”
Как переписать: заменить на “для”.
“Соответствующий”
Как переписать: можно просто пропустить и указать, что именно имеется в виду.
“В противном случае”
Как иначе: заменить на “иначе”.
Замена не идеальна, как лучше формулировать в таких случаях расскажем в одном из следующих постов.
А что бы вы еще добавили в список? Какие у техписов самые частые слова-паразиты? Давайте исповедуемся в комментах про свои 😉
#давайте_практику
Наверное, никого из техписов не нужно убеждать, что канцеляризмам не место в инструкциях. Ведь мы пытаемся сделать их максимально краткими и дружелюбными для читателей. Но заметить их не всегда просто.
Собрали для вас список слов и выражений, которые, на наш взгляд, чаще всего проползают в наши тексты незамеченными и делают его более сухим и сложным для восприятия.
“Является”
Устройство Гамма является основным компонентом системы управления.
Как переписать: чаще всего можно заменить на тире.
Устройство Гамма — основной компонент системы управления.
“Требуется”
Чтобы получить доступ к новым функциям, требуется обновить систему.
Как переписать: лучше всего заменить на повелительное наклонение.
Чтобы получить доступ к новым функциям, обновите систему.
“Данный”
В данном разделе вы можете управлять заявками.
Как переписать: обычно можно просто пропустить.
В разделе вы можете управлять заявками.
“В настоящий момент”
В настоящий момент создание новых карточек товаров недоступно.
Как переписать: пропустить или заменить на “временно” или конкретный срок, если нужно это подчеркнуть.
Создание новых карточек временно недоступно.
“В целях”
В целях безопасности пароль не отображается.
Как переписать: заменить на “для”.
Для безопасности пароль не отображается.
“Соответствующий”
Загружайте обновления ПО в соответствующем порядке.
Как переписать: можно просто пропустить и указать, что именно имеется в виду.
Загружайте обновления ПО в порядке, который пришлет администратор сети.
“В противном случае”
Если вы хотите отслеживать заказ, авторизуйтесь. В противном случае нажмите Заказ в один клик.
Как иначе: заменить на “иначе”.
Если вы хотите отслеживать заказ, авторизуйтесь. Иначе нажмите Заказ в один клик.
Замена не идеальна, как лучше формулировать в таких случаях расскажем в одном из следующих постов.
А что бы вы еще добавили в список? Какие у техписов самые частые слова-паразиты? Давайте исповедуемся в комментах про свои 😉
#давайте_практику
❤31🔥10✍6👍2
Инструкция к техническому писателю. Как быстро «подружить» техписа с командой заказчика
Устали объяснять, чем вы занимаетесь и почему вас нужно звать в проект раньше, чем «вчера»? Евгения Береснева, один из авторов нашего канала, на TechWriter Days 2 рассказала про инструмент, который помогает решать эти проблемы. Организаторы опубликовали видео доклада — делимся им с вами.
Обсудим:
🔹 что нужно знать заказчику еще до привлечения техписателя к задаче
🔹 чек-лист вопросов для установочной встречи с заказчиком
🔹 рекоменации для технического писателя: как быстро влиться в команду и не тратить время на лишние согласования.
🔹 Workflow: делаем процесс работы техписателя прозрачным для всех.
Смотреть видео: https://vkvideo.ru/video-223804668_456239176
Устали объяснять, чем вы занимаетесь и почему вас нужно звать в проект раньше, чем «вчера»? Евгения Береснева, один из авторов нашего канала, на TechWriter Days 2 рассказала про инструмент, который помогает решать эти проблемы. Организаторы опубликовали видео доклада — делимся им с вами.
Обсудим:
🔹 что нужно знать заказчику еще до привлечения техписателя к задаче
🔹 чек-лист вопросов для установочной встречи с заказчиком
🔹 рекоменации для технического писателя: как быстро влиться в команду и не тратить время на лишние согласования.
🔹 Workflow: делаем процесс работы техписателя прозрачным для всех.
Смотреть видео: https://vkvideo.ru/video-223804668_456239176
VK Видео
TechWriter Days 2 — Евгения Береснева, Инструкция к техническому писателю. Как быстро «подружить» техписа с командой заказчика
В докладе расскажу про инструмент, который мы назвали "Инструкция к техническому писателю", — в нем простым языком рассказали о важных моментах работы техписателя, которые стоит донести до заказчика еще "на берегу". Я покажу все разделы инструкции и расскажу…
🔥11❤6👍3🥰1
Документация API: пишем первое описание метода
Эндпоинты, коды, JSON, Swagger, Postman — новичку бывает страшно даже заглянуть в документацию API. С чего начать и как не потеряться в деталях — разбираемся вместе.
Работа над документацией API начинается с понимания, для чего существует API, какие задачи решает и для кого. Документацию API обычно пишут для разработчиков, поэтому каждое описание должно чётко и максимально кратко объяснять, зачем нужен метод, как сделать запрос, что будет в ответе.
Начните с описания самого простого метода, обычно это получение данных.
В описании укажите:
• URL ресурса, куда отправляем запрос
• HTTP-метод — действие, которое выполняет метод
• Название метода
• Что делает метод
• Параметры запроса и как их передать. Для каждого параметра добавьте имя, краткое описание, тип данных, обязательность. В нашем примере параметр передаём в пути (path)
• Коды ответов с расшифровкой их значений — что вернёт метод
• Поля ответа — что получим в ответе. Также с краткими описаниями, типом данных, обязательностью
• Пример успешного запроса
• Примеры разных ответов
200
404
Неважно, какие инструменты публикации вы будете использовать — структура описания метода будет одинаковой и в таблице, и в тексте, и в спецификации OpenAPI. Главное, не бояться заглянуть глубже )
#давайте_практику
Эндпоинты, коды, JSON, Swagger, Postman — новичку бывает страшно даже заглянуть в документацию API. С чего начать и как не потеряться в деталях — разбираемся вместе.
Работа над документацией API начинается с понимания, для чего существует API, какие задачи решает и для кого. Документацию API обычно пишут для разработчиков, поэтому каждое описание должно чётко и максимально кратко объяснять, зачем нужен метод, как сделать запрос, что будет в ответе.
Начните с описания самого простого метода, обычно это получение данных.
В описании укажите:
• URL ресурса, куда отправляем запрос
https://api.market.com/v1/users/{id}
• HTTP-метод — действие, которое выполняет метод
GET
• Название метода
Получить имя пользователя
• Что делает метод
Метод возвращает имя пользователя по его ID
• Параметры запроса и как их передать. Для каждого параметра добавьте имя, краткое описание, тип данных, обязательность. В нашем примере параметр передаём в пути (path)
Параметр: id
Где передаётся: path
Тип: integer
Обязательность: true
Описание: ID пользователя
• Коды ответов с расшифровкой их значений — что вернёт метод
200 OK — Успех
404 Not found — Пользователь не найден
• Поля ответа — что получим в ответе. Также с краткими описаниями, типом данных, обязательностью
Поле: name
Описание: Имя пользователя
Тип: string
Обязательность: true
• Пример успешного запроса
https://api.market.com/v1/users/15437
• Примеры разных ответов
200
{ "name": "Иван" }
404
{ "error": "Пользователь не найден" }
Неважно, какие инструменты публикации вы будете использовать — структура описания метода будет одинаковой и в таблице, и в тексте, и в спецификации OpenAPI. Главное, не бояться заглянуть глубже )
#давайте_практику
❤31✍10🔥9👍4
Давайте розыгрыш!
Уже совсем скоро нас ждёт классная конференция WriteConf, где соберутся все, кто работает с текстами в IT. Это технические писатели, UX-редакторы, контент-менеджеры, локализаторы и много кто еще.
26 февраля в Москве (и онлайн).
Мы были на прошлой WriteConf всей нашей редакцией и нам очень понравилось. В этот раз тоже шикарные доклады, нетворкинг и даже прожарка текстов в прямом эфире и нытинг-сессия 😱 😁
По уже сложившейся традиции разыгрываем билет на конференцию 🎉
Билет офлайн — то есть посещение всех докладов, доступ к записям, нетворкинг и afterparty.
Условия простые:
— Быть подписанным на наш канал и канал конференции.
— Написать в комментах в свободной форме о вашем желании участвовать.
Через неделю присвоим всем номерки и запустим рандомайзер.
Делитесь постом с коллегами, чтобы и им дать шанс (ну или не делитесь, чтобы оставить все шансы себе 😁).
#давайте_анонс
Уже совсем скоро нас ждёт классная конференция WriteConf, где соберутся все, кто работает с текстами в IT. Это технические писатели, UX-редакторы, контент-менеджеры, локализаторы и много кто еще.
26 февраля в Москве (и онлайн).
Мы были на прошлой WriteConf всей нашей редакцией и нам очень понравилось. В этот раз тоже шикарные доклады, нетворкинг и даже прожарка текстов в прямом эфире и нытинг-сессия 😱 😁
По уже сложившейся традиции разыгрываем билет на конференцию 🎉
Билет офлайн — то есть посещение всех докладов, доступ к записям, нетворкинг и afterparty.
Условия простые:
— Быть подписанным на наш канал и канал конференции.
— Написать в комментах в свободной форме о вашем желании участвовать.
Через неделю присвоим всем номерки и запустим рандомайзер.
Делитесь постом с коллегами, чтобы и им дать шанс (ну или не делитесь, чтобы оставить все шансы себе 😁).
#давайте_анонс
❤18🔥18👍12⚡3
Тестовое онлайн. Чего ждать?
Уже не раз в профессиональных чатах, да и мы на канале, обсуждали тестовые задания и портфолио. А тем временем всё больше работодателей стали давать тестовые задания прямо на собеседовании. Постараемся рассказать об основных видах заданий на собеседованиях, которые были в нашей практике.
Вычитка
Мы встречали разные варианты: от «вычитать 3 абзаца» до «154 страницы за 40 минут». Ожидания от этих двух заданий абсолютно разные.
Разработка структуры документа
На таких заданиях просят накидать основу для структуры какого-то известного b2c сервиса.
Работа с GIT
Тут тоже были вариации на тему: от «решить простенький конфликт» до конкретных задач. Например таких: реши проблему «При git pull или git fetch: «error: cannot lock ref 'refs/remotes/origin/{branch}': is at {commit-sha1} but expected {commit-sha1}»».
Логические задачки
Да-да, они до сих пор актуальны. Про лампочки, ведра и т.д.
Задание на английском
Как-то раз было задание прочитать текст на английском и по нему ответить на вопросы на русском языке.
А вы встречали на собеседованиях практические задания в прямом эфире? Если да, то какие?
#давайте_про_профессию
Уже не раз в профессиональных чатах, да и мы на канале, обсуждали тестовые задания и портфолио. А тем временем всё больше работодателей стали давать тестовые задания прямо на собеседовании. Постараемся рассказать об основных видах заданий на собеседованиях, которые были в нашей практике.
Вычитка
Мы встречали разные варианты: от «вычитать 3 абзаца» до «154 страницы за 40 минут». Ожидания от этих двух заданий абсолютно разные.
Разработка структуры документа
На таких заданиях просят накидать основу для структуры какого-то известного b2c сервиса.
Работа с GIT
Тут тоже были вариации на тему: от «решить простенький конфликт» до конкретных задач. Например таких: реши проблему «При git pull или git fetch: «error: cannot lock ref 'refs/remotes/origin/{branch}': is at {commit-sha1} but expected {commit-sha1}»».
Логические задачки
Да-да, они до сих пор актуальны. Про лампочки, ведра и т.д.
Задание на английском
Как-то раз было задание прочитать текст на английском и по нему ответить на вопросы на русском языке.
А вы встречали на собеседованиях практические задания в прямом эфире? Если да, то какие?
#давайте_про_профессию
✍7🔥5⚡2👍2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Кому повезло в розыгрыше?
Пятница 13-е оказалась счастливым днём для @nanoanna 🎉🎉🎉
Скоро свяжемся и расскажем, как получить ваш билетик :)
Для всех остальных наших подписчиков тащим промокод на скидку 10%. Введите при покупке ДавайтеСкидку.
Увидимся 26-го ;-)
#давайте_анонс
Пятница 13-е оказалась счастливым днём для @nanoanna 🎉🎉🎉
Скоро свяжемся и расскажем, как получить ваш билетик :)
Для всех остальных наших подписчиков тащим промокод на скидку 10%. Введите при покупке ДавайтеСкидку.
Увидимся 26-го ;-)
#давайте_анонс
🔥10👍9👏6😢3❤1
Узнать свою ЦА
Чем лучше мы понимаем наших читателей, тем лучше они будут понимать наши тексты.
И вот что стоит выяснить в первую очередь:
🖌 Опыт работы с IT-технологиями. Водителям фур, которых перевели на работу с мобильным приложением после десятилетий работы с бумажными документами, объяснять все придется намного подробнее, чем аудитории, которая всю жизнь работает за компьютером.
🖌 Образование и профессия. Инструкция по работе с перевозками для логиста должна выглядеть иначе, чем для менеджера по продажам. Например, в ней можно без расшифровки использовать профессиональные термины.
🖌 Контекст работы с документацией. Инструкция всегда открыта в соседней вкладке браузера или лежит на рабочем столе в печатном виде? Открывается только при возникновении проблем или в начале работы? Читают с телефона или с компьютера?
А вот возраст имеет значение далеко не всегда, ведь на опыт работы с IT он влияет лишь косвенно.
А как техпису добраться до своих читателей, чтобы лучше их узнать, расскажем в одном из следующих постов.
#давайте_про_процессы
Чем лучше мы понимаем наших читателей, тем лучше они будут понимать наши тексты.
И вот что стоит выяснить в первую очередь:
🖌 Опыт работы с IT-технологиями. Водителям фур, которых перевели на работу с мобильным приложением после десятилетий работы с бумажными документами, объяснять все придется намного подробнее, чем аудитории, которая всю жизнь работает за компьютером.
🖌 Образование и профессия. Инструкция по работе с перевозками для логиста должна выглядеть иначе, чем для менеджера по продажам. Например, в ней можно без расшифровки использовать профессиональные термины.
🖌 Контекст работы с документацией. Инструкция всегда открыта в соседней вкладке браузера или лежит на рабочем столе в печатном виде? Открывается только при возникновении проблем или в начале работы? Читают с телефона или с компьютера?
А вот возраст имеет значение далеко не всегда, ведь на опыт работы с IT он влияет лишь косвенно.
А как техпису добраться до своих читателей, чтобы лучше их узнать, расскажем в одном из следующих постов.
#давайте_про_процессы
🔥15👍9✍4❤1