Проектирование интерфейсов

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

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

Небольшой дисклеймер

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

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

Что понимаю под исследованием аудитории

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

Примеры количественных методов:

• Анализ данных систем веб- и мобильной аналитики.
• Онлайн- и офлайн-опросы пользователей продукта или респондентов в панели.
• Карточная сортировка.

Примеры качественных методов:

• Глубинное интервью пользователей.
• Модерируемое или не модерируемое юзабилити-тестирование респондентов.
• Дневниковые исследования.

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

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

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

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

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

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

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

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

Ненужная функциональность

Антикейс 1 возможность сравнения товаров в одной категории и расширенные фильтры для интернет-магазина

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

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

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

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

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

Как можно было поступить лучше

Команда могла узнать отношение пользователей к изменениям на этапе принятия решения о разработке. Это мог быть тот же онлайн-опрос на сайте. Он бы дал понимание опыта предыдущих покупок и потребностей пользователей в новой функциональности.

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

Антикейс 2 мобильное приложение для банковских клиентов

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

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

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

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

Можно ли было предусмотреть такой результат да. 5% клиентов компании давали 95% дохода. Причём эти клиенты никогда сами не проводили операции и взаимодействовали только со своими менеджерами на стороне компании. Всю отчётность для них привозили менеджеры и показывали её в распечатанном виде. Логично, что при такой модели новое приложение никак не затронуло основных, приносящих деньги клиентов. И тем более не привлекло бы таких же новых клиентов.

Как можно было поступить лучше

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

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

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

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

Неудобная функциональность

Антикейс 1 неудачная структура лендинга

Представим себе лендинг конференции. Структура лендинга сверху вниз:

• большой баннер с логотипом, названием и датами проведения;
• топ-10 спикеров с фото (известные всем кто в теме);
• баннер;
• ещё 30 спикеров с фото;
• форма заявки на покупку билета;
• полная программа мероприятия;
• карта проезда;
• форма заявки на покупку билета;
• логотипы партнёров.

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

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

Дальше решили провести A/B/N-тестирование, при котором на странице меняли местами форму заявки с другими блоками контента. Почему начали с формы? На лендинге была простая навигация, она не вызывала сложностей. Самих спикеров и их темы менять уже было поздно. Из возможных вариантов оставалась только сама структура страницы и расположение формы заявки.

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

• большой баннер с логотипом, названием и датами проведения;
• топ-10 спикеров с фото;
• форма заявки на покупку билета;
• всё остальное.

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

Как можно было поступить лучше

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

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

Антикейс 2 калькулятор для расчёта размера страховки

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

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

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

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

Мы провели A/B-тестирование и после анализа запросов пользователей в техподдержку добавили для сложных полей подсказки. В результате за счёт кропотливой проработки текстов подсказок удалось увеличить конверсию на 10%.

В этом кейсе комплексного исследования не требовалось. Команде дизайнеров было сразу понятно, что сложные пункты нужно подробно объяснить. Поэтому проводили A/B-тесты, чтобы понять, как лучше описать подсказки.

Как можно было поступить лучше

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

Резюмируем

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

Бывают случаи, когда исследование излишне: нет ресурсов, времени или задача не влияет на критичные бизнес-показатели. Однако даже в таких случаях лучше провести хотя бы минимальное исследование, пусть даже коридорный опрос, чтобы проверить получившийся результат. Когда от дизайна зависит удобство использования продукта, лучше опираться на объективные данные, которые собрали перед началом работы.

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

Совершенствование продуктов с применением когнитивных искажений и моделей убеждения.

Несколько лет назад коллега из моей бывшей компании (BlaBlaCar) познакомил меня с игрой Mental Notes. Разрабатывая какую-либо функцию, мы вместе с несколькими менеджерами по продукту, дизайнерами и разработчиками делали поведенческий анализ, во время которого старались понять, как и какие принципы поведенческой психологии можно применить в проекте.

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

Для справки: представленные далее темы и их описания взяты из колоды карт Mental Notes.

Социальное доказательство

В новых и незнакомых обстоятельствах мы склонны следовать образцам поведения тех, кто на нас похож.

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

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


Приложение для медитации Petit BamBou

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


Страницы с ценами в мобильных приложениях The Athletic и MasterClass

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

Любопытство

Если человека подразнить интересной информацией, он захочет узнать больше!

Именно это делает фитнес-приложение Strava в своей функции Анализ темпа: вам дают предпросмотр того, как выглядит график, но не более того. Чтобы увидеть подробный анализ, нужно купить подписку Summit.


Анализ темпа в Strava триггер, побуждающий подписаться на премиум-версию

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


Веб-сайт Wall Street Journal

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

Узнать проще, чем вспомнить

Пережитое ранее легче узнать, чем вспомнить.

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

Например, Airbnb дает восемь различных критериев оценки места, где вы останавливались. Это позволяет получить от гостя достаточно количественной информации в случае, если он не даст словесный отзыв. Кроме того, благодаря такому подходу гостям проще вспомнить определенные моменты своего опыта. Если бы Airbnb не предлагал все эти категории, то оценки наверняка были бы менее аккуратными: гости оценивали бы только самые приятные и неприятные впечатления, а про середину забывали бы.


Система оценок Airbnb

Поэтому и страховой стартап Lemonade предлагает несколько предопределенных категорий дорогостоящих предметов.


Последний этап процесса запроса расценок в Lemonade

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

Приятные моменты

Мы вспоминаем и положительно реагируем на небольшие, неожиданные и веселые приятные моменты.

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


Скриншоты приложения Zenly

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


Если включить композицию из плейлистов Звездных войн на Spotify, то панель воспроизведения превратится в световой меч.

Привязка и приспосабливание

Принимая решения, мы чересчур полагаемся или привязываемся к одному аспекту или фрагменту информации.

Например, при покупке ноутбука на сайте Apple.com вам предлагают множество вариантов (200 $ мощнее процессор, 100 $ лучше видеокарта, 400 $ больше объем диска, 299,99 $ предустановленный Final Cut Pro X, 199,99 $ Logic Pro X). Если брать по отдельности, то за всё получится внушительная сумма. Но вы уже сделали мысленный скачок и платите за ноутбук 2799 $, поэтому кажется, что каждая опция не так уж и дорого, верно?



Тот же подход применим, когда вы платите 150 $ за продукты на кассе, и вам предлагают пожертвовать на благотворительность 0,50 $ не такая уж и большая сумма относительно всего чека, верно?

Умеренные трудности

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

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

Эстетика как удобство использования

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

Привлекательные элементы воспринимаются нами как более удобные в использовании. Приложение-календарь Sunrise, купленное Microsoft в 2015 г. за более чем 100 млн долл., на тот момент было лучшим в своей категории на платформах iOS и Android: тысячи пользователей хвалили его за понятный и удобный интерфейс.



Но действительно ли возможности Sunrise такие уникальные? В приложении было несколько удобных функций например, интеграция с событиями в Facebook. Но ничего сверхнеобычного там не было в том числе ничего, что календари от Apple или Google не могли бы скопировать за пару недель.

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

Установление ценности

Мы ценим то, что стоит дороже.

Стоимость может выражаться и в деньгах, и во временных затратах.

В отношении денег можно привести множество не самых интуитивных примеров, когда компании повышали конверсию и (или) доход, просто подняв цены. В книге Не сходите с ума на работе Джейсон Фрайд и Дэвид Хайнемайер Хенссон рассказывают, что повышение начальной цены Basecamp с 29 $ до 99 $ в месяц позволило привлечь новых клиентов: иногда чем выше стоимость, тем более полезным кажется продукт.


Страница с ценами Basecamp

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

Боязнь потери

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

Хороший пример этого психологического трюка часто можно увидеть при отмене подписки на некоторые сервисы. Например, если вы решите отменить тарифный план Adobe Creative Cloud, вы увидите следующее:


Процесс отмены подписки на Adobe Creative Cloud

Вам перечисляют всё, что вы потеряете и в смысле финансов (из-за платы за досрочную отмену), и в смысле функций (которыми вы больше не сможете пользоваться).

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



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

Боязнь потерь также широко эксплуатируется в условно-бесплатных приложениях с подпиской. Предположим, вы запустили вводный курс медитации в Headspace. Если вы прошли 10 занятий, можно сказать, что вы определенно намерены научиться медитации. Но если не оформить платную подписку, вы не сможете продолжить и потеряете накопленный момент.

Контраст

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

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



Что нужно пассажиру на этом этапе? Спокойно указать свои данные, при необходимости добавить пару услуг и поскорее перейти на страницу оплаты.

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

А вот в Opodo иерархия действий не очень хорошо отражена контрастом: разделы выбора места, отправки по электронной почте, добавления багажа и входа в учетную запись выделены так же, как переход к следующим этапам. Даже если такая иерархия направлена на увеличение дополнительных продаж (скорее всего, так и есть), она с большой вероятностью приведет к снижению общей удовлетворенности пользователей.

Регулярные события

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

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

Последовательность действий

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

Хороших примеров разбиения сложного действия на последовательность простых бесчисленное множество. Продуктам часто удается разбить сложные процессы на удобные и быстрые действия. Например процесс публикации в Airbnb или процесс перевода денег в TransferWise.

В этой статье я рассмотрю процесс регистрации в онлайн-банке N26: выделив каждому этапу регистрации отдельный экран, разработчики создают впечатление, что открыть банковский счет проще простого!


Процесс регистрации в N26 в 2018 г.

На веб-сайте они даже дают такую рекламу: Банковский счет в N26 за 8 минут.



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

Ограниченный выбор

Мы с большей вероятностью сделаем выбор, когда вариантов меньше.

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

Например, прокат автомобилей Virtuo строит бизнес на том, что предлагает в каждом случае всего несколько автомобилей премиум-класса.


Результаты поиска в приложении Virtuo

Если вам дается ограниченный выбор, вы с большей вероятностью примете решение.

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

Репутация

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

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



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

Авторитет

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

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

Например, AirHelp помогает клиентам затребовать компенсацию за задержку или отмену авиарейса. Юристы сервиса знают законодательство различных стран мира (относящееся к авиасообщению) и помогут вам затребовать как можно больше денег. Но как можно быть уверенным, что кто-то, кого вы не знаете лично, может помочь вам вернуть деньги?

AirHelp понимает эту проблему поэтому они добавляют в процесс запроса элементы, обосновывающие его авторитетность:

• Они упоминают регламент EC261.
• Они дают возможность пообщаться с человеком: Джейн ваш помощник в AirHelp.

Первая страница процесса оформления заявки на компенсацию на сайте AirHelp

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

Ограниченный доступ

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

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



Приложение Inbox в итоге кануло в лету: компания Google закрыла его в 2019 г. Сервис предлагал пару новых (в сравнении с Gmail) функций, но ожидаемой революции в электронной почте он не произвел. Тем не менее, продвижение этого продукта на рынке было успешным. Подобный ажиотаж сейчас наблюдаются вокруг Superhuman и Clubhouse.

Еще один пример ограничения доступа сообщество дизайнеров Dribbble.


Главная страница Dribbble

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

Самовыражение

Мы ищем возможность выразить свою личность, свои чувства и мысли.

Это очень мощный принцип, который работает во всех возрастных группах.

Приложения, ориентированные на подростков, почти всегда дают возможность настроить профиль: изменить цвета, аватар, добавить классные аксессуары и т. д. Примеры Pokmon Go, Snap (с Bitmoji) и (совсем недавно) Stadium Live.


Настройка аватара в Stadium Live

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


Настраиваемые рамки для фото в профиле Facebook

Среди SaaS-инструментов также можно найти такие примеры: Trello дает пользователям возможность менять цвет и изображение фона, Slack предлагает множество тем для настройки интерфейса.

Использование принципа самовыражения укрепляет связь между продуктом и пользователями.

Дефицит

Если что-то ограничено в доступности или рекламируется как дефицитное, мы склонны придавать этому более высокую ценность.

Безупречное мастерство в применении этого принципа демонстрирует Booking.com: при просмотре гостиниц на странице поиска нередко можно увидеть несколько визуальных подсказок, указывающих на дефицитное предложение.



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

• Забронировано 27 раз за последние 6 часов (эта фраза также применяет принцип социального доказательства).
• Большой спрос: на сайте осталось всего 7 номеров!

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

Юмористический эффект

Поданная с юмором информация запоминается легче и радует пользователя.

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

Например, при поиске маршрута из пункта А в пункт Б иногда можно использовать функции Телепорт, Катапульта или Реактивный ранец и тогда Борис Джонсон переместится из А в Б менее чем за 5 секунд.


Предложение катапультировать Бориса Джонсона и правда звучит забавно.

Citymapper и платную подписку строит частично на таком юмористическом подходе.


Платная подписка Citymapper Citymapper CLUB

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

Непредсказуемые вознаграждения

Случайные вознаграждения сильные мотиваторы: они кажутся редкими и отличаются непредсказуемостью (а также реже противоречат внутренней мотивации).

Один из элементов, благодаря которым Snapchat завоевал пользователей, это трофеи.


Трофеи в Snapchat

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

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

Подробнее о непредсказуемых вознаграждениях и геймификации в этой колоде в целом пишет Mozza: Mobile Gamification How The Best Apps Nailed It (Waze, Duolingo, Tinder, Snapchat, LinkedIn, Zenly).

---

Надеюсь, вам понравились эти примеры! Может, и вы знаете примеры реализации психологических принципов в дизайне продукта? Расскажите о них!

Если вас заинтересовали Mental Notes и соответствующая карточная колода, то, к сожалению, заказать ее уже нельзя. Но похожую информационную подборку можно найти здесь: плакат Persuasive Patterns Poster от UI Patterns.

Если вам понравилась эта статья и вас интересует применение психологии в дизайне продуктов, я рекомендую зайти на отличную страницу Growth.design The Psychology of Design, где составлен еще более длинный список (101 пункт!) когнитивных искажений и принципов, влияющих на удобство пользования.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее

Привет, Хабр!

Продолжая исследование темы C#, мы перевели для вас следующую небольшую статью, касающуюся оригинального использования extension methods. Рекомендуем обратить особое внимание на последний раздел, касающийся интерфейсов, а также на профиль автора.




Уверен, что любой, хотя бы немного имевший дело с C#, знает о существовании методов расширений (extension methods). Это приятная фича, позволяющая разработчикам расширять имеющиеся типы новыми методами.

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

Добавление методов к перечислениям

Перечисление это просто набор константных числовых значений, каждому из которых присвоено уникальное имя. Хотя, перечисления в C# и наследуют от абстрактного класса Enum, они не трактуются как настоящие классы. В частности, это ограничение не позволяет им иметь методы.

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

Например, представьте себе следующий тип в обычном приложении, позволяющем сохранять файлы в различных форматах:

public enum FileFormat{    PlainText,    OfficeWord,    Markdown}

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

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

public static class FileFormatExtensions{    public static string GetFileExtension(this FileFormat self)    {        if (self == FileFormat.PlainText)            return "txt";        if (self == FileFormat.OfficeWord)            return "docx";        if (self == FileFormat.Markdown)            return "md";        // Будет выброшено, если мы забудем новый формат файла,        // но забудем добавить соответствующее расширение файла        throw new ArgumentOutOfRangeException(nameof(self));    }}

Что, в свою очередь, позволяет нам поступить так:

var format = FileFormat.Markdown;var fileExt = format.GetFileExtension(); // "md"var fileName = $"output.{fileExt}"; // "output.md"

Рефакторинг классов моделей

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

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

Итак, рассмотрим следующий пример с двумя моделями: одна представляет закрытый список титров, а другая отдельную строку титров:

public class ClosedCaption{    // Отображаемый текст    public string Text { get; }    // Когда он отображается относительно начала трека     public TimeSpan Offset { get; }    // Как долго текст остается на экране     public TimeSpan Duration { get; }    public ClosedCaption(string text, TimeSpan offset, TimeSpan duration)    {        Text = text;        Offset = offset;        Duration = duration;    }}public class ClosedCaptionTrack{    // Язык, на котором написаны субтитры    public string Language { get; }    // Коллекция закрытых надписей    public IReadOnlyList<ClosedCaption> Captions { get; }    public ClosedCaptionTrack(string language, IReadOnlyList<ClosedCaption> captions)    {        Language = language;        Captions = captions;    }}

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

var time = TimeSpan.FromSeconds(67); // 1:07var caption = track.Captions    .FirstOrDefault(cc => cc.Offset <= time && cc.Offset + cc.Duration >= time);

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

public static class ClosedCaptionTrackExtensions{    public static ClosedCaption GetByTime(this ClosedCaptionTrack self, TimeSpan time) =>        self.Captions.FirstOrDefault(cc => cc.Offset <= time && cc.Offset + cc.Duration >= time);}

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

1. Понятно, что этот метод работает только с публичными членами класса и не изменяет его приватного состояния каким-нибудь таинственным образом.
2. Очевидно, что этот метод просто позволяет срезать угол и предусмотрен здесь только для удобства.
3. Этот метод относится к совершенно отдельному классу (или даже сборке), назначение которых отделять данные от логики.

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

Как сделать интерфейсы разностороннее

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

Если вам это кажется нонсенсом, рассмотрим типичный интерфейс, сохраняющий модель в файл:

public interface IExportService{    FileInfo SaveToFile(Model model, string filePath);}

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

Таким образом, чтобы выполнить это требование, мы добавляем к контракту новый метод:

public interface IExportService{    FileInfo SaveToFile(Model model, string filePath);    byte[] SaveToMemory(Model model);}

Это изменение только что сломало все имеющиеся реализации IExportService, поскольку теперь все их нужно обновить, чтобы они поддерживали и запись в память.

Но, чтобы не делать всего этого, мы могли с самого начала спроектировать интерфейс немного иначе:

public interface IExportService{    void Save(Model model, Stream output);}

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

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

К счастью, этот недостаток полностью обнуляется при использовании методов расширений:

public static class ExportServiceExtensions{    public static FileInfo SaveToFile(this IExportService self, Model model, string filePath)    {        using (var output = File.Create(filePath))        {            self.Save(model, output);            return new FileInfo(filePath);        }    }    public static byte[] SaveToMemory(this IExportService self, Model model)    {        using (var output = new MemoryStream())        {            self.Save(model, output);            return output.ToArray();        }    }}

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

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

Проектирование автоматизированной системы работы с дилерами

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

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

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

Конечно, добавим, ответим мы и обязательно предложим сделать это правильно.

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

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

• Что будет в личном кабинете дилера?
• Просто заказы с документами и создание нового.

• Действительно, просто. А откуда возьмутся заказы? Как сейчас они создаются? Возможно ли взаимодействие с этой системой через api? Кто сможет их создавать в нашей системе? А кто не сможет? Можно ли отменить? А если заказ уже отгружен? У кого будет доступ к заказу? А документы в какой момент и откуда возьмутся? А можно ли их выгрузить? Как будут меняться статусы? Будет ли кто-то контролировать выполнение заказа? С заказом могут быть рекламные материалы, говорите? А что за материалы, кто их создает, кто прикрепляет к заказу?

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

Исследование

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

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

Наш клиент один из ведущих российских производителей материалов для строительства и отделки. Это предприятие полного цикла производства: от добычи гипсового камня (у компании собственная сырьевая база) до фасовки и упаковки готовой продукции. Поставки продукции компании осуществляются в более чем 100 городов России, а также в другие страны Европы и Азии. У компании примерно 150 дилеров, которые реализуют продукцию своей оптово-розничной сети. Ведется тщательная работа по привлечению и удержанию дилеров. Компания всячески поддерживает их в продвижении товаров, стимулирует продавать больше интересными маркетинговыми акциями и системой бонусов.

Интервью с заинтересованными лицами, постановка бизнес-целей

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



Такие проблемы нам были озвучены:

• Вся работа с дилерами ведется по телефону и электронной почте. Заказ оформляется письмом на электронный адрес, обновления по нему обсуждаются в личном общении. Общение и оформление заказа ручной труд, который отнимает много времени сотрудников.
• Нет актуальной информации о наличии товара на складе. Информация об остатках поступает менеджерам утром и не обновляется в течение дня. При формировании заказа нельзя точно сказать, доступно ли нужное количество товара.
• У компании нет данных о деятельности дилеров: количестве товара на их складе, доле продукции компании в общем портфеле, популярности конкретных линеек товара, конечных покупателях и потребителях. Таким образом, нет возможности оптимально планировать отгрузки и маркетинговую деятельность.
• Дилеры не получают полную информацию о сотрудничестве с компанией, теряют документы, не понимают, насколько выполнен план продаж, не знают о положенных им бонусах и подарках.
• Анализ объемов продаж дилерам, остатки на их складах, планирование производства происходит в ручном виде аналитиком предприятия на основе догадок и предположений. Все данные собираются в один файл в формате excel, из него создаются отчеты.
• Руководители отдела не получают точной информации о работе сотрудников своего отдела и не могут точно планировать их загрузку, ставить планы продаж.

Таким образом, целями работы стали:

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

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

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

На первой встрече с нашим заказчиком мы также:

1. Узнали, что:

• Все продажи компании организованы по дивизионам, созданным с географической привязкой к странам и регионам России.
• У каждого дивизиона есть руководитель и несколько региональных менеджеров, за которыми закреплены регионы и торговые представители (дилеры) в конкретных городах.
• Дилеры, в свою очередь, продают продукцию компании своей оптовой и розничной сети, поставляют на стройки объектов.

2. Получили:

• Договор партнерства,
• Пример аналитического отчета об отгрузках,
• Каталог продукции,
• Рекламные материалы.

3. Познакомились с:

• Генеральным директором,
• Коммерческим директором,
• Руководителем отдела продаж,
• Руководителем отдела маркетинга.,
• Руководителем отдела логистики,
• Главным бухгалтером.

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

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

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

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

AS IS или описание существующих бизнес-процессов, выявление проблем, сбор пользовательских требований

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

Пример списка сотрудников для общения:

• Генеральный директор;
• Заместители директора (два человека);
• Руководитель дивизиона (три человека);
• Менеджер отдела продаж (три человека);
• Руководитель отдела логистики;
• Руководитель отдела маркетинга;
• Главный бухгалтер;
• Трейд-маркетолог;
• Аналитик;
• Дилер (три человека).

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

Пример описания текущей ситуации:

У каждого дилера есть каталог товаров компании и действующий прайс-лист. Прайс-лист зависит от города, в котором находится компания дилера, а также может зависеть от конечного объекта, на который поставляются материалы (для одного того же дилера может быть предоставлена скидка для определенного объекта).

Для размещения заказа дилер отправляет письмо-заявку на электронный адрес закрепленного за компанией менеджера. В заявке он указывает:

1. Названия и количество товаров, которые необходимы,
2. Свои реквизиты;
3. Адрес грузополучателя, куда необходимо отгрузить товар;
4. Транспорт, которым необходимо отправить товар;
5. Желаемую дату отгрузки.

Менеджер отдела продаж создает новый заказ для дилера в системе 1С:

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

После размещения заказа для него формируется заявка на транспорт, которая отправляется в отдел логистики.

Пример пользовательских требований к новой системе:

а) Автоматизировать создание заказа дилером, дать ему возможность набрать и разместить заказ самостоятельно, следить за его статусом выполнения, видеть историю всех своих заказов за время работы с компанией;
б) Дать возможность дилерам размещать предварительные заказы на неделю для возможности прогнозирования производства и отправки товара;
в) Дать возможность менеджеру отдела продаж видеть резерв товара на складе;
г) Дать возможность менеджеру автоматически определять количество поддонов и транспортных средств в зависимости от объема заказа;
д) Сохранять все документы по всем заказам дилера и дать возможность скачивать их всем заинтересованным лицам (менеджер, руководитель, бухгалтер, дилер).

На этом этапе аналитику важно содействие со стороны заказчика:

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



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

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

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

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

Полевые исследования

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



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

Технические особенности

Уже давно нет таких предприятий, которые не использовали бы в своей работе какие-либо специальные программы и инструменты (например, 1С). На этапе исследования важно понять, какие данные содержатся в таких программах, насколько они необходимы, подходят ли они по формату и, самое главное, как их извлечь или использовать в результате интеграции с системой.

Для работы личного кабинета нашего заказчика были необходимы каталог товаров и данные дилеров (контрагентов). Все это хранится в системе 1С: Предприятие. Структура каталога не оптимальна, использовать ее неудобно (интуитивно не понятно, в какой категории находится товар, а ведь дилеру теперь придется искать его самостоятельно), данные не всегда заполнены (нет описаний, перепутаны фасовки).

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

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

В результате этапа исследования у нас, как правило, есть:

1. Сформулированные руководством цели и задачи для создания личных кабинетов;

2. Общее понимание и детальное описание бизнес-процессов, которые будут автоматизированы в результате их создания;

3. Список пользовательских требований от каждого типа пользователей личного кабинета;

4. Список систем, с которыми будет необходимо взаимодействовать, их описание и технические данные.

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

Проектирование

TO BE или проектирование новых бизнес-процессов и пользовательских сценариев

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

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

Пользовательское требование руководителя дивизиона:

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

Возможные сценарии на основе этого требования:

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

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

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

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

Выделение минимального набора сценариев для запуска

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

Пример MVP:

Личные кабинеты:

• Генерального директора,
• Руководителя дивизиона,
• Менеджера продаж,
• Маркетолога (зачеркнуто),
• Сотрудника отдела логистики (зачеркнуто),
• Главного бухгалтера (зачеркнуто).

Примеры сценариев руководителя дивизиона:

• Установка плана продаж сотрудников,
• Установка плана продаж по договору для дилеров,
• Контроль статусов заказов (зачеркнуто),
• Получение статистики продаж дивизиона по сотрудникам,
• Получение статистики продаж дивизиона по дилерам,
• Просмотр информации дилера.

Примеры сценариев дилера:

• Просмотр условий работы с компанией, плана продаж,
• Размещение заказа (зачеркнуто),
• Просмотр статистики продаж за месяц,
• Размещение заявления на получение маркетинговых материалов (зачеркнуто),
• Участие в акции (зачеркнуто).

Функциональные требования

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

Пользовательское требование руководителя дивизиона:

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

Функциональные требования, которые из него вытекают:

1. Видеть общую информацию по отгрузкам дилерам своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города; конкретного менеджера;

д) конкретного дилера.

2. Устанавливать и менять план отгрузок на месяц для каждого менеджера дивизиона.

3. Видеть план компании по отгрузкам для дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) группы товаров (ССС, СЦС, ГСП, ПГП);

г) конкретного товара;

д) конкретного менеджера;

е) конкретного дилера.

4. Сравнивать (видеть одновременно) запланированные показатели с фактическими для того, чтобы увидеть отклонения и тенденции. Необходима возможность множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/ города; конкретного менеджера;

д) конкретного дилера.

5. Видеть общую информацию о вторичных продажах дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/города;

г) конкретного менеджера;

д) конкретного дилера.

6. Указывать, сколько дилеров предоставили информацию.

7. Видеть общую информацию о структуре вторичных продаж дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/дивизиона и города;

г) конкретного менеджера;

д) конкретного дилера.

8. Видеть общую информацию о дебиторской задолженности дилеров своего дивизиона с возможностью множественного и одновременного выбора срока задолженности:

а) общая;

б) не более 14 дней;

в) 15-30 дней;

г) 31-45 дней;

д) 46-60 дней;

е) больше 61 дня.

9. Видеть список всех платежей дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) конкретного менеджера;

г) конкретного дилера.

10. Видеть прогнозы отгрузок продукции от дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города;

д) типа транспорта;

е) конкретного менеджера;

ж) конкретного дилера.

Создание структуры системы, права пользователей

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

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

Пример структуры кабинета дилера, * отмечена версия MVP:

1. Страница авторизации*

2. Рабочий стол*

3. Моя компания

а) Профиль*

б) Договор и дополнения*

в) Коммерческие условия*

г) О компании*

сотрудники*

склады*

территория работы*

контракты других производителей*

специализированные подразделения*

требования и преимущества*

д) Грузополучатели*

е) Объекты*

4. Каталог

а) Список товаров

б) Корзина

в) Оформление заказа

5. Заказы и платежи

а) Мои заказы

заказы

отгрузки

б) Мои платежи

в) Дебиторская задолженность

5. Продвижение

а) POS-материалы

б) Акции

в) Бонусы

6. Сдать отчет*

7. Помощь*

8. Настройки*

9. Контакты*

10. Уведомления*

а) Автоматические уведомления*

б) Сообщения*

в) Написать сообщение*

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

Вот так могут быть заданы права:

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

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

Структура данных всегда представлена в виде схемы:



Советы:

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

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

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

Техническое задание

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

Отрывок из технического задания:

3.1.1.1.1. Склады

Основная часть страница включает следующие элементы:

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

название (адрес) склада;

город, в котором расположен склад;

площадь склада (кв.м.);

отметка принадлежности склада компании. Если стоит эта отметка, данные площади склада учитываются в статистической информации о складах в Личном кабинете сотрудника. Площадь складов, у которых не стоит данная отметка, в этой статистике не учитывается;

дополнительная информация: текст с описанием склада.

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

Если пользователь сделал несколько изменений за один месяц, в статистике необходимо учитывать последние предоставленные данные. Таким образом, текущий показатель площадей склада партнера сохраняется на 23:59 ч последнего дня месяца и именно эти данные показываются как показатель данного месяца.

2. Форма добавления нового склада со следующими полями, * отмечены обязательные для заполнения поля:

название (адрес) склада (текстовая строка)*;

город склада (текстовая строка)*;

собственный склад (чекбокс)*;

площадь склада, м2 (число)*;

дополнительная информация (текстовое поле).

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

При добавлении склада партнер видит сообщение: Спасибо за вашу информацию!, а менеджер партнера и руководитель его дивизиона получают уведомление в виде автоматического уведомления, а также сообщения в разделе Уведомления о том, что партнер добавил новый склад. Площадь нового склада, при условии, что склад отмечен как собственный склад компании, добавляется в статистику площадей складов за тот месяц, в котором был добавлен новый склад и сразу же отображается в ней. Добавленный партнером склад сразу же отображается в его списке.

Если на странице еще не был добавлен ни один склад, пользователь видит сообщение об этом: Вы еще не добавили ни один склад. Пожалуйста, сделайте это с помощью формы ниже и форму добавления склада.

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

Если пользователь добавил несколько складов в одном месяце, для статистики необходимо учитывать последние изменения.

Подытожим

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

Наш заказчик получил:

1. Личный кабинет для дилеров компании с возможностями:

самостоятельно собрать и оформить заказ продукции компании, видеть статусы обработки и поставки на склад,

делать предварительные заказы, тем самым предоставлять возможность планировать производство и транспорт для доставки,

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

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

2. Личные кабинеты сотрудников компании с возможностями:

планировать продажи дилерам с учетом актуальной информации о наличии товара на складе предприятия,

получать и обрабатывать заказы дилеров в рамках своих полномочий и последовательных этапов общего процесса работы с заказами,

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

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

хранить и обрабатывать результаты маркетинговых акций

В результате работ по проектированию у участников проекта появилась возможность выбрать отвечающую всем требованиям технологию разработки (веб-технологии с использованием зарекомендовавших себя фреймворков), что позволило значительно (7-8 млн. рублей вместо 70 млн.) снизить стоимость разработки по сравнению с разработкой на основе известных программных продуктов, например SAP.