К чему готовиться при проектировании eCommerce-приложения

Поддерживать работу крупного интернет-магазина — непростая техническая задача. Нужно интегрировать несколько разных IT-систем и поддерживать их стабильную работу. Среди них — системы оплаты, учёта товарных остатков, управления витриной и т. д. Есть два способа это осуществить: воспользоваться готовой CMS для интернет-магазина или написать свою. Половина крупных российских интернет-магазинов использует готовые CMS. Вторая половина пишет систему сама.

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

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

В 2016 году компания Лайв Тайпинг разработала iOS и Android-приложение для магазина косметики и парфюмерии ИЛЬ ДЕ БОТЭ, а позже мы запустили версию для планшетов. Опираясь на этот опыт, мы хотим рассказать, какие основные вопросы возникнут у команды к заказчику в ходе исследования и проектирования.

Что нужно сделать, чтобы начать разработку

Сделать проектирование. В общем виде этот процесс можно разбить на четыре этапа:

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

• аналитики и дизайнеры рисуют, что хочется получить от приложения — вместе с заказчиком создают прототип интерфейса;

• разработчики выясняют, как всё это будет работать — проектируют архитектуру API и серверной части;

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

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

Исследование и описание систем проекта

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

Что такое API и зачем оно нужно?

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

Когда речь идёт о мобильных приложениях, API нужно, чтобы связывать сервер интернет-магазина и все IT-системы, которые в нём есть, с клиентом, то есть мобильным приложением. API помогает договориться о том, как им обмениваться данными.

Кто договаривается? Разработчики мобильного приложения и Back-End разработчики со стороны заказчика. Разработчики мобильного приложения не могут просто так передавать данные от сервера к приложению и от приложения к серверу. Чтобы начать это делать, нужно договориться о формате передачи данных.

Когда договорённость, то есть API, готова, приложение и сервер могут взаимодействовать. Сервер собирает данные из IT-систем, превращает в читаемый формат и отправляет мобильному приложению. И наоборот.

Так что же нужно интегрировать в API?

Чтобы спроектировать API, нужно узнать, с какими системами оно будет интегрироваться и как эти системы устроены. Рассмотрим каждую из них.

Система учета товарных остатков

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

Логистика товаров

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

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

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

Кроме всего вышеперечисленного магазин может работать с несколькими логистическими компаниями или с агрегатором служб логистики.

Система, отвечающая за бухгалтерию

Например, система «1С: Предприятие», которая готовит бухгалтерские документы.

Система управления акциями и скидками

Её интеграция позволяет приложению при расчёте стоимости учитывать, что на какой-то набор товаров сейчас объявлена скидка. Или знать о системе подарков. Сюда же относится дисконтная система. Она хранит информацию о том, что у пользователя есть скидочная карта, и приложение может обращаться к этой системе и определять, какая именно у человека скидочная карта. Ещё здесь могут быть платформы CRM-маркетинга, которые не только помнят о дисконтной карте, но и собирают кучу другой информации о пользователе: помнят, когда у человека день рождения, когда и какую имейл-рассылку он получил и как отреагировал; помнят, что он любит покупать и т. д.

Системы авторизации пользователей

Здесь возможны разные варианты. Такой, когда авторизуется не пользователь, а приложение — для eCommerce-приложений один из самых интересных. С такими системами разработчики могут, например, присылать push-уведомления на конкретное устройство, даже если пользователь ещё не зарегистрировался в приложении.

Набор систем оплаты

Определяет, каким образом интернет-магазин принимает деньги покупателей. Это может быть WebMoney, Яндекс. Деньги, карты Visa и Mastercard, Apple Pay или Android Pay и т. д. — систем оплаты, с которыми нужно интегрироваться, очень много.

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

Создание прототипа интерфейса

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

Что вам нужно знать про этот этап?

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

Помимо этого у пользователей разных платформ — iOS и Android — есть свои пользовательские привычки. Например, у смартфонов на Android есть кнопка back, а у смартфонов на iOS её нет. И пользователи iOS привыкли нажимать на кнопку «назад» внутри приложения, а пользователям Android это не нужно. Пользователи разных платформ взаимодействуют с приложением по-разному, поэтому гайдлайны для дизайна приложений будут разными в случае каждой платформы. Дизайнеры мобильных приложений знают все эти особенности и учитывают их при создании интерфейсов. Знаний и опыта веб-дизайнера здесь недостаточно.

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

Этот процесс повлияет на прототип интерфейса. Скорее всего, пройдёт череда доработок, прежде чем прототип и архитектура API и сервера не начнут устраивать все стороны процесса. После этого остаётся только проектирование административной панели.

Проектирование административной панели

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

У приложений отличаются и технические возможности. Например, пользователю приложения можно отправить push-уведомление. Это создаёт дополнительный канал коммуникации, которым нужно управлять с помощью административной панели.

Что со всем этим делать?

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

Что еще почитать по теме?

• Сколько стоит разработка мобильного приложения
• Сколько времени она занимает
• Какие базовые и расширенные функции должны быть в  eCommerce-приложении