«Ваш репетитор» создали и развивают те же люди, которые создали сервис «Профи». Приложение для репетиторов создаётся на основе существующего аналогичного приложения Профи. Приложение Профи разработано с учётом того, что с сервисом сотрудничают 100500 видов специалистов: от сантехников и репетиторов до врачей и визажистов. Поэтому приложение с одной стороны универсально и подходит всем, а с другой — не учитывает особенностей работы конкретного вида специалистов.
«Ваш репетитор» хочет сделать версию приложения, которая была бы заточена именно под репетиторов. По замыслу клиента, приложение станет важным инструментом для привлечения новых репетиторов. «Ваш репетитор» планирует со временем переделать и подкрутить всё приложение, но это история на несколько итераций.
Нужно решить, что сделать в первой итерации. С чего начать? Что будет наиболее полезным для продукта? У клиента несколько идей: статистика репетитора, баланс, экран заказа и чатики с учениками. Анализируем эти идеи и рассуждаем примерно следующим образом. Во‑первых, ближайшая цель сервиса — перетащить к себе как можно больше репетиторов с Профи. Во‑вторых, исходя из этой цели, в первой итерации лучше взяться за те элементы и разделы, обновление которых позволит начать привлекать новых репетиторов, не дожидаясь переделки всего приложения.
Предлагаем клиенту в первой итерации переделать разделы со статистикой и балансом, а всё остальное отложить на другие итерации. Во‑первых, с выбранными разделами связано большинство вопросов и претензий репетиторов (а значит, их обновление будет для репетиторов хорошим стимулом работать с «Вашим репетитором»). Во‑вторых, их реально обновить, не трогая остальные разделы приложения. В‑третьих, команда разработки готова уложиться в сроки, которые важны для бизнеса.
Клиент соглашается. Пишем понимание задачи, готовим и согласовываем с разработкой план работы.
В приложении Профи раздел со статистикой репетитора выглядит так:
На стадии обсуждения задачи с клиентом договорились сделать раздел более наглядным и мотивирующим, чтобы репетиторы понимали, как их показатели влияют на задержку появления заказов и получение плюшек. Прикидываем:
Ищем стиль плашек с ачивками и графиков:
Арт‑директор вспоминает сервис знакомств «Баду» и предлагает посмотреть, как они агрессивно и изобретательно мотивируют пользователя что‑нибудь сделать.
Примеряем увиденные идеи в наш интерфейс:
Арт‑директор говорит, что синий верх навевает ощущение Госуслуг, и предлагает сделать всё чище, светлее. Эволюция дизайна:
Придумываем, как показывать подсказки в списке заказов:
Ищем форму иконок для отображения плюшек:
Собираем макеты для презентации клиенту:
Клиент принимает подход, но говорит, что нужно показывать соблюдение правил сервиса проще, потому что технически пока бэкенд не умеет отслеживать причины изменения репутации, а делать это долго. Договариваемся пофлексить:
Вместо баллов и детальной истории изменения показателя ставим иконку пальца вверх или пальца вниз, которая показывает, что всё хорошо или плохо, и что надо делать.
Клиент просить поставить ссылки на справку (кружок со знаком вопроса) и добавить возможность для репетиторов получить детальный расчёт изменения показателей.
Прорабатываем разные состояния экрана, придумываем больше сценариев подсказок, рассчитываем и прорисовываем цветовую гамму шкалы для диаграмм показателей:
Принимаемся за экран баланса. Нам необходимо продумать его так, чтобы у репетитора не возникало вопросов: «Куда пропали мои деньги?». А если такой вопрос возникнет, чтобы репетитор мог легко получить на него ответ.
Слишком много плашек и цифр. Ведущий дизайнер предлагает принципиально замочить все плашки и выделить одну главную цифру — баланс, от которого зависит, может ли репетитор брать заказы. Хотим сделать похоже на историю операций в банковских приложениях.
Следим, чтобы придуманные ранее подсказки органично встраивались в экран баланса.
Рисуем напоминание об оплате:
Придумываем, что по нажатию на операцию можно увидеть статус заказа и его историю:
Собираем макеты для презентации клиенту с основными состояниями экрана:
Клиент принимает подход. Принимаемся за проработку состояний интерфейса:
И ещё:
И ещё больше:
Спустя 100500 обсуждений с клиентом и разработчиками, доработок и согласований макеты утверждены. Разработчики пишут спецификацию, а мы принимаемся за иконку приложения и рекламу.
Чтобы приложение увидело свет, ему нужна иконка и оформление для магазинов приложений. Ищем иконку:
Останавливаемся на иконке с силуэтом довольного репетитора:
Клиенту нравится идея показать репетитора, но не нравится графика и идея показывать пол репетитора. Графика просто кажется сложной и шумной. А с полом непонятно, какую иконку показывать в рекламе и на странице приложения: репетитор же ещё не скачал приложение и не зарегистрировался, и мы не знаем его пол, — клиент опасается, что кого‑то иконка с неправильным полом может отпугнуть. Ещё разработчики говорят, что сделать динамическую иконку можно, но они такого раньше не делали и не знают, как много времени это займёт. Возможно, что много, а времени до конца итерации остаётся маловато.
Договариваемся упростить графику, уменьшить количество элементов и сделать так, чтобы по иконке нельзя было определить пол репетитора.
Уходим думать и рисовать. Появляется идея оставить только лицо, а глаза сделать из наклонённой В из логотипа (про логотип ещё расскажем :‑)
Идея хороша, и арт‑директор предлагает связать иконку и логотип ещё сильнее — сделать рот из буквы «Р»:
Спустя три километра переписки и обмена скриншотами с арт‑директором добиваемся нужной формы и градуса дружбы:
Показываем клиенту:
Технически мы сделали всё, о чём договаривались с клиентом, но с новым вариантом возникают переживания, что не все опознают лицо, или что кто‑то решит, что иконка дразнит высунутым языком. К сожалению, времени на рисование ещё одного варианта не остаётся. Договариваемся с клиентом поставить на иконку логотип сервиса, просто на другом фоне. Скучно, но для первого пуска подойдёт:
Параллельно с работой над макетами сопровождаем разработку приложения:
Дизайн был утверждён в срок и частично реализован, когда из‑за организационных изменений на стороне клиента выход приложения был отложен на неопределённое время.