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

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

1. Начну с простого. Если вы думаете, что локализация продукта это перевод интерфейса на новый язык и просто сделав его, то ваш продукт «теперь запущен в США и Европе», вы… глубоко ошибаетесь.

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

3. Поэтому, всё, что вы делали на самом первом этапе (поиск пользовательской боли, касдеев, маркет-фит и т.п.) придётся повторно проводить, но… уже для новой локальной аудитории и рынка.

4. Да-да, придётся снова верифицировать проблемы и их наличие на новом рынке. Ты же не хочешь спустя Х-лет успешного роста в своём регионе столкнуться с классическими стартап-болячками, но в другой стране?

5. Конечно же, ты как продакт скажешь, что можно экстраполировать. ЧЁРТ ПОБЕРИ, НЕ ЭКСТРАПОЛИРУЙ данные от текущей аудитории на новую! Данные это всегда факты и детали, которые должны верифицировать что-либо. Но релевантность данных от русскоговорящей аудитории не равна данным от англоговорящей.

6. Причина простая – разница культур и менталитетов и всего, что из них вытекает. Эта разница играет ОЧЕНЬ большое значение и именно она должна быть во главе всех исследований продакта (а не вопросы “как правильно принимать оплату в баксах”).

7. Простой пример. Для нас было удивлением узнать, что в США термин “погодные боли” (weather pains) не распространён (несмотря на то, что именно он записан в Википедии). Вместо него на Западе используется термин rain pains. Вроде мелочь, но из неё растет всё: от правильных терминов на сайте и конверсии в юзера, до ранжирования в поисковых сетях и потенциала сеошки по таким ключам.

8. Другой пример. Что делают на Западе, когда чувствуют боль? Звонят в страховую и идут ко врачу. Вроде простая и понятная мысль, но поясню для тех, кто пока ещё не жил/не работал в США. За ней скрываются следующее – это значит, что в сознании и механиках юзеров США поиск “народных средств лечения” в интернете/по знакомым стоит самым последним пунктом. Более того, если американский пациент сам назначит себе диагноз и лечение, страховая может легко отказаться от его дальнейшего обслуживания. Подобные вещи нужно определять как можно раньше и учитывать при локализации продукта.

9. Возвращаемся к локализации. Если вы и ваша команда – russian native speaker (как в нашем случае), то даже не пытайтесь самостоятельно заниматься переводами сайта/приложения (мы до сих пор разгребаем последствия кривых переводов профессиональными аутсорс-переводчиками в интерфейсе и статьях).

10. Русский язык — богатый и великий. Постарайтесь облегчить переводчику работу и уменьшите количество сложных обротов и фраз в текстах. Советую ещё раз вычитать и подготовить оригинальные тексты к переводу.

11. Хороший тон – подготовить полноценное интро о вашем проекте для переводчика, рассказав ему о продукте, как им пользуются и т.п. вещи. Человеку будет легче понять тематику и он быстрее въедет в процесс.

12. Если вы – стартап, то вместо самодеятельности и контор с большими прайсами за переводы, гораздо эффективнее найти самого простого US native speaker типа студента/домохозяйки (зависит от отрасли) и попросить помочь с адаптацией новых текстов именно их. Поверьте, такие переводы будут гораздо легче для понимания аудиторией, нежели сложные конструкции, построенные профессиональными переводчиками. Приятный бонус – вы можете обзавестись и вырастить толкового контент-менеджера за вполне приемлемый прайс.

13. С чего начать локализацию? Иди по пользовательской воронке, но с самого конца:

приложение → страницы в сторах → веб-сайт.

Новые пользователи смогут пользоваться приложением при кривом переводе сайта, но им не нужно кривое приложение с правильно переведённым сайтом.

14. Оптимизируйте систему(ы) управления контентом. В данный момент, у нас их аж ТРИ: сайт на тильде, интерфейс приложения и система контента внутри приложения. В данный момент, мы объединили две последних в 1 инструмент, от тильды сможем отказаться только после слияния аппы и сайта (в планах до конца лета).

15. Оптимизируйте процессы работы над переводами. Мы используем отдельную доску в Ношене с обычным канбаном, где 1 переводимая страница/экран = 1 таска, которые двигаются по статусам от «На очереди» до «Оплачено» (оплата по количеству символов).

16. Введи в таске-менеджере глоссарий с терминами. Не устану повторять золотую фразу: «Вначале, определимся с терминами и понятиями«. Тоже самое должно происходить когда вы вводите новую сущность/механику/сотрудников в продукт, донося до команды правильное и единое понимание слов и терминов.

17. Выведи сбор фидбека на первое место. Лучшие помощники в поиске багов и косяков – пользователи. Не стесняйся просить у них помощи и сообщать, если они нашли где-либо неточность. Отблагодарить их всегда можно бесплатными услугами продукта (под шумок, можно даже предложить покасдевиться немного ;).

Источник