Запускаем цикл постов про работу продактов в разных доменов | Developer Experience 🧑💻
Есть мнение, что если твой пользователь - разработчик, то с UX можно особо не заморачиваться. Он технический, документацию прочитает, ошибку поймёт, со сложным сценарием разберётся.
Но технический пользователь — всё ещё пользователь.
Привет! Я Валентина. Последние несколько лет я работаю с продуктами для разработчиков.
И одна из вещей, в которой я точно убедилась:
«Разработчик? - он же умный! - разберется!» - плохая продуктовая стратегия.
Давайте возьмём обычный сценарий.
Разработчик приходит на платформу, чтобы:
➡️ загрузить продукт
➡️ протестировать
➡️ опубликовать
➡️ понять, что происходит с продуктом после публикации
➡️ получить обратную связь
➡️ выпустить следующую версию
На словах все довольно просто. А дальше начинается магия. Потому что под каждым таким шагом может лежать миллион зависимостей и ограничений:
- разные форматы файлов и их версии;
- технические требования платформы;
- права доступа;
- разные состояния продукта;
- валидации и ошибки;
- процессы модерации;
- метрики и отзывы;
- ограничения внутренних систем;
и ещё десяток зависимостей, о которых пользователь вообще не должен задумываться.
И вот здесь очень легко попасть в ловушку:
«Ну это же разработчик. Поймёт».
Но для пользователя важно не просто, чтобы он как-то в принципе смог разобраться. Основная задача - сделать так, чтобы ему не приходилось разбираться там, где продукт может сделать это за него. Для пользователя не существует внутренней архитектуры, ограничений и того, что одна маленькая кнопка на самом деле завязана еще на три системы и две команды. У него есть задача, которую он хочет выполнить максимально просто и понятно.
И вот это, наверное, одна из самых интересных вещей в работе продакта с Developer Experience.
Ты должен знать все эти технические нюансы и понимать, как они между собой связаны, где реально нельзя по-другому, а где просто «исторически так сложилось». И уже затем из всего этого собрать нормальный человеческий сценарий.
При этом разработчики - очень требовательные пользователи. Они заметят вообще все: микрокосяк, странный текст ошибки, непонятный статус, найдут очень интересный corner case. А затем обязательно придут с вопросом:
«А почему вы это просто не исправите? Тут же легко». - Но ты и твоя команда знает, что это далеко не так.
Три вещи основные вещи, которые я бы выделила при работе с developer-продуктами:
💡 Техническая аудитория не отменяет UX.
Скорее наоборот: чем сложнее сам продукт, тем меньше сложности хочется перекладывать на пользователя.
💡 Техническое ограничение - не оправдание.
Само ограничение может быть неизбежным. Но то, как с ним столкнётся пользователь, - уже продуктовая задача.
💡 Разработчиков тоже нужно исследовать.
Понимать техническую логику продукта ≠ понимать реальный сценарий человека, который им пользуется.
Паблишеры, разработчики, администраторы, интеграторы — всё это пользователи.
Просто со своими задачами, контекстом и очень хорошим радаром на продуктовые косяки
📝 А если вы работаете с технической аудиторией — где у вас проходит граница между «пользователь разберётся» и «мы должны сделать это понятнее»?
Автор: Валентина Князева — Product Manager, автор канала «Валь, что думаешь?» — про жизнь, работу в IT и продуктовые инсайты.
Есть мнение, что если твой пользователь - разработчик, то с UX можно особо не заморачиваться. Он технический, документацию прочитает, ошибку поймёт, со сложным сценарием разберётся.
Но технический пользователь — всё ещё пользователь.
Привет! Я Валентина. Последние несколько лет я работаю с продуктами для разработчиков.
И одна из вещей, в которой я точно убедилась:
«Разработчик? - он же умный! - разберется!» - плохая продуктовая стратегия.
Давайте возьмём обычный сценарий.
Разработчик приходит на платформу, чтобы:
➡️ загрузить продукт
➡️ протестировать
➡️ опубликовать
➡️ понять, что происходит с продуктом после публикации
➡️ получить обратную связь
➡️ выпустить следующую версию
На словах все довольно просто. А дальше начинается магия. Потому что под каждым таким шагом может лежать миллион зависимостей и ограничений:
- разные форматы файлов и их версии;
- технические требования платформы;
- права доступа;
- разные состояния продукта;
- валидации и ошибки;
- процессы модерации;
- метрики и отзывы;
- ограничения внутренних систем;
и ещё десяток зависимостей, о которых пользователь вообще не должен задумываться.
И вот здесь очень легко попасть в ловушку:
«Ну это же разработчик. Поймёт».
Но для пользователя важно не просто, чтобы он как-то в принципе смог разобраться. Основная задача - сделать так, чтобы ему не приходилось разбираться там, где продукт может сделать это за него. Для пользователя не существует внутренней архитектуры, ограничений и того, что одна маленькая кнопка на самом деле завязана еще на три системы и две команды. У него есть задача, которую он хочет выполнить максимально просто и понятно.
И вот это, наверное, одна из самых интересных вещей в работе продакта с Developer Experience.
Ты должен знать все эти технические нюансы и понимать, как они между собой связаны, где реально нельзя по-другому, а где просто «исторически так сложилось». И уже затем из всего этого собрать нормальный человеческий сценарий.
При этом разработчики - очень требовательные пользователи. Они заметят вообще все: микрокосяк, странный текст ошибки, непонятный статус, найдут очень интересный corner case. А затем обязательно придут с вопросом:
«А почему вы это просто не исправите? Тут же легко». - Но ты и твоя команда знает, что это далеко не так.
Три вещи основные вещи, которые я бы выделила при работе с developer-продуктами:
💡 Техническая аудитория не отменяет UX.
Скорее наоборот: чем сложнее сам продукт, тем меньше сложности хочется перекладывать на пользователя.
💡 Техническое ограничение - не оправдание.
Само ограничение может быть неизбежным. Но то, как с ним столкнётся пользователь, - уже продуктовая задача.
💡 Разработчиков тоже нужно исследовать.
Понимать техническую логику продукта ≠ понимать реальный сценарий человека, который им пользуется.
Паблишеры, разработчики, администраторы, интеграторы — всё это пользователи.
Просто со своими задачами, контекстом и очень хорошим радаром на продуктовые косяки
📝 А если вы работаете с технической аудиторией — где у вас проходит граница между «пользователь разберётся» и «мы должны сделать это понятнее»?
Автор: Валентина Князева — Product Manager, автор канала «Валь, что думаешь?» — про жизнь, работу в IT и продуктовые инсайты.