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

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

Источник: https://exp.fm/posts/308

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

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


Report Page