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

— В сети магазинов у товара могут быть разные статусы: доступен в выбранном магазине, в другом магазине того же города, на региональном складе, недоступен. Как должен работать интерфейс заказа, если в корзине товары с разными статусами?
— Чтобы собрать базовые ограничения, поговорите со стейкхолдерами. Причины серьёзных интерфейсных сложностей обычно находятся за пределами интерфейса;
— Изучите прошлые наработки компании, а также конкурентов, чтобы найти возможные решения. Проанализируйте их;
— Допустимый вариант: разделение корзины на несколько заказов с отдельными способами доставки и оплатой. Рекомендуемые: разделение корзины с единой оплатой или единый заказ с единой доставкой, которой дольше ждать. Последний вариант может стать опцией;
— Составьте карту сценариев с действиями пользователя и ответами системы. В первую очередь опишите основной;
— Составьте логическую карту интерфейса. Это позволит синхронизироваться с другими участниками проекта и ничего не упустить на следующих шагах;
— Пользователь может быть авторизован и нет, активировать промокод, получать заказ не лично, вернуться к оформлению через несколько дней, когда статусы товаров из корзины могли измениться;
— Создайте черновой прототип решения и покажите команде. Так можно увидеть проблемы на ранней стадии, попытаться убедить стейкхолдеров пересмотреть базовые ограничения;
— Может выясниться, что если на одной странице будет несколько заказов, пользователь может оформить один, а остальные не заметить;
— Для пользовательского тестирования полезно сделать высокодетализированный прототип, моделирующий реальное оформление заказа с выбором размера товара, количества, способа получения и так далее;
— На модерируемом тесте можно уточнить, почему какие-то шаги вызвали сложности, как респондент воспринял тот или иной элемент интерфейса.

#process