Бизнес требования к мобильному приложению

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

64 002 просмотров
О чем рассказываем

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

Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.

В предыдущих материалах мы рассказывали:

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

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

Этапы создания мобильного приложения

Мы в студии обычно строим работу так:

аналитика;
техническое задание;
проектирование и дизайн;
разработка;
тестирование и стабилизация;
публикация в сторах;
поддержка и развитие.

Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.

Рустам Мухамедьянов, руководитель студии Winfox
Этап 1. Аналитика

Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.

Что в результате: референсы по функциональности и дизайну.

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

Валерий Сорокин, менеджер проектов студии Winfox
Этап 2. Техническое задание

Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.

Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.

Что в результате:

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

Что такое пользовательские истории

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

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

Рустам Мухамедьянов, руководитель студии Winfox
Что такое карта путешествий пользователя

Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.

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

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

Александр Хрущев
, технический директор студии Winfox
Чек-лист: что должно быть в ТЗ

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

1. Общие сведения:

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

2. Функциональные требования к приложению:

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

3. Нефункциональные требования к приложению:

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

4. Реализация функциональности приложения:

экран загрузки;
регистрация и авторизация;
основной экран;
меню;
поиск;
…
уведомления.

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

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

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

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

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

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

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

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

V Международная студенческая научная конференция Студенческий научный форум — 2013

РАЗРАБОТКА ТРЕБОВАНИЙ К МОБИЛЬНОМУ ПРИЛОЖЕНИЮ ПО УПРАВЛЕНИЮ ЛИЧНЫМИ ФИНАНСАМИ

Есюнин Н.О. 1 , Пантилимонов М.В. 1

1 Национальный исследовательский университет «Высшая школа экономики» (Пермский филиал), факультет бизнес-информатики

Работа в формате PDF

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF

На сегодняшний день рынок мобильных приложений является быстро развивающейся сферой для вклада интеллектуальных, физических и финансовых ресурсов. Однако не все приложения, доступные в официальных интернет-магазинах, таких как Google Play, AppStore, Marketplace, удобны для пользования и соответствуют требованиям, которые будут описаны дальше. Именно по этой причине целью данной статьи – определить какие же требования должны предъявляться к приложению как с точки зрения дизайна, так и с точки зрения работы приложения в целом.

Для выбора приложения, к которому и будут предъявлены требования не нужно «далеко уходить» от реальности. Достаточно посмотреть на современный мир. У каждого человека огромное количество дел, как на работе, так и в семейном кругу. Однако к этим делам прибавляется один из главных аспектов современности — финансовый аспект. Зачастую тратится огромное количество сил и времени на планирование и надлежащий контроль личных или семейных финансов. Возникает логический вопросом, «Что будет, если отдать часть обязанностей по контролю финансов некому «роботу», мобильному приложению?»

И, несмотря на то, что подобных приложений на рынке достаточно, именно мобильных приложений по контролю и отслеживанию финансовых потоков индивида, как оказалось, не так много(удалось найти Home Budget, Checkbox – Personal manager, Bills и т.д.). Именно поэтому разработка приложений для данной сферы достаточна перспективна и само приложение будет довольно востребовано.

В первую очередь необходимо определить целевую аудиторию приложения. Так как прежде всего приложение будет удовлетворять нужды «загруженных» людей, основным контингентом пользователей будут молодые люди 20-35 лет, которые уже не могут представить жизнь без мобильных технологий. Однако не стоит забывать и о людях старше 35. Сегодняшние тенденции показывают, что 80% населения активно используют мобильные устройства (смартфоны, планшетные ПК) и 5/6 из этого количества – люди 20-35 лет, однако 1/6 людей старше, следовательно, они тоже являются потенциальными пользователями приложения.

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

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

Жизненный цикл приложения

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

Первая стадия – разработка идеи, определение того, что приложение будет делать и для кого.

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

Таким образом, согласно пункту 2.5 ГОСТ 34.602-89 «Характеристики объекта автоматизации», мы установили объект автоматизации нашим приложением – управление личными финансами.

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

Выработанные требования должны быть оформлены в техническом задании. Оно должно быть написано с учетом всех пунктов ГОСТ 34.602-89 , ГОСТ 24.601, и так же на понятном языке для заказчика с целью того, чтобы расставить все детали будущего приложения «по полочкам», так как после проделанной работы может оказаться, что приложением попросту невозможно пользоваться и оно не соответствует требованиям заказчика; и, пожалуй, главным аспектов для понятного усваивания информации в ТЗ является то, что оно должно быть оформлено в соответствии с ГОСТ 2.301.Также некорректно определенные требования к разработке приложения могут стать огромной проблемой и уничтожить весь текущий прогресс, тем самым заставив вернуться на начальную стадию, что отсрочит готовность приложения на неопределенный срок. На данной стадии необходимо понять следующее: как снизить объем потребляемых системных ресурсов, как уменьшить риск непредвиденных аварийных ситуаций и как нормализировать работу приложения.

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

Рассмотрим идею и возможности применения приложения.

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

Рассмотрим процесс распоряжения и регулирования денежных средств рядового человека(рис 1).

Каждый месяц человек получает деньги(зарплата/выручка и тп). Для регулирования потока денег, человек должен запоминать, подсчитать их количество. На протяжении месяца человек совершает покупки и оплату за услуги. После их совершения человек записывает сколько денег он потратил на это в, назовем это так, «тетрадь затрат».

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

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

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

Из этого следует вывод, что используя приложение человек:

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

Следующий пункт, который необходимо рассмотреть – требования к приложению. Небезызвестный факт, что следует ставить перед собой «высокие цели», почти недостижимо-высокие, а после пытаться дотянуться до них. Так и в разработке приложения и требований к нему нужно подходить со стороны оптимизма, ставить задачи куда более высокие, чем можно себе позволить и бросать все силы на их исполнение.

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

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

Согласно ГОСТ 34.602-89 в требованиях к приложению (АС) должны быть предъявлены требования к входным данным приложения, требования к системе, запрашиваемой приложением.

Рис. Контролирование финансов

Рис. Контролирование финансов с приложением

Данное приложение будет разрабатываться в соответствие со следующими требованиями:

Что будет использоваться в качестве входных данных – это то, что необходимо ввести, чтобы приложение работало:

потребуется ввод бюджета, которым располагает пользователь;
краткое описание потребляемых товаров с указанием их стоимости. Следует отметить, что пользователь должен иметь возможность единожды записав свои регулярные расходы, выбирать их из предлагаемого списка. Рис. 3

Рис. Контролирование финансов

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

Пользователь должен иметь возможность корректировать бюджет, как в положительную ,так и в отрицательную сторону. Рис. 4

Рис. корректировка бюджета

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

Временные данные буду заполняться автоматически в историю трат(согласно текущей дате и времени на устройстве). Рис. 5

Рис. История трат

Пользователь должен иметь возможность просматривать историю покупок со всей необходимой информацией.

Требуемые ресурсы ПО аппаратного устройства.

Согласно пункту 2.6.1 ГОСТ 34.602-89 «Требования к системе в целом» , 2.6.2 «Требования к функциям(задачам)», 2.6.3 «Требования к видам обеспечения» к разрабатываемому приложению должны предъявляться следующие требования:

Требования к системе в целом:

Приложение должно занимать не более 1 мб оперативной памяти устройства;
Приложено должно свободно функционировать на устройствах с минимальной мощностью в 400 МГЦ.

Требования к функциям(задачам):

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

Требования к видам обеспечения:

Минимальная версия фреймворк, на которой приложение должно свободно функционировать – API 2.2, однако и на API 4.0 приложение должно работать корректно.

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

С учетом этих требований предполагается реализовать приложение с использованием Eclipse SDK Android, так как данный инструментарий обеспечивает возможность кроссплатформенной разработки.

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

Бизнес-требования к мобильному приложению Claires. Версия 3 nael

1. Бизнес-требования к мобильному приложению CLAIRE’S

2.

Целевая аудитория и возрастная категория
ЦА: девушки от 12 до 18+ лет
Покупательница Claire’s – модная и современная, любит международные
бренды, использует ювелирные украшения и бижутерию для собственного
самовыражения, наслаждается процессом покупки в наших магазинах и
открывает новые стили для себя. Ее жизненная позиция – «COOL GIRL».

3. Стратегия и бизнес-цели

Бизнес-цели
• Привлечение новых клиентов
• Стимулирование продаж
• Развитие лояльности
Стратегия стимулирования пользования приложением
• Приложение распространяется среди постоянных клиентов c элементами геймификации (получение баллов за
определенные действия – шеринг в соцсетях, отзывы, заполнение профиля, «Приведи друга», первое
бронирование заказа и т.д.)
• Это каталог, путешествие по которому станет познавательным приключением
• Приложение является альтернативой Карты – не надо носить с собой карту, есть под рукой
• Обмен баллов на подарки (на сувениры, продукцию CLAIRE’S)

4. User story

Бизнес-требования
Карта CLAIRE’S – карта в приложении. Используются элементы геймификации – «карта достижений»,
приложение может стимулировать пользователя к заказу, если ему остается немного баллов до нового
достижения.
Клуб CLAIRE’S – получение баллов за каждые действия и обмен на подарки.
Список магазинов – магазины списком и на карте, информация о каждом магазине, товарах, акциях
Социальное взаимодействие – можно поделиться приложением с другом и получить дополнительный бонус
к сумме накопления за установку нового приложения или шеринг в соц.сетях, отзывы, комментарии, опросы
Обратная связь – можно дать оценку магазину и обслуживанию после посещения, связаться по чату/
телефону/емейл
Push-уведомления – возможность сообщать пользователю об акции или брошенной корзине, поздравить с
днем рождения и пр., GEO-PUSH – когда находятся рядом с магазином.

5. Приложения для анализа

Приложения для анализа были отобраны по совокупности факторов:
— Известность бренда;
— Аналогичная целевая аудитория;
— Современный и удобный интерфейс;
— Наличие большинства функций, планируемых к реализации
VALTERA
Азбука вкуса
Girls Dress Up

6. Информационная структура приложения

1-й этап
0. Экран загрузки
Welcome
2-й этап
3-й этап
4-й этап
1.Главный экран
Программа
лояльности
Карта
Информация
Получить баллы
Оформить карту
Акции
Показать карту
Новости
Заказ
Магазины
Ввод номера
телефона
Ввод кода
подтверждения
Потратить баллы
Профиль
пользователя
Добавить фото или
выбрать из галереи
(или коненект с
соцсетью)
Изменить
персональные
данные
Запрос на доступ к
данным
Магазин
поощрений
Изменить
персональные
данные
Push-нотификации
Карточка товара
На карте
Страницы
Избранное
Схемы
Контакты
Социальная
активность
Ассортимент
Ассортимент
Ассортимент
Корзина
Бронирование в
магазине
5-й этап

7. Общие функции

8. 0.Экран загрузки

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

9. 1. Главный экран. Основная навигация

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

10. Профиль пользователя/ Запрос на доступ к данным

ФИО
Дата рождения
Город/регион
Телефон
Емейл
Добавить фото (коннект с соцсетью)
Согласие на коммуникацию

11. Изменить персональные данные

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

12. Социальная активность

• кнопки соцсетей, комментарии к товарам, шеринг и т.д.

13. 2. Программа лояльности

14. 2.0. Программа лояльности

Бонус от 3% до 20%
Оплата баллами до 100% покупок (1 балл = 1 руб.)
Уровни участия в программе для получения привилегий:
Название уровня
бонус, % от
суммы покупок
Пороговая сумма для
получения карты
большего номинала
(руб.)
Базовый
3%
0 – 10 000
365 дней
Серебряный
7%
10 000 – 15 000
365 дней
Золотой
10%
15 000 – 50 000
365 дней
Платиновый
15%
50 000 – 100 000
365 дней
VIP
20%
от 100 000
365 дней
Срок действия бонусов
(дней)

15. 2.1. Получить баллы

при первом заказе –
при установке приложения –
за регистрацию/заполнение профиля –
действия в соцсетях (за каждый оставленный отзыв,
подписку, опрос, шеринг и т.д.) –
в День рождения –
за каждого приглашенного друга –
за каждую покупку друга –
Участие в акциях – индивидуально по каждой акции
1 руб. = 1 балл
Начисление дополнительных баллов может
происходить 1 раз в месяц или 1 раз в день (в
зависимости от разработки)

16. 2.2. Потратить баллы

Скидка от 3% до 20% в зависимости от накопленной суммы
покупок
Оплата баллами части покупок или полный обмен баллов
на товар (1 балл = 1 руб.)
Уровни участия в программе для получения привилегий:
Скидка/бонус, % от
суммы покупок
Пороговая сумма для
получения карты
большего номинала (руб.)
Срок действия бонусов
7%
0 – 15 000
365 дней
10%
15 000 – 50 000
365 дней
15%
50 000 – 100 000
365 дней
20%
от 100 000
365 дней
(дней)

17. 2.3 Магазин поощрений

ассортимент товаров CLAIRE’S
1 балл = 1 рубль

18. 3. Карта CLAIRE’S

19. 3.0. Карта CLAIRE’S

• электронная карта в приложении
• информация на карте отображает: ФИО, номер, количество баллов,
доступную скидку
• условия или ссылка на краткие и полные условия бонусной системы
У кого есть пластиковая карта, есть возможность
перейти на электронную, сохранив при этом все
данные по накоплениям и списаниям баллов

20. 3.1. Оформить карту

Карту предлагается оформить в трех
случаях:
1. При первом контакте с приложением
2. При оформлении 1-й покупки, если
карта еще не была введена
3. Отдельно на странице внутри раздела

21. 3.2. Показать карту

Изображение карты находится в
верхней части экрана – при тапе на
карту «переворачивается» другой
стороной со штрих-кодом.
Показать изображение
QR-кода при оплате

22. 4. Информация

23. Информация

— Акции и скидки
— Правила программы
— Push-нотификации (могут быть как
триггерные – например о забытой
корзине, так и информирующие)
— Обратная связь
— Телефон горячей линии/чат
— Дополнительная информация

24. Обратная связь/Помощь

Зака Зака
Здесь можно оставить как общий
отзыв, так и отзыв о конкретном
посещении ресторана или доставки.
Можно обратиться через
встроенный мессенджер
Также можно оставить отзыв о
приложении.
Вьет кафе

25. 5. Заказы

26. 5.1. Ассортимент

— Фильтр по поиску товаров
— Сканирование штрих-кода
— Ассортимент по возрастной группе

27. 5.2. Карточка товара

—
Описание товара
Количество в наличие
Цвет
Размер
Поделиться в соцсетях или отправить кому-нибудь

28. 5.3. Избранное

—
Звездочка добавления в избранное
Просмотр товаров в избранном
Переход на карточку товара
Перемещение в корзину

29. 5.4. Корзина

— Оформление заказа (резерва, как в Valtera)
— Отдельное поле для применения промокода на скидку

30. 5.5. Бронирование

Поля для заполнения
— Имя и фамилия
— Телефон
— Email
— Комментарий
— Регион доставки (присутствие магазинов Клэрс)

Источник: ppt-online.org