Локализация продукта и её подводные камни
Published in 28 Apr 2022
78

Локализация продукта и её подводные камни

Пара мыслей по поводу локализации и развития продукта(ов) на новом рынке на примере приложения Метеоагент. Для справки: продукту чуть больше года, 80% ру-аудитория, MAU <10,000, локализация на рынок США только в разгаре.

  1. Начну с простого. Если вы думаете, что локализация продукта это перевод интерфейса на новый язык и просто сделав его, то ваш продукт "теперь запущен в США и Европе", вы... глубоко ошибаетесь.
  2. Локализация продукта – трансформация продукта (его концепции, стратегии, особенностей развития) и его выход на новый рынок. Это значит, что продукты локализуются по странам, а не языкам (как на концептуальном уровне, так и на детальном).
  3. Поэтому, всё, что вы делали на самом первом этапе (поиск пользовательской боли, касдеев, маркет-фит и т.п.) придётся повторно проводить, но... уже для новой локальной аудитории и рынка.
  4. Да-да, придётся снова верифицировать проблемы и их наличие на новом рынке. Ты же не хочешь спустя Х-лет успешного роста в своём регионе столкнуться с классическими стартап-болячками, но в другой стране?
  5. Конечно же, ты как продакт скажешь, что можно экстраполировать. ЧЁРТ ПОБЕРИ, НЕ ЭКСТРАПОЛИРУЙ данные от текущей аудитории на новую! Данные это всегда факты и детали, которые должны верифицировать что-либо. Но релевантность данных от русскоговорящей аудитории не равна данным от англоговорящей.
  6. Причина простая – разница культур и менталитетов и всего, что из них вытекает. Эта разница играет ОЧЕНЬ большое значение и именно она должна быть во главе всех исследований продакта (а не вопросы “как правильно принимать оплату в баксах”).
  7. Простой пример. Для нас было удивлением узнать, что в США термин “погодные боли” (weather pains) не распространён (несмотря на то, что именно он записан в Википедии). Вместо него на Западе используется термин rain pains. Вроде мелочь, но из неё растет всё: от правильных терминов на сайте и конверсии в юзера, до ранжирования в поисковых сетях и потенциала сеошки по таким ключам. Google Keywords Planner или Trends помогут разобраться какое слово используются чаще.
  8. Другой пример. Что делают на Западе, когда чувствуют боль? Звонят в страховую и идут ко врачу. Вроде простая и понятная мысль, но поясню для тех, кто пока ещё не жил/не работал в США. За ней скрываются следующее – это значит, что в сознании и механиках юзеров США поиск “народных средств лечения” в интернете/по знакомым стоит самым последним пунктом. Более того, если американский пациент сам назначит себе диагноз и лечение, страховая может легко отказаться от его дальнейшего обслуживания. Подобные вещи нужно определять как можно раньше и учитывать при локализации продукта.
  9. Возвращаемся к локализации. Если вы и ваша команда – russian native speaker (как в нашем случае), то даже не пытайтесь самостоятельно заниматься переводами сайта/приложения (мы до сих пор разгребаем последствия кривых переводов профессиональными аутсорс-переводчиками в интерфейсе и статьях).
  10. Русский язык - богатый и великий. Постарайтесь облегчить переводчику работу и уменьшите количество сложных оборотов и фраз в текстах. Советую ещё раз вычитать и подготовить оригинальные тексты к переводу.
  11. Хороший тон – подготовить полноценное интро о вашем проекте для переводчика, рассказав ему о продукте, как им пользуются и т.п. вещи. Человеку будет легче понять тематику и он быстрее въедет в процесс.
  12. Если вы – стартап, то вместо самодеятельности и контор с большими прайсами за переводы, гораздо эффективнее найти самого простого US native speaker типа студента/домохозяйки (зависит от отрасли) и попросить помочь с адаптацией новых текстов именно их. Поверьте, такие переводы будут гораздо легче для понимания аудиторией, нежели сложные конструкции, построенные профессиональными переводчиками. Приятный бонус – вы можете обзавестись и вырастить толкового контент-менеджера за вполне приемлемый прайс.
  13. С чего начать локализацию? Иди по пользовательской воронке, но с самого конца: приложение → страницы в сторах → веб-сайт. Новые пользователи смогут пользоваться приложением при кривом переводе сайта, но им не нужно кривое приложение с правильно переведённым сайтом.
  14. Оптимизируйте систему(ы) управления контентом. В данный момент, у нас их аж ТРИ: сайт на тильде, интерфейс приложения и система контента внутри приложения. В данный момент, мы объединили две последних в 1 инструмент, от тильды сможем отказаться только после слияния аппы и сайта (в планах до конца лета).
  15. Оптимизируйте процессы работы над переводами. Мы используем отдельную доску в Ношене с обычным канбаном, где 1 переводимая страница/экран = 1 таска, которые двигаются по статусам от "На очереди" до "Оплачено" (оплата по количеству символов).
  16. Упрощение – единственное, чего хотят пользователи во всем мире. В таких UI-блоках как кнопки, попапы и т.п. визуальных элементах, которые глаза и мозг юзера должен считывать быстро, не стесняйся использовать сокращения (типа Send вместо Send Message). Само собой, главным со-советчиком должен выступать дизайнер. Я это к тому, что дизайнер тоже должен участвовать в локализации и проверке на деве того, чего там напереводил наш локализатор.
  17. Введи в таске-менеджере глоссарий с терминами. Не устану повторять золотую фразу: "Вначале, определимся с терминами и понятиями". Тоже самое должно происходить когда вы вводите новую сущность/механику/сотрудников в продукт, донося до команды правильное и единое понимание слов и терминов.
  18. Выведи сбор фидбека на первое место. Лучшие помощники в поиске багов и косяков – пользователи. Не стесняйся просить у них помощи и сообщать, если они нашли где-либо неточность. Отблагодарить их всегда можно бесплатными услугами продукта (под шумок, можно даже предложить покасдевиться немного ;).


Зарегистрируйтесь для комментирования
Авторизация
Контакты Владимир Миролюбов
23 Feb 2022 • 104 views
01 Feb 2022 • 188 views
02 Jul 2021 • 372 views
Читать больше
Владимир Миролюбов