Как масштабироваться на международном уровне: глобальный дизайн продукта

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

Прекрасным примером является запуск мобильной операционной системы Apple iOS6 в 2012 году. Одним из ключевых нововведений, которое так взволновало поклонников Apple, был анонс нового приложения Apple Maps, недавно созданного внутри Apple, включая мировую премьеру 3D Maps. Однако через несколько дней после запуска приложение Apple Maps было признано публично провальным, с серьезными проблемами в результатах поиска и переводе местоположения (например, Берлин стал Schoneiche bei Berlin; поиск Лондона в Великобритании привел к Лондону, Онтарио, Канада; и в Ирландии внезапно появился новый аэропорт). Запуск продукта более чем в 100 странах одновременно — это огромная задача, и некоторые сбои неизбежно произойдут, но руководители Apple, объявившие, что приложение готово к выпуску, упустили из виду некоторые основные выводы.

Архитектура продукта имеет значение

Ключевым требованием к глобальному дизайну продукта является закладка основ архитектуры продукта, которые легко адаптируются к различным странам. Крайне важно убедиться, что все текстовые компоненты (так называемые «строки») структурированы таким образом, чтобы их было легко извлечь для перевода, а затем реинтегрировать. Создание функциональной матрицы функций, показывающей, какие функции появляются и когда, также является важным шагом. Он должен обрабатывать больше контекстной информации, такой как местоположение, регион телефона или язык телефона, чем чисто локальный продукт. Включение набора функций продукта для адаптации к обнаруженному местоположению пользователя не должно быть второстепенным. Поскольку в разных странах уровень сотового трафика, как правило, разный, командам разработчиков приходится решать, какая часть архитектурной логики должна находиться на сервере, а какая — на устройстве пользователя. Некоторым продуктам также может потребоваться автономный режим, который является подмножеством функций, доступных, когда телефон или устройство не подключены к сети. Принимая во внимание все эти компоненты, продукт будет готов к масштабированию, будь то для двух или 50 стран.

Производительность и серверная архитектура — еще два ключевых вопроса, которые необходимо решить заранее. Для обеспечения адекватной производительности продукта в режиме 24/7 в странах по всему миру требуется серверная архитектура с достаточным количеством серверных узлов и возможностями балансировки нагрузки. В зависимости от объема трафика продуктовые команды должны решить, нужны ли им серверные узлы в США, Латинской Америке, Европе или Азии, поскольку более оптимально располагать узлы ближе к регионам с высоким трафиком, чтобы обеспечить реальную производительность. время отклика. Основываясь на оптимизированных почасовых кривых использования, нагрузку трафика можно сбалансировать по 24-часовому спектру — например, основные серверы западного побережья можно разгрузить, перемещая трафик на восточное побережье, когда использование на восточном побережье падает.

Регион против языковой матрицы

Для мобильных приложений лучший способ определить страну пользователя и место выпуска его телефона — полагаться на региональную настройку, выбранную пользователем или установленную по умолчанию. Это также можно комбинировать с настройкой языка, чтобы создать сложную матрицу поддерживаемых регионов и стран, а не языков. Например, это позволит гражданину Китая, проживающему в США и купившему телефон в США, отображать телефон и приложение на китайском языке. Еще одно решение, которое необходимо принять группе разработчиков, — это настройки по умолчанию, когда язык или страна не поддерживаются. Например, если программное обеспечение не поддерживает финский язык в Финляндии, по умолчанию должен использоваться английский язык. Это позволяет продукту предлагать предпочтения и настройки.

Усложнение матрицы признаков

Стандартная матрица функций будет поддерживать ряд стандартных сценариев. Например, если пользователь уже вошел в систему, он должен иметь возможность перейти непосредственно на домашнюю страницу, а не на страницу входа. Однако создание интернациональных продуктов означает увеличение сложности за пределы функций, которые взаимодействуют друг с другом. Хорошим примером является функция Facebook Dating, которая впервые была протестирована в Колумбии, но какое-то время была недоступна для пользователей из США. В этом случае, если программа определяет страну пользователя как Колумбию, она должна показать состояние входа пользователя и функцию знакомств Facebook. Однако, если пользователь находится в США, должно быть видно состояние входа в систему, но не функция знакомств.

Точно так же в примере с Apple Maps функция поиска не должна отображать то, что кажется первым логическим результатом, а должна учитывать местоположение пользователя. В алфавитном порядке «Лондон, Канада» предшествует «Лондон, Великобритания», но если пользователь находится в Великобритании и вводит «Лондон» в качестве ключевого слова, местоположение в Канаде должно отображаться вторым, а не первым вариантом выбора.

Следовательно, матрица результатов поиска должна быть взвешена по таким критериям, как регион пользователя, определяемый из настроек телефона, IP-адрес компьютера или текущее местоположение пользователя, распознаваемое приложением. Матрица функций также должна поддерживать точное автоматизированное принятие решений на основе контекста, такого как базовая страна пользователя, текущее местоположение и языковые предпочтения.

Культурные различия в взаимодействии функций

Культурные аспекты также влияют на взаимодействие функций. Например, пользователь из США может ввести символ «&», чтобы указать на перекресток при поиске адреса, в то время как этот символ обычно не используется в других странах. Мексиканцы ищут адрес, используя аббревиатуры, например, «Col. del Parque» вместо «Colonia del Parque», поскольку мексиканские адреса обычно длинные. Иконы также являются уникальным культурным тропом и могут привести к множеству недоразумений. В одном из приложений, над которым я работал, была британская иконка аптеки, и мои французские пользователи спрашивали, почему мы отображаем бутылки с молоком по всей карте. Хотя мы можем принимать «общепринятые» символы как нечто само собой разумеющееся, мы не должны этого делать, поскольку на визуальную коммуникацию влияют культурные и языковые нормы.

Это также может быть применено к A/B-тестированию — методу, который включает в себя итерации определенных компонентов продукта, чтобы определить, какие из них обеспечивают наиболее успешное поведение пользователя. На A/B-тестирование цветов кнопок может влиять культурное восприятие. Несмотря на то, что восприятие зеленого цвета как «вперед» и красного как «стоп» в значительной степени интернационально, все же существует значительная разница в культурном восприятии значений цветов. Например, в разных странах цвет траура может быть как черным, так и белым, что вызовет противоположную реакцию у пользователей, если вы используете неправильный цвет.

Локализация, не только перевод

Приведенные выше примеры иллюстрируют разницу между локализацией и переводом. Локализация учитывает множество культурных компонентов, влияющих на визуальный дизайн и взаимодействие функций, и выходит далеко за рамки простого перевода текстов или звуковых подсказок. Среди прочего, они включают в себя разнообразие валют, систем измерения (метрическая и имперская или шкала Цельсия и Фаренгейта) и форматирования (форматы даты различаются в США и Европе), а также изменение текстовых символов и ориентации. к дизайну (арабский язык читается справа налево, и это сильно влияет на эргономику страницы).

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

Настройка команды контроля качества на успех

Когда продукт достигает стадии тестирования, продуктовая команда должна рассмотреть возможность локального и централизованного тестирования. Хотя ряд сценариев можно протестировать автоматически и централизованно из штаб-квартиры, некоторые основные функции можно было бы протестировать на месте. Вождение по дорогам страны даст вам ценную информацию о версии программного обеспечения местных карт; то же самое относится к тестированию фестивального приложения с локальной сотовой сетью, а не с Wi-Fi. Тестирование в полевых условиях обходится дороже из-за необходимых человеческих ресурсов и соответствующих транспортных расходов. Как правило, разработчики продуктов сталкиваются с компромиссом между рисками качества и безопасности, с одной стороны, и затратами, связанными с углубленным тестированием, с другой.

Подробный план тестирования необходим для обеспечения проведения надлежащего тестирования. Он состоит из множества компонентов, в том числе:

• Основные сценарии использования в каждой стране
• Пиковые нагрузки трафика
• Местные особенности, такие как использование Wi-Fi и сотовой связи.
• Уровень пропускной способности интернета
• Типы используемых устройств

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

Маркетинг на основе местоположения

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

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

Сложный, но удовлетворительный

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