UX-исследование и дизайн интерфейса интернет-магазина

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

~ 300 000 ₽

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

Контекст

Результат

Бюджет

Прототипы интерфейса

Файл ТЗ

2014

Новый сайт

ООО «Европа Уно Трейд» торгует воздухом. Точнее, воздушными шариками. И другими товарами для дней рождения, новых годов и прочих вечеринок в колпачках со свечками-тортиками. Для широкого круга компания больше известна под розничным брендом «Веселая затея».

Это серьезный бизнес: производство, розничная и оптовая торговля, работа с брендом — совсем не ерунда. И для всей этой не-ерунды нужны технологические инструменты. Много, разных, сложных.

Среди прочих компании «Европа Уно Трейд» нужен и сайт для оформления оптовых заказов. Что совсем, совсем не то же самое, что заказы розничные.

Вот, например, кое-какие жизненные ситуации, в которые попадают оптовики-затейники.

Документ с жизненными ситуациями

PDF

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

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

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

Поэтому настал час X: руководители компании подумали и решили, что для оптовиков действительно нужен отдельный сайт.

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

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

Комикс о связи заказчика, программиста и ТЗ | Sobakapav.ru

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

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

Вот на этом месте нас и вовлекли в работу.

Процесс

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

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

На этом месте мы прощаемся с читателями, никогда не делавшими ни одного IT-проекта. Они заскучали и подумали, что речь о чем-то второстепенном и очень простом. Эка невидаль, записать требования, было бы о чем говорить.

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

А если еще по ходу дела нужно уговорить заказчика не зацикливаться на второстепенных мечтах? И вызнать (иногда партизанскими методами) факты, которые всем представителям бизнеса — но не разработчикам! — кажутся общеизвестными и тривиальными? Да, тут помощник нужен…

Поэтому техническое задание пишут-рисуют трое наших сотрудников: менеджер, проектировщик интерфейсов и аналитик.

Пишут так.

Две страницы, и сразу понятен контекст задачи

А рисуют — например, так.

Прототип интерфейса

Axure

Прототип — тоже часть технического задания

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

Довольно часто «техническим заданием» почему-то называют случайный набор букв в стиле «Что вижу, о том и пою». Смысл не важен, лишь бы много текста и правильное оформление. Сколько бреда можно оформить по ГОСТу, вы даже не представляете.

Нам такой подход к снаряду не нравится. И мы делаем технические задания совсем-совсем по-другому. Вот так.

Что делаем?

План работ, неизбежно приводящий к приемлемому ТЗ

Моделируем поведение пользователей

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

Для смоделированных пользователей проектируем интерфейс

Не «технологическую платформу» или «ядро», а экранчики. Звучит неубедительно, но: разве живым людям есть какое-то дело до ядра? Нет, конечно.

Снабжаем интерфейс комментариями технологического характера

Все-таки абстрактные картинки мало помогут конкретному разработчику «поженить» прототип с технологической платформой — поэтому пояснения нужны обязательно.

Как делаем?

Аналитические и дизайн-техники

Анализ технических возможностей.

Бизнес-интервью.

Кейс-моделирование.

Моделирование пользователей.

Детальное проектирование.

Такой метод — не стопроцентная гарантия, но все-таки хорошая страховка от непонимания требований программистами.

В проекте для «Европы Уно Трейд» все шло как обычно — и как мы только что рассказали.

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

Результат

На выходе — бумажка. Да, просто бумажка с заголовком «Техническое задание». У нас таких много — для разных бизнесов и разных задач.

Итоговое ТЗ

MS Word

Хорошее техническое задание — это не просто инструкция для программиста. Мы подготовили условия для диалога между заказчиком и разработчиками. Если что-то пойдет не так, всегда можно ткнуть пальцем в ТЗ и сказать, чтобы делали, как написано

Но что важней — на выходе получается заказчик, который разобрался в своих требованиях-ожиданиях. И готов с головой погружаться в разработку. И погрузился. Сайт работает, соответствует прототипу, радует оптовых клиентов и приносит «Европе Уно Трейд» свою вполне себе осязаемую пользу.

Смысл

Альтернатив ТЗ всегда довольно много.

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

Можно играть в гибкие методологии и управлять backlog’ом. Но для этого нужна очень высокая квалификация заказчика.

Можно самостоятельно написать ТЗ. Озадачить какого-нибудь подходящего сотрудника, умеющего быстро печатать, — и вот буквально через месяц у вас много букв. Без картинок, но это нюансы.

На самом деле выбор зависит от сути проекта. Иногда мы рекомендуем не заморачиваться ТЗ или делать его как попало. Но для «Европы Уно Трейд» техническое задание — на наш экспертный взгляд — нужно было сделать.

Вот мы и сделали.