Редизайн программ что это

Что такое редизайн и зачем он нужен?

Редизайн – это английское слово, перевести его можно как «смена внешнего вида».

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

Обычно когда говорят о редизайне, подразумевают не просто смену дизайна.

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

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

Зачем?

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

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

Тест-дизайн. Что это такое? Тест дизайн в тестировании ПО. Test design

Когда может понадобится редизайн сайта?

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

2. Редизайн может понадобится и если сайт новый, но при разработки было что-то упущено, из-за чего сайт не выполняет задачи, которые на него возложены.

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

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

4. Еще одна причина, по которой нужен редизайн, это добавление на сайт новых сервисов.

Сколько стоит редизайн?

Цена редизайна зависит от объема работ. Для начала определяется, что именно владельца сайта не устраивает в дизайне и в сайте, что он хочет изменить.

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

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

Источник: dramtezi.ru

Редизайн: что это такое простыми словами

В данной статье мы посмотрим, что такое редизайн сайта простыми словами. Когда и по каким причинам он проводится. Какие цели преследует редизайн сайта и нужно ли его проволить. Узнаем, что такое редизайн персонажа в рисовании.

Что такое редизайн сайта?

УДИВИТЕЛЬНЫЙ МИР MOTION-ДИЗАЙНА | ФРИЛАНС | ЧТО ТАКОЕ МОУШН ДИЗАЙН?| — Bagaxd

Что такое редизайн сайта? Редизайн сайта заключается в обновлении внешней и внутренней составляющей, это необходимо, если сайт нужно продвигать в настройках объявлений в яндекс директ, а сайт не соответствует современным требованиям и тенденциям. Как правило это полное обновление, а не частичные изменения. Основное отличие от разработки нового сайта в том, что все обновления проводятся на основе сайта который уже существует и функционирует.
При этом используются все данные аналитики, которые были присущи старому сайту, они сохраняются, также как частично сохранится контент и действенность. Смысл редизайна —это не уничтожить все достижения, а сохранить их, создав симбиоз с новыми аспектами. Есть несколько частей, которые необходимо сохранить при проведении работ по редизайну:

• SEO;
• пользователей;
• аналитику.

Оставить результаты SEO продвижения бизнеса в интернете очень важно, чтобы не выпасть из ТОПа поиска.

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

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

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

После этого проводится тщательный анализ сайта, который использовался ранее:

• целевая аудитория;
• страницы сайта с высокой проходимостью;
• цели, которые выполнялись сайтом;
• поведенческие особенности аудитории на сайте.

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

Что такое редизайн персонажа?

Что такое редизайн персонажа? Редизайн рисованного персонажа заключается в том, что внешность персонажа переделывается для того чтобы он был привлекательнее для аудитории.

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

Редизайн персонажа проводится, если персонаж морально устарел, но его востребованность ранее была высока. При смен поклонений могут меняться требования к графическому исполнению персонажей, но когда то это персонаж был любим другим поколением, таким образом, при редизайне персонажа завоевывается не только новая аудитория, но и возвращается старая.

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

Что такое редизайн в рисовании?

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

Прислушавшись, понимаешь, что это использование заимствованных иностранных слов, с типично русским произношением, что делает понимание этих слов практически недоступным для непосвященных.

С проникновением компьютерных технологий рисование стало не только творческим, но и технологичным процессом, ведь можно узнать как сделать GIF-анимацию из видео и применить это в рисовании. Так, например, появился диджитл арт, который называют дидж.

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

Зрительно отличить можно и это все равно остается не искусством, а диджем. Также появилось понятие редизайн в рисовании. Часто этот термин используется при изменении графики, в которой создан персонаж, могут заменяться его стиль или образ, который подстраивают под современные тенденции, которые меняются с завидным постоянством.

Источник: pro-promotion.ru

Редизайн приложения — взгляд изнутри

Mobius bike — это сервис по прокату велосипедов и самокатов, разработанный для Таллина (на данный момент запланировано расширение географии).

Гипотеза первого релиза — «приложение по прокату велосипедов, будет востребовано на рынке Европы». В декабре 2019 была пересмотрена основная гипотеза и теперь она звучала так — «может ли сервис по прокату велосипедов и самокатов получить максимальное распространение за счет удобства для конечного пользователя и франчайзи?» Для того, чтобы ответить на этот вопрос, нужно было реализовать следующее:

• провести работы по оптимизации структуры приложения (как внутренней — backend, так и внешней — дизайн и frontend) для внедрения нового типа транспорта и возможного масштабирования в будущем
• сделать условия аренды регулируемыми в админке

Ключевые экраны приложения Mobius bike до редизайна

Одной из первых моих задач в качестве продуктового дизайнера, была подготовка макетов для внедрения нового вида транспорта — электросамокатов. Закончив с макетами, я решил внести некоторые изменения в дизайн и UX приложения и сделать небольшой концепт редизайна. Показал новые макеты команде. Получил фидбэк: ребята давали советы и делились своим мнением. В итоге набралось некоторое количество ключевых экранов.

Приближался запланированный, двухмесячный рефакторинг кода и мы решили показать новый дизайн заказчику, чтобы оптимизировать код уже под новый интерфейс, если, конечно, заказчик согласится на редизайн. Мы презентовали макеты, объяснили как новый дизайн может упростить взаимодействие с приложением и какие выгоды это принесет бизнесу. И уже в процессе презентации мы поняли, что дизайн «зашёл». Редизайн одобрили и теперь мы выходили на рефакторинг уже с новым интерфейсом и переработанным UX.

Варианты ключевых экранов, которые были созданы в процессе редизайна

Организация работ

Так как у нас не было чётко прописанного технического задания и наш сервис развивался вместе с бизнесом, нам нужно было определиться с тем, как мы будет проводить работы: какие задачи брать в первую очередь, как отслеживать прогресс и оценивать результат. Больше всего под наши задачи подходил метод agile. Длительность каждого спринта мы определили в две недели. Каждый день мы проводили стендапы — обсуждали текущие задачи, делились идеями, решали возникающие проблемы. В конце каждого спринта проводили демо — показывали клиенту результаты работы, проделанной за спринт.

Agile во всей красе

Тестовый самокат в нашем офисе

Навигация

Первое, что мы решили изменить — это навигацию по приложению. Вместо «бургера» мы сделали нижнее таб-меню (bottom navigation). Наверное вы заметили, что многие приложения переходят именно к этому типу навигации. И это понятно, так как таб-меню упрощает доступ к основным разделам приложения даже если человек держит телефон одной рукой. Но это не единственная причина использования данного типа навигации. Приложение разрабатывается на React Native, поэтому нам пришлось учитывать особенности этой платформы:

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

Никита Ренёв — front-end разработчик

До редизайна — меню «бургер». После редизайна — навигация снизу (bottom navigation)

Интерфейс, компоненты, UI-kit

Кроме изменения навигации, мы отказались от контролов масштаба на экране приложения. Оставили изменение масштаба с помощью жестов. Заменили модальные окна, диалоги и часть экранов на swipe-up экраны. Опять же потому, что так удобнее использовать приложение одной рукой — такой экран можно просто «смахнуть» вниз и закрыть его.

Примеры swipe-up экранов в приложении Mobius bike после редизайна

Также мы упростили процесс регистрации в приложении, сделав вход через Google и Facebook. А кроме привязки банковских карт добавили возможность оплаты с помощью Apple Pay и Google Pay.

Экран входа в приложение и оплаты с помощью Apple Pay

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

UI-kit приложения Mobius bike

Рефакторинг и переход на GraphQL

Основными целями редизайна были:

• создать более гибкую и масштабируемую систему компонентов, которая бы легко позволяла добавлять новый функционал, например еще один вид транспорта, без ущерба внешнему виду и общей логике взаимодействия с приложением
• максимально облегчить и упростить интерфейс
• «освежить» внешний вид приложения

Но кроме обновления интерфейса приложения, видимой стороны редизайна, очень важной частью был переход с RESTful API на GraphQL.

Если по простому, GraphQL — это синтаксис, который описывает способ получения клиентом (телефоном/приложением) данных с сервера, посредством специальных запросов. В зависимости от запроса сервер отдает те или иные данные.

Артём Бухтояров — DevOps/Backend-разработчик

GraphQL имеет три основные характеристики:

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

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

Кроме того, в процессе рефакторинга мы выделили следующие достоинства применения GraphQL:

• удобная документация для разработчика
• удачное решение для WebSocket, как для backend, так и для frontend
• с GraphQL разработчику проще ориентироваться в структуре кода
• более гибкая разработка, по сравнению с RESTful API, позволяет быстрее и проще добавить что-то новое (в нашем случае — это новый вид транспорта)

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

Изначально, когда у нас был только один вид транспорта, сервер для подключения велосипедов работал вместе с основным бэкендом. Затем, мы вынесли сервер для велосипедных замков как самостоятельный сервис, который можно разворачивать на отдельных серверах — это позволило снизить нагрузку на основной сервер и дало дополнительные возможности для масштабирования. Для передачи сообщений между сервисами мы используем RabbitMQ. И было очень удобно, что у него есть плагин для mqtt — протокол на котором работают наши самокаты, что позволило без труда добавить новый вид транспорта.

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

Франшиза и администрирование

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

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

Также сделали возможность модерировать изменения администратором сети. Расширили структуру админки под добавление новых типов транспорта.

Проблемы

Конечно не обошлось и без трудностей. Мы отказались от визуализации маршрута в истории поездок, так как. gps-модуль в замке велосипеда, не всегда корректно передает координаты. И вместо красивой линии маршрута, как на дрибловском шоте, мы получали вот это:

Ожидание VS реальность

Была проблема в технической реализации Google карт под React Native. Маркеру на карте нужно постоянно перерисовываться, для того, чтобы изменить своё положение на карте. Перерисовка векторной графики в большом количестве не оптимизирована и поэтому, при определённых настройках, всё очень сильно тормозило. И мы решили заменить векторные маркеры на карте на растровые в формате png. Это дало значительный прирост к скорости работы приложения.

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

В итоге остановились на следующем варианте тарификации: время поездки разбивается на неравные отрезки и каждый отрезок времени тарифицируется отдельно. Например, первые 15 минут поездки стоят €2, если катаешься больше 15 минут, но меньше получаса, то стоимость поездки €3.5, от 30 минут до часа — €5 и т.д. И чтобы пользователю было проще ориентироваться в тарифах, мы решили визуализировать расчет стоимости и сделали его в виде прогресс бара. Теперь пользователь может видеть как изменяется стоимость поездки в реальном времени.

Визуализация начисления стоимости в виде прогресс бара

Экраны с тарифами и абонементами

Некоторые пользователи нашли вариант как не платить за поездку: добавляли банковскую карту, потом удаляли её и катались бесплатно. Когда мы это обнаружили, то стали блокировать €1 для проверки платёжеспособности и убрали возможность удалять карту во время поездки или если есть неоплаченный долг.

Также иногда были проблемы с завершением поездки. Чтобы завершить поездку на велосипеде нужно закрыть замок, который передает информацию на сервер. Но замок не всегда передавал данные вовремя. И в итоге у людей мог накапливаться долг по нескольку сотен евро за, якобы, незавершённые поездки. Мы решили, что будем проверять большие суммы вручную и убрали для них автосписание.

Жалоб почти не было, так как в Европе мало у кого подключено смс-оповещение. В России было бы иначе.

Выводы

Frontend

• следить за количеством перерендеров (перерисовок). Компонент должен перерисовываться только в том случае, если поступающие в него новые данные действительно должны изменить состояние интерфейса
• использовать нативную анимацию Animated из стандартного пакета React Native с использованием ключа useNativeDrive в конфиге анимации или пакет Reanimated
• проводить ревью кода JS пакетов или компонентов добавляемых в проект. Не все доступные пакеты могут оказаться оптимизированными, или правильно использующими особенности React Native. Также в разработке на React Native стоит учитывать отличия платформ. Один и тот-же код на iOS и Android может работать совершенно по разному

Слабая сторона React Native — это его не полная нативность. Необходимо постоянно следить за тем, чтобы не перегружать JS-thread. Болезненность обновлений и установки нативных пакетов до 0.60 версии, пока не ввели autolinker.

Backend

Переход на GraphQL в большинстве случаев упростил разработку API. Она стала понятнее, как для разработчика, так и для клиента.

• есть возможность автоматически документировать API и это очень удобно
• позволяет более гибко работать с API. Клиент выбирает только те данные которые ему нужны в данный момент
• поддержка web sockets «из коробки», что было очень важно так как у нас часто обновляются данные в реальном времени
• мы можем легко писать скалярные типы если это нужно и в дальнейшем переиспользовать их

• сложнее делать фичи по типу пагинации. Приходится применять дополнительные технологии
• «из коробки» нет namespace. Нужно самому позаботиться о разделении API. В то же время есть поддержка deprecated-полей, что позволяет в дальнейшем упростить жизнь разработчику
• необходимо следить за уровнями вложенности для запросов. Можно написать запрос с большой вложенностью и потом долго ждать ответ

Интерфейс

Работая над редизайном нужно помнить, что не стоит делать дизайн ради дизайна. В нашем случае новый интерфейс позволил упростить взаимодействие пользователя с приложением, в том числе, если человек держит телефон одной рукой. Мы учли особенности React Native и, для того, чтобы сократить вложенности, перешли от «бургера» к bottom navigation. Также необходимо заложить возможность масштабирования структуры приложения. Здесь может помочь создание библиотеки компонентов и применение атомарного дизайна.

В планах у нас внедрение геймификации (получение приятных бонусов за пройденные километры), тёмная тема, подключение к контактам телефона и уведомление о друзьях, катающихся по близости и внедрение новых видов транспорта. Но главное, редизайн должен быть оправдан: приносить пользу бизнесу и упрощать работу с приложением для пользователя.

• Разработка мобильных приложений
• Проектирование и рефакторинг
• Интерфейсы
• Дизайн мобильных приложений
• Agile

Источник: habr.com

Редизайн приложения — взгляд изнутри

В статье мы делимся нашим опытом редизайна мобильного приложения для сервиса по прокату велосипедов и электросамокатов. Почему отказались от «бургера» в пользу bottom navigation, особенности разработки на React Native и почему мы перешли на Graph QL.

2056 просмотров

Mobius bike — это сервис по прокату велосипедов и самокатов, разработанный для Таллина (на данный момент запланировано расширение географии).

Гипотеза первого релиза — “приложение по прокату велосипедов, будет востребовано на рынке Европы”. В декабре 2019 была пересмотрена основная гипотеза и теперь она звучала так — “может ли сервис по прокату велосипедов и самокатов получить максимальное распространение за счет удобства для конечного пользователя и франчайзи?” Для того, чтобы ответить на этот вопрос, нужно было реализовать следующее:

провести работы по оптимизации структуры приложения (как внутренней — backend, так и внешней — дизайн и frontend) для внедрения нового типа транспорта и возможного масштабирования в будущем

сделать условия аренды регулируемыми в админке.

Любовь Никифорук, Менеджер проекта
Ключевые экраны приложения Mobius bike до редизайна​

Одной из первых моих задач в качестве продуктового дизайнера, была подготовка макетов для внедрения нового вида транспорта — электросамокатов. Закончив с макетами, я решил внести некоторые изменения в дизайн и UX приложения и сделать небольшой концепт редизайна. Показал новые макеты команде. Получил фидбэк: ребята давали советы и делились своим мнением. В итоге набралось некоторое количество ключевых экранов.

Приближался запланированный, двухмесячный рефакторинг кода и мы решили показать новый дизайн заказчику, чтобы оптимизировать код уже под новый интерфейс, если, конечно, заказчик согласится на редизайн. Мы презентовали макеты, объяснили как новый дизайн может упростить взаимодействие с приложением и какие выгоды это принесет бизнесу. И уже в процессе презентации мы поняли, что дизайн «зашёл». Редизайн одобрили и теперь мы выходили на рефакторинг уже с новым интерфейсом и переработанным UX.

Варианты ключевых экранов, которые были созданы в процессе редизайна​
Организация работ

Так как у нас не было чётко прописанного технического задания и наш сервис развивался вместе с бизнесом, нам нужно было определиться с тем, как мы будет проводить работы: какие задачи брать в первую очередь, как отслеживать прогресс и оценивать результат. Больше всего под наши задачи подходил метод agile. Длительность каждого спринта мы определили в две недели. Каждый день мы проводили стендапы — обсуждали текущие задачи, делились идеями, решали возникающие проблемы. В конце каждого спринта проводили демо — показывали клиенту результаты работы, проделанной за спринт.

Agile во всей красе​
​Тестовый самокат в нашем офисе

Первое, что мы решили изменить — это навигацию по приложению. Вместо «бургера» мы сделали нижнее таб-меню (bottom navigation). Наверное вы заметили, что многие приложения переходят именно к этому типу навигации. И это понятно, так как таб-меню упрощает доступ к основным разделам приложения даже если человек держит телефон одной рукой. Но это не единственная причина использования данного типа навигации. Приложение разрабатывается на React Native, поэтому нам пришлось учитывать особенности этой платформы:

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

Никита Ренёв, Front-end разработчик
До редизайна — меню «бургер». После редизайна — навигация снизу (bottom navigation)​
Интерфейс, компоненты, UI-kit

Кроме изменения навигации, мы отказались от контролов масштаба на экране приложения. Оставили изменение масштаба с помощью жестов. Заменили модальные окна, диалоги и часть экранов на swipe-up экраны. Опять же потому, что так удобнее использовать приложение одной рукой — такой экран можно просто «смахнуть» вниз и закрыть его.

​Примеры swipe-up экранов в приложении Mobius bike после редизайна

Также мы упростили процесс регистрации в приложении, сделав вход через Google и Facebook. А кроме привязки банковских карт добавили возможность оплаты с помощью Apple Pay и Google Pay.

Экран входа в приложение и оплаты с помощью Apple Pay​

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

UI-kit приложения Mobius bike ​

Рефакторинг и переход на GraphQL

Основными целями редизайна были:

• создать более гибкую и масштабируемую систему компонентов, которая бы легко позволяла добавлять новый функционал, например еще один вид транспорта, без ущерба внешнему виду и общей логике взаимодействия с приложением
• максимально облегчить и упростить интерфейс
• «освежить» внешний вид приложения

Но кроме обновления интерфейса приложения, видимой стороны редизайна, очень важной частью был переход с RESTful API на GraphQL.

Если по простому, GraphQL — это синтаксис, который описывает способ получения клиентом (телефоном/приложением) данных с сервера, посредством специальных запросов. В зависимости от запроса сервер отдает те или иные данные.

Артём Бухтояров,

DevOps/Backend-разработчик

GraphQL имеет три основные характеристики:

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

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

Кроме того, в процессе рефакторинга мы выделили следующие достоинства применения GraphQL:

• удобная документация для разработчика
• удачное решение для WebSocket, как для backend, так и для frontend
• с GraphQL разработчику проще ориентироваться в структуре кода
• более гибкая разработка, по сравнению с RESTful API, позволяет быстрее и проще добавить что-то новое (в нашем случае — это новый вид транспорта)

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

Изначально, когда у нас был только один вид транспорта, сервер для подключения велосипедов работал вместе с основным бэкендом. Затем, мы вынесли сервер для велосипедных замков как самостоятельный сервис, который можно разворачивать на отдельных серверах — это позволило снизить нагрузку на основной сервер и дало дополнительные возможности для масштабирования. Для передачи сообщений между сервисами мы используем RabbitMQ. И было очень удобно, что у него есть плагин для mqtt — протокол на котором работают наши самокаты, что позволило без труда добавить новый вид транспорта.

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

Франшиза и администрирование

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

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

Также сделали возможность модерировать изменения администратором сети. Расширили структуру админки под добавление новых типов транспорта.

Конечно не обошлось и без трудностей. Мы отказались от визуализации маршрута в истории поездок, так как. gps-модуль в замке велосипеда, не всегда корректно передает координаты. И вместо красивой линии маршрута, как на дрибловском шоте, мы получали вот это:

Ожидание VS реальность​

Была проблема в технической реализации Google карт под React Native. Маркеру на карте нужно постоянно перерисовываться, для того, чтобы изменить своё положение на карте. Перерисовка векторной графики в большом количестве не оптимизирована и поэтому, при определённых настройках, всё очень сильно тормозило. И мы решили заменить векторные маркеры на карте на растровые в формате png. Это дало значительный прирост к скорости работы приложения.

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

В итоге остановились на следующем варианте тарификации: время поездки разбивается на неравные отрезки и каждый отрезок времени тарифицируется отдельно. Например, первые 15 минут поездки стоят €2, если катаешься больше 15 минут, но меньше получаса, то стоимость поездки €3.5, от 30 минут до часа — €5 и т.д. И чтобы пользователю было проще ориентироваться в тарифах, мы решили визуализировать расчет стоимости и сделали его в виде прогресс бара. Теперь пользователь может видеть как изменяется стоимость поездки в реальном времени.

Источник: vc.ru

Как сделать большой редизайн сайта и приложения? Рассказывает Head of product design Parimatch Tech

Любую статью можно сохранить в закладки на сайте, чтобы прочесть ее позже.

Партнерский материал

Партнерский материал Материал на правах рекламы

Режим чтения включен

Режим чтения увеличивает текст, убирает всё лишнее со страницы и даёт возможность сосредоточиться на материале. Здесь вы можете отключить его в любой момент.

Режим чтения

Режим чтения увеличивает текст, убирает всё лишнее со страницы и даёт возможность сосредоточиться на материале. Здесь вы можете отключить его в любой момент.

Редизайн — это всегда риски. Парадокс, но запуск улучшенной версии всегда сопровождается падением метрик, потому что пользователь чаще всего не хочет ничего менять. Правильного варианта в таком деле нет, но есть опыт компаний, на котором можно поучиться.

В преддверии онлайн-конференции о цифровых продуктах CASES, которая состоится 17 июня, Алексей Стикс, Head of product design в Parimatch Tech, рассказал Vector о том, из каких этапов состоит редизайн и как провести его грамотно.

Как развиваются интерфейсы продуктов

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

Но в этом процессе скрыта опасность превратить интерфейс в большой базар, где каждый элемент перетягивает на себя внимание. Не всегда можно измерить эффективность решений. Потому в интерфейсе могут накапливаться функции, которые не работают вообще или доступны только отдельным сегментам пользователей.

В какой-то момент разрозненных элементов становится слишком много. Тогда косметические изменения уже не спасут. В таком случае нужно полностью пересобирать продукт, чтобы он хорошо выглядел и работал. На это стоит обратить внимание в первую очередь старожилам рынка, которым более 5 лет.

С чего начать редизайн

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

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

С точки зрения визуального дизайна всегда есть два варианта:

• быть похожими на других;
• отличаться от всех.

Оба варианта неплохие. Но важно четко понимать:

• что делает продукты похожими;
• что является паттерном для индустрии и для клиента;
• что можно «сломать», чтобы отличаться;
• как не испортить общий UX.

Когда вы определитесь с вышеперечисленным, можно начинать собирать реф-листы.

На что нужно ориентироваться

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

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

Поэтому важно поддерживать базовый уровень продуктовой гигиены — следить за совместимостью решений и закладывать мощности на поддержку визуального дизайна.

Как измерить эффективность редизайна

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

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

Его можно попробовать измерить фокус-группами. Но часто в команде есть человек, который выполняет экспертно-визионерскую функцию. Он в таком случае выступает валидатором, проверяет — попали в эмоцию или нет.

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

Запланируйте миграцию аудитории на новый интерфейс по частям — сначала одну долю, потом другую. Переведя часть аудитории на новый дизайн, вы сможете понять, что ухудшилось, и исправить эти вещи, прежде чем перевести следующую группу людей.

Таким образом переход будет плавным для аудитории.

Как это было в Parimatch

При миграции сайта Parimatch на новую платформу основной задачей был все-таки переезд, а не редизайн. Но мы решили, что раз уже пишем новый фронт, то можем попробовать улучшить продукт для нашей pro-аудитории.

Мы поделили аудитории на разные части: по опыту, прибыльности, платформе, на которой играют. Далее распланировали, кого и когда мы будем переводить на новую платформу, и замерили активность этой аудитории после переезда.

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

Благодаря этому сейчас мы превысили все показатели предыдущей версии: повысили количество конверсий в ключевое действие, скорость их выполнений. А новая платформа увеличила скорость загрузки и выдерживание пиковых нагрузок по одновременному количеству ставок в минуту.

Детально о том, как провести успешный редизайн на примере продукта Parimatch, узнаете уже 17 июня на онлайн-конференции о цифровых продуктах CASES.

Нашли ошибку? Выделите ее и нажмите Ctrl+Enter

Источник: vctr.media