Хотя на первый взгляд они могут показаться похожими, Developer Experience (DX) — это не просто «пользовательский опыт (UX) для разработчиков». Скорее, DX — это расширение UX, ориентированное на пользователей, которые создают свои продукты с помощью технических языков и инструментов. DX следует тем же основным принципам UX, но расширяет их, признавая, что технические детали и механические процессы могут быть поняты и эффективно использованы разработчиком.
Отличный DX происходит, когда разработчики чувствуют, что с ними разговаривают и напрямую удовлетворяют их потребности. Это означает демонстрацию кода, предоставление большого количества деталей и четких инструкций для множества вариантов использования.
Пользовательский опыт — это набор общих принципов, наиболее часто применяемых к конечным пользователям, которые могут быть нетехническими специалистами и использовать программное обеспечение как для деловых нужд, так и для личного потребления. Опыт разработчиков ориентирован на то, чтобы разработчики могли использовать программное обеспечение для создания решений. Различия между UX и DX обусловлены разными потребностями конечных пользователей и разработчиков. В этой статье мы рассмотрим, что такое хороший UX и DX, ключевые различия между ними и практические различия, когда вы разрабатываете продукты для разработчиков.
Отличный DX начинается с принципов UX
Хороший UX состоит из двух компонентов: упростить начало использования вашего продукта и обеспечить приятное продолжение работы с ним. Опыт разработчиков расширяет эти же основные идеи, применяемые к технической аудитории, ориентированной на достижение конкретных целей.
Во-первых, максимально упростите начало использования нового продукта. В UX это, как правило, означает отказ от потоков регистрации, если это возможно, или их упрощение, если они необходимы. Продукты должны быть интуитивно понятными — конечный пользователь или разработчик должен иметь возможность начать использовать ваш продукт и достичь своих целей с минимальными инструкциями. Также очень важно помнить о ценности, которую предоставляет ваш продукт. Для оценки UX и DX можно использовать одни и те же инструменты, такие как A/B-тестирование, опросы пользователей и аналитические программы.
Первое ключевое различие между UX и DX — это путешествие пользователя. Хороший UX делает путь пользователя к вашему продукту как можно более простым. Слишком большой выбор может быть подавляющим для конечных пользователей, что может затруднить выполнение задачи и получение ценности от продукта. Хороший DX должен быть более гибким, чтобы обеспечить множество различных возможных целей разработчиков. Аналогично, хотя конечным пользователям не нужны технические подробности для успешного использования вашего продукта, разработчикам необходим доступ к подробной информации, чтобы можно было оценить их требования. Хороший DX облегчает разработчикам понимание того, как работает продукт или услуга, чтобы они могли успешно работать с ним.
В то время как хороший UX делает продукт одинаково доступным для пользователей с разными техническими возможностями, DX должен учитывать технические возможности разных пользователей и предлагать разные уровни поддержки. Более опытные разработчики хотят получить доступ к более мощным инструментам, в то время как менее опытным разработчикам может потребоваться начать с более простого рабочего процесса, который легче настроить. Важно понимать, каким уровнем технических способностей обладают ваши основные пользователи, чтобы сделать опыт разработчиков более соответствующим вашим продуктам.
Теперь, когда мы сравнили высокоуровневые различия между опытом разработчика и опытом пользователя, мы рассмотрим пример приложения, которое показывает разницу на практике.
UX Vs. DX — практический пример
Давайте рассмотрим, как UX и DX выглядят в реальном мире.
Большинство из нас, вероятно, были конечными пользователями потребительского приложения для покупок. Представьте себе пользователя, который впервые заходит в новое приложение для покупок и ищет новый свитер. Он может ввести поисковый запрос «свитер» в поисковую строку или перейти к навигации по категориям. Затем они выберут свитер, который им понравится, и добавят его в корзину. Для оформления заказа, возможно, придется создать учетную запись с информацией о выставлении счета и доставке, или просто нажать кнопку «Оплатить с помощью PayPal» и предоставить сайту сделать все остальное. Теперь нашему пользователю остается только ждать, когда его свитер будет доставлен.
Теперь представьте, что разработчик создает ту же функциональность в новом приложении. Если не принимать во внимание API, используемые для поиска, у них будет как минимум один API для аутентификации и выставления счетов, а возможно, и больше. Сначала нужно будет установить все необходимые библиотеки или SDK и решить вопросы зависимости. Затем разработчик должен сгенерировать ключ API и добавить его в переменные окружения приложения для повторного использования. Затем разработчик пишет вызов API к конечной точке аутентификации пользователя и пишет слушатель, который подтверждает, что пользователь прошел аутентификацию. Следующим шагом будет написание вызова бэкенда приложения, который подтвердит, что в наличии еще есть свитера, и вызов API для обработки платежа. Наконец, если оплата прошла успешно, разработчик должен написать код, который прослушивает ответ от API, обновляет бэкенд, чтобы удалить свитер из инвентаря, отправляет информацию в фулфилмент-центр и планирует доставку посылки.
Чтобы разработчик смог успешно создать такое приложение, он должен понимать, какие конечные точки API следует использовать, какие методы разрешены в разных конечных точках, какие ответы следует ожидать от API и как надежно аутентифицировать вызовы API с помощью ключа API. Без хорошего DX разработчики могут спокойно отказаться от вашего продукта в любой момент, если не смогут быстро решить проблемы, или вообще не попытаться реализовать его, если не уверены в успехе.
Подобно тому, как у потребителей есть множество вариантов выбора при покупке свитера, у разработчиков есть множество вариантов инструментария. Чтобы сделать ваш выбор привлекательным, начните с хорошего DX. Разработчики выберут ваш продукт, если будут уверены, что смогут его использовать, и будут продолжать его использовать, если почувствуют успех.
Отличный опыт для разработчиков начинается со знания уникальных потребностей разработчиков как пользователей. В следующем разделе мы рассмотрим, как общие стандарты UX применяются к продуктам, ориентированным на разработчиков, и как вы можете адаптировать их к аудитории разработчиков.
Раскрытие ценности продукта API с помощью хорошего опыта разработчиков
Опыт разработчиков охватывает то, что происходит, когда разработчик взаимодействует с вашим сервисом или продуктом в процессе создания. Разработчики хотят чувствовать себя вправе создавать и внедрять инновации, а хороший DX помогает им увидеть возможности и шаги для реализации своих идей. Вам необходимо создать опыт для разработчиков, который внушает доверие, а затем контролировать, чтобы ваши пользователи добивались успеха и расширяли свои интеграции.
Давайте более подробно рассмотрим характеристики хорошего DX и то, как они часто реализуются на практике.
Разработчики должны иметь возможность настраивать используемые ими сервисы в соответствии с различными рабочими процессами. Линейный путь пользователя менее чем идеален, поскольку он не отражает того, как работают разработчики и как создаются приложения. Отличный DX предоставляет инструменты и информацию для поддержки гибкости, поэтому ваш продукт должен поддерживать различные конфигурации, когда это возможно. Этого можно добиться следующими способами:
- Предоставление ряда хорошо проанализированных конечных точек API.
- Разработка SDK на нескольких языках
- Разделение кода на более мелкие методы многократного использования
- Создавайте читабельный код без жаргона
- Подробно документируйте свой продукт
Очень важно, чтобы вы предоставили разработчикам достаточно информации для понимания технических деталей вашего продукта.
Ваша документация — это точка входа разработчика в ваш продукт, которая влияет на его решение о внедрении. Если разработчики смогут понять, как работает ваш продукт, они смогут уверенно внедрить его в свой рабочий процесс. Вам нужна четкая, актуальная и подробная документация, чтобы разработчики могли научиться использовать ваш продукт, устранять неполадки и интегрировать его в существующие рабочие процессы. Это особенно важно, если вы создаете свой продукт для разработчиков с разным набором навыков и уровнем знаний.
В конечном счете, разработчики должны чувствовать, что вы понимаете их болевые точки и что ваш продукт, инструменты и документация решают их. При наличии хорошего DX любой разработчик должен быть в состоянии настроить базовую реализацию вашего продукта с минимальными инструкциями. Более опытные разработчики должны чувствовать себя уверенно, расширяя функциональность вашего продукта для решения уникальных задач. Этого можно достичь, показывая примеры кода, предоставляя подробные объяснения в документации, используя аналитику API, чтобы понять, как разработчики используют ваш API, и демонстрируя наглядные примеры для нескольких вариантов использования.
Опыт разработчиков: Не ограничивайтесь первым впечатлением
Для удержания разработчиков требуется нечто большее, чем первое впечатление. Как хороший UX нужно оценивать, совершенствовать и тестировать с течением времени, так и хороший DX — это инвестиции в долгосрочную перспективу. Вы не сможете узнать, насколько вам удалось добиться успеха, если не будете использовать аналитику для оценки DX и тестирования изменений. Мониторинг API поможет вам выявить пользователей, которые не смогли успешно выполнить вызовы API, обнаружить закономерности успеха и неудачи для разработчиков и увидеть, как различные пользователи взаимодействуют с вашим продуктом с течением времени. Если отслеживание UX-метрик относительно просто для продуктов, ориентированных на конечных пользователей, то DX-метрики отличаются по важным параметрам. Вам необходимо разработать хорошую стратегию для аналитики API, чтобы отслеживать соответствующие показатели бизнес-ценности, избегая при этом суетных показателей.
Хотя опыт разработчиков имеет много общих ключевых аспектов с пользовательским опытом, важно помнить, что разработчики имеют специфические потребности, выходящие за рамки стандартных принципов UX. Вам необходимо понимать DX, когда вы создаете продукты для разработчиков, чтобы привлечь пользователей-разработчиков, вселить в них уверенность и креативность, а также поддерживать их все более сложные интеграции с течением времени. Создание хорошего UX и DX может быть сложной задачей, но с помощью Moesif API Analytics вы можете контролировать работу вашего API и использовать метрики для создания идеального опыта разработчиков API.
Эта статья была первоначально написана для блога Moesif Адамом Дювандером, специалистом по общению с разработчиками.