Смотрите «Дом Дракона» 22 августа в подписке Плюс Мульти с Амедиатекой на Кинопоиске
«Дом Дракона»
Смотрите в подписке Плюс Мульти с Амедиатекой на Кинопоиске
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
Доступно на Кинопоиске по Подписке Плюс Мульти с Амедиатекой или при наличии Доп. опции "Амедиатека". Условия: clck.ru/FMQND.
18+
Личный опыт
Ferma.digital

UX при локализации в Omio: опыт разработчика

Привет, меня зовут Олег Кузнецов, мне 29 лет, из которых 6 я разработчик. До 24 февраля я работал в иностранной компании, а сейчас я работаю в Ferma Digital, где делаю проект с Omio - крупнейшим европейским агрегатором путешествий. Но обо всем по порядку.

От студента до Fullstack’а

Почти 6 лет назад я закончил универ в своем городе по специальности "Разработка программного обеспечения".

Потом молодым джуном без опыта попал в топовую международную компанию. Там я успешно прошел интервью как С# разработчик под dotnet, и первые три месяца сидел на проектах по демкам, рассчитанным под VR.

Заслужив доверие и набив кое-какие шишки, присоединился к полноценному проекту. Главной задачей было сделать платформу гибкого поиска юристов и дел. С платформой работал почти 6 лет. Начиная от стартапа, когда была только бизнес-идея, заканчивая стадией поддержки. За эти 6 лет получил большой опыт в различных технологиях и стал полноценным fullstack-разработчиком.

Короче, сформировал приличное портфолио. Оно мне, как уже догадываетесь, пригодилось в феврале.

Как я снова начал искать работу, и куда меня это завело

Иностранная компания, в которой я работал, ушла из России. Поэтому я, как и 6 лет назад, был в поисках. Не сразу, но я нашел классную вакансию, на которую захотелось откликнуться. Так я попал на собеседование в Omio.

Первое интервью было техническим. Специалист гонял по вопросам, я решал базовые алгоритмические задачки. Когда я его прошел, меня собеседовал уже lead-разработчик компании. Спрашивал про стек технологий и про то, какие пункты нужно учитывать, выкатывая приложение клиенту. Я ему перечислил мастхэвы в приложении, он остался доволен, и меня взяли в команду.

Omio – это кто?

Omio – это онлайн-агенство для путешественников, которое продает каждый день столько билетов, что можно заполнить больше 300 автобусов и 30 поездов.

Это приложение по поиску билетов и составлению маршрутов. У них очень удобное web-приложение, партнерство с Букингом и качественный клиентский сервис.

Чем там занимаюсь я?

Я занимаюсь A/B тестированием. Разработал и продолжаю курировать фичу с локализацией. Теперь новые достопримечательности показываются пользователю более точно, по регионам.

Как команда Omio поняла, что пора локализоровать приложение? В ряде стран Omio может предложить посетить интересные места (экскурсии, музеи, парки), но это не адаптировано под каждый город — в Париже человек получает несколько страниц предложений, а в провинциальном городе – 0, несмотря на то, что интересные достопримечательности могут быть совсем рядом. Для клиентов сервиса это, конечно, минус.

UX при локализации: зачем он все-таки нужен?

UX или “Пользовательский опыт”, на самом деле, и есть то, что определяет успех или провал приложения. Если пользователю что-то неудобно или непонятно, он его удалит. И тут все ваши вложения, дни написания и тестирования окажутся впустую потраченным временем.

Как правило, плохая локализация приложения выглядит так:

1.При переводе текст не вписывается в верстку (длиннее или короче);

2.Очень много грамматических ошибок и язык из Google Translate версии 2007. Пользователям с филологическим образованием точно не зайдет.

3. Факапы с размером шрифта.

Но есть и более сложные проблемы. Когда, как в Omio, визуально все выглядит окей: шрифты, тексты, верстка в порядке; но очевидный запрос пользователя (посмотреть, куда сходить), игнорируется.

Так в чем проблема: взял и локализировал

На самом деле, все гораздо сложнее.

Как минимум, нужно включить в работу много отделов и команд. С этим, кстати, поможет система управления работой команды (например, Wrike, Azure Devops, Jira).

Получается, всей вот этой толпе специалистов нужно дополнить (или создать, если у вас еще не настроена локализация) продукт, где региональные особенности (в нашем случае – достопримечательности) будут вынесены в отдельные блоки, которые будут подгружаться при выборе того или иного региона/страны.

Что это дает (технически)

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

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

3. Изначальный размер приложения при таком подходе меньше

4. Если найдете баги при тестировании локализации, они будут связаны с локалью, а не с самим приложением.

Что это дает репутационно и финансово

Простыми словами: клиент не пользуется тем, что ему неудобно.

Это легко отследить на языковой локализации продукта: согласно исследованию CSA, 75% опрошенных заявили, что, выбирая между двумя похожими продуктами, они выберут тот, который доступен на их родном языке. А доклад компании Applead показывают, что локализация страницы приложения в Google Play и AppStore повышает конвертацию в установку на 25-30%.

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

0
Комментарии
Читать все 0 комментариев
null