Прототипирование с помощью сервиса SAP Build

Для разработки интерфейса сервиса в данном проекте используется инструмент SAP Build.

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

3.2.1. Подготовка
Перед началом работы я прошла регистрацию в системе и изучила обучающие материалы. Далее необходимо заполнить информацию профиля, создать и описать проект (Рисунок 5). Для данного проекта я выбирала создание проекта с нуля. Инструмент также предлагает возможность создания проекта с использованием готовых шаблонов.

Рисунок 5 Workspace Sap Build

3.2.2. Загрузка файлов

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

Рисунок 6 Загрузка файлов прототипов

Согласование прототипа интерфейса

Оцифрованный «аналоговый» прототип интерфейса загружен в систему и его можно отправлять рабочей группе (в т.ч. будущим пользователями) на согласование.

Построение цифровых прототипов

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

Для начала отрисуем первые два экрана используя встроенный редактор интерфейсов (Рисунок 7, Рисунок 8). Он позволяет модифицировать сгенерированные шаблоны приложений и разрабатывать свои.

Рисунок 7 Цифровой макет Экран Авторизации

 

Рисунок 8 Цифровой макет Главного экрана Личного кабинета

 

 

Анализ результатов

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

 

Архитектура системы

Интеграционные потоки

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

1. С внутренними системами организации:

· ERP системой для первоначальной загрузки и дальнейшей синхронизации списка магазинов, данных по ассортименту и наличию в разрезе торговых точек.

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

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

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

2. С внешними системами:

· Системы веб-аналитики: передача данных по размеченным событиям для анализа и построения различных отчетов.

· Системы рассылок сообщений электронной почты, смс и пуш-уведомлений.

· Социальными сетями для публикации единого контента.

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

Система технической архитектуры верхнего уровня представлена на Рисунок 9.

 

 

Рисунок 9 Схема технической архитектуры верхнего уровня

 

Content Management System

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

· Процесс разработки: команды frontend'a и backend'a могут работать независимо друг от друга.

· Возможно постепенно добавлять функциональность CMS там, где это необходимо.

· Omnichannel: возможность работы над контентом для разных платформ в одном интерфейсе.

· Гибкость: свобода разработчиков в выборе технологий.

· Безопасность: обеспечивает полный контроль над тем, как и где отображается ваш контент.