Процесс: Как происходил полный редизайн «Мегаплана»

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

#самизнаетекакиекнопки

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

Капля истории

В 2007 году, работая дизайнером в «Студии Артемия Лебедева», я
спроектировал первый «Мегаплан».

Каких-то семь-восемь лет назад все пользовались почтой или самописными системами для совместной работы. «Мегаплан» стал одним из первых онлайн-инструментов для управления задачами.

Первые подходы к дизайну интерфейса выглядели так:

В 2010 я вернулся к работе над «Мегапланом» уже в качестве арт-директора. За это время в интерфейсе накопился мусор, чувствовалось отсутствие гайдлайнов, появился разнобой и солянка. Пригласили дизайнеров и редактора. Вместе с ребятами привели систему в порядок: освежили оформление, выбросили мусор, подмели, покрасили, привели к единообразию. Стало хорошо и дружелюбно:

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

Решение о новом дизайне

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

Зачем менять что-то, что уже работает, почему нельзя продолжить улучшать то, что есть?

У нас появилась метафора для ответа на этот вопрос: «Улучшая лошадь, нельзя придумать автомобиль».

Появились требования, которые не лезли в старый интерфейс. Мы не могли радикально поменять логику и дизайн, оставаясь в рамках того же продукта. Наши пользователи привыкли к определенному интерфейсу. Если мы внесем радикальные изменения в дизайн привычного «Мегаплана», то осложним жизнь платящих клиентов. Нельзя в одно прекрасное утро превратить чью-то карету в автомобиль. «Мегаплан» — не игрушка, не промо-сайт, а жизненноважный инструмент. По этой же причине, например, дизайн почтовых клиентов меняют настолько аккуратно, насколько это возможно, всегда оставляя старую версию.
За пять лет существования «Мегаплана» мир сильно поменялся. Появилось много новых технологий, которые нельзя с легкостью внедрить. Полезные технологии, с помощью которых мы могли бы улучшить жизнь наших клиентов, постоянно появляются и некоторые проходят мимо.

Пять источников информации для редизайна

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

Говорит «Мегаплан»

У сотрудников компании «Мегаплан» есть пятилетний опыт использования «Мегаплана». Мы выписали то, что не устраивает нас самих.

Входящие

Посмотрим на то, что люди физически делают большую часть времени в «Мегаплане»:
95% — оперативная работа: читать, писать, отвечать, прикладывать документы, скачивать документы.
5% — организационная и аналитическая работа: менять дедлайны, ставить приоритеты, менять участников, создавать проекты, строить отчеты.

Начало дня в «Мегаплане» — это разгребание входящих. Разгрести входящие можно из двух мест:

1. Информер — маленький баблик в углу экрана, показывающий по клику ваши уведомления. Проблема в том, что «разгребать» входящие из информера утомительно. Тысяча непрочитанных уведомлений — верный признак того, что пользователь перестал пользоваться этим интерфейсом:

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

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

Общение

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

Быстрая постановка задачи

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

Навигация

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

Говорят пользователи

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

Кто говорит

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

1. «Платники» и «бесплатники». В «Мегаплане» есть платящие и не платящие клиенты. И те и другие высказывают пожелания. Важно понимать разницу между пожеланиями «я хочу» и «я готов заплатить за».

Картинка из статьи
blog.intercom.io

2. Активисты и молчуны. Те, кто оставляет вам отзывы — активисты. Те кто не оставляет — молчуны. И те и другие имеют свое мнение, но только активисты выражают его.

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

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

3. Гики и нормальные люди. Гики — продвинутые, технологически образованные пользователи. Гики заправляют общественным мнением в интернете и важны хотя бы поэтому. Они осведомленные и могут выбирать из многих продуктов. Они требовательны. Они знают, какой продукт им нужен. Если они к вам пришли, им уже можно ничего не рассказывать. Если собрать все гиковские компании в нашей стране, то этот сектор не слишком богатый, хотя и составляет ядро пользователей «Мегаплана».

Обыватели не разбираются в интернете. Они пользуются устаревшими инструментами и методами. Они не знают о конкуренции среди таск-менеджеров. Они не знают, что такое инструмент для совместной работы или CRM. У них нет понятия «дедлайн» и «задача». Они не пишут отзывы, они работают (или делают вид, что работают). Для бизнеса «Мегаплана» это означает, что есть более «жирный» сектор, с которым можно работать и который «молчит».

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

Пожелания

Смотрим в систему сбора отзывов и предложений, на «
Реформал».

Выписываем топ-10 пожеланий, формируем из них
большие блоки:

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

Отдел продаж сообщает, что отзывы платных клиентов говорят об одном и том же — скорость и стабильность работы. Сделайте нам инструмент такой же быстрый и стабильный как «Гугло-почта», и цены вам не будет. Если посмотреть на статистику оттока, то скорость и стабильность — главные причины.

Помечаем:

Скорость — самое важное для тех, кто платит сейчас. И это базовая вещь, которая не зависит от типа пользователя. И это совпадает с нашими ощущениями.
Мобильные приложения — самое важное из функциональности. Не зависит от типа пользователя.
Тесная интеграция с почтой. Не зависит от стиля руководства.
Крутое управление проектами. Мы подумаем, но на первой стадии редизайна отказать.
Крутое управление процессами. Мы подумаем, но на первой стадии редизайна отказать.

Говорит модель продаж

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

Связь органическая. «Сделай сам» сервис стоит дешево, малофункционален, понятен. Клиент сам осваивается и сам покупает.

Корпоративное решение — дорогое, всё умеет, настраивается специалистами, сложное в освоении. Клиент проходит обучение. Клиенту активно продают.

Где же «Мегаплан»?

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

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

Говорит статистика

Статистика — единственный честный отзыв о том, что вы сделали.

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

Идеальный конечный результат

В теории решения изобретательских задач есть полезный инструмент — идеальный конечный результат (ИКР).

Описание идеального решения — задание на редизайн. Если вы — дизайнер интерефейса, то знаете мантру «идеальный интерфейс тот, которого нет, а его функция выполняется».

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

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

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

Метод дизайна шаблонов страниц

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

Метод дизайна шаблонов страниц коротко звучит так:

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

Новый проект всегда начинаю рисовать с бумаги, к компьютеру не притрагиваюсь.
Когда понятен первый концепт, фиксирую в Photoshop.

Девять подходов

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

<br>

Вот с этим макетом только начался наш редизайн:

От дизайна в реальную жизнь

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

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

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

Для того, чтобы создать стартап внутри «Мегаплана» потребовалось:

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

Саша, наш тимлид, в шутку называл нас «КБ». Прижилось.

Дизайнеры в КБ кодят.

Минимальная версия продукта

Читаем как запускать «бережливый» стартап.

Делаем минимальную версию продукта:

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

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

Интерфейс

В процессе разработки дизайн полностью поменялся еще раз. Сейчас «Мегаплан» стал совсем крутой. Я это говорю как человек, которому приходится пользоваться «Бейскемпом» по стороннему проекту и который перепробовал тысячу и один таск-менеджер.

Вот как мы реализовали ключевые идеи в новом «Мегаплане»:

Инбокс

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

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

Удобнее информера функцию входящих выполняет почта. Все классические таск-менеджеры абсолютно оправданно сваливают функцию входящих на почтовый клиент:

Но почта — плохой инбокс, который ничего не умеет:

«Ответьте над этой линией» — это костыль. Из почты нельзя нормально ответить или сделать что-то с задачей. Для этого необходимо перейти из почты в «Мегаплан», потом вернуться в почту — всё это бесконечно долго. Если мы хотим, чтобы «Мегаплан» стал центром работы, нужно изменить этот сценарий.
Почта — это спам. У многих пользователей почта — это и личное и рабочее в одном месте. Мы хотим, чтобы в инбокс не попадало лишнее. Если вы руководитель, вы знаете, о чем я говорю. У боссов есть огромная проблема — миллиард неотвеченных писем. Найти в них рабочее почти невозможно.
Удобство работы с почтой зависит от конкретного почтового клиента. Получается, наши клиенты получают совершенно разный опыт работы. Кто-то уже научился работать в почте как на конвеере, а кто-то свой почтовый клиент в гробу видал. Мы хотим угодить и тем и другим.

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

Inbox Zero

Мы считаем, что можно сделать всю работу из инбокса. Мы хотим сделать инбокс центром «Мегаплана» и реализовать в нем концепцию
inbox zero, когда работа пользователя выстраивается вокруг борьбы с инбоксом. Задача пользователя — опустошить его. Задача «Мегаплана» — помочь пользователю сделать это.

Посмотрите, как можно работать из инбокса:

<br>

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

Модель боковой навигации

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

Признаюсь. Боковая навигация — тренд 2011-2012. Соблазн попробовать её «потому что так делают все остальные» был велик. Чем больше был соблазн, тем больше терзали сомнения. В теории модель боковой навигации побеждала:

Сценарий «прокликивания» задач без смены экранов и хождениям в карточку задачи и обратно в список — главное преимущество. Казалось, что это в два раза быстрее, можно просто заглянуть в задачу и тут же уйти из нее. Экраны стали достаточно широкие, чтобы попытаться уместить и список задач, и карточку задачи. Мы давно хотели уйти от утомительных хождений по структурам и реализовать что-нибудь очень быстрое, без перезагрузки страницы.
Выше описана вся важность «входящих» в новом интерфейсе. Просматривать входящие из списка так же как в современных почтовых клиентах — прекрасная идея.
Ядро «Мегаплана» — задачи. Всё остальное — обвес. Тут я заметил, что мы сможем нагло изменить модели боковой навигации, если вдруг она нас не устроит и для модуля «Задач» сделать классическое представление элементов таблицей. В классическом «Мегаплане» в списке задач есть левый столбец с фильтрами, поэтому всегда можно сделать «классический» дизайн. Таким образом, всегда был запасной выход. Это сильно успокаивало.
Мобильность. Было четкое ощущение, что не должно быть никакой разницы, будет клиент пользоваться приложением в браузере, в телефоне или на планшете. Самый дешевый способ сделать три приложения по цене одного — схожий дизайн и одни технологические рельсы. Кажется, это одна из причин, по которой модель боковой навигации стала столь популярной в наше время.
Модель боковой навигации укладывалась в новый концепт: быстрая навигация, без перезагрузки, экономия на мобильном приложении.

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

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

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

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

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

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

Слои

Боковая навигация на десктопе означает много информации одновременно на экране. Три столбца — предел восприимчивости, поэтому перед нами возникли три проблемы:

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

Обратите внимание, как фокус переходит из списка в карточку

Плоские списки vs Иерархия

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

Исполнитель просматривает свои задачи:

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

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

Мы попытались совместить простоту интерфейса для исполнителя и поддержали сложные сценарии для босса.

Личный список дел и список на контроле

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

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

«Контроль» для задач, которые делают другие:

И список текущих задач, которые «я делаю»:

Бесконечный календарь

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

Быстрое добавление задачи и написание сообщения

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

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

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

Мобильная версия vs мобильные приложения

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

Держать свою команду разработки под iOS и Android — дорого.
Вносить изменения в веб-версию и переносить на iOS и Android — долго.
Полностью доверять работу сторонним фирмам — терять качество.

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

Нативность

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

Чтобы добиться нативности, пришлось:

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

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

Понятность

Мы определились, что делаем продукт не для гиков. Значит, всё должно быть понятно бухгалтеру. Меня бесит тенденция делать иконки без подписи. Я не против, что мы узнаем общепринятые иконки и не всегда нуждаемся в подписях. Но когда в 2012 вышла новая почта на Mac, она меня просто взбесила.

Что это? Почему я на месте старушки не должен путать первые две кнопки? Я смогу привыкнуть. Но первое ощущение, позволительное для Apple, непозволительно для «Мегаплана». Почта — бесплатная, «Мегаплан» должны купить.

А это?

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

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

Мой любимый Evernote. Вторая иконка — вершина человеконенавистничества.

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

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

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

Flat во благо

Начало разработки нового «Мегаплана» совпало с модой на «плоское оформление» интерфейсов. Так как мы делали прототип, то оформление у нас и так было плоское, просто потому что не было времени им заниматься.

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

При увеличении масштаба в четыре раза интерфейс становится еще красивее:

С человеческим лицом

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

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

С любовью к деталям

Новый «Мегаплан» на голову выше конкурентов в кайфности:

Часы, которые ходят

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

«Выбиратор» лучше, чем у Apple

Надо хоть в чем-то стараться быть лучше, чем Apple. Наш «выбиратор» людей — самый кайфный в вебе. Можно стрелками ходить вправо-влево, вверх-вниз и вставлять имена в середину. Нативность 100%.

Аватарки

Аватарки не хотелось делать квадратами, от которых мы немного устали. И круглыми «как у всех» не хотелось. В этой не столько важной детали можно позволить себе каприз:

Хотелось добавить нашему чересчур нативному интерфейсу ламповости. Мне всегда нравилась форма нокиевских икон.

Эксперименты на живых людях

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

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

Как за день провести тест на свои самые большие проблемы:

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

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

Эксперимент на сотрудниках

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

Эксперимент на клиентах

Первым менеджером у клиентов я был сам. Собирал фидбек из первых рук. Так легче приоритизировать задачи для разработки и понимать общий настрой пользователей. Первым клиентам мы давали три месяца работы бесплатно. На первых клиентах мы провели А/Б-тестирование стоимости продукта. Хвала этим отважным людям.

Мониторинг

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

Установили сирену. Сирена включается, когда падает скорость или сыпется куча ошибок с сервера.

Статистика — то, чего обычно не видит дизайнер. В отличие от дизайнера, руководитель продукта понимает, что красота — не главное. Главное — деньги и развитие. Но эта тема отдельной статьи.