Итак, PROFI.RU

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

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

Часть первая. Бизнес модель.

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

Давайте рассмотрим этот процесс подробнее.

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

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

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

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

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

Сегодня профи.ру находится в переходном этапе от традиционной модели с комиссией к автоматизированному аукциону.

Часть вторая. Зонтичный бренд

Еще одной важной особенностью сервиса, которую мы узнали от заказчика, является большое количество различных направлений — вертикалей бизнеса. Платформа PROFI.RU образовалась путем объединения нескольких уже существующих сервисов по поиску репетиторов, спортивных тренеров, врачей и т.д. — образовав тем самым, так называемый, зонтичный бренд.

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

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

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

Часть третья. Legacy

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

Итого

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

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

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

Мини-кейс

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

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

Конечно же ввести геймификацию!
Главная проблема заключается в том, что довольно сложно принимать большое количество одинаковых лекарств постоянно, это просто надоедает. Но можно пойти другим путем и разделить одинаковые лекарства на две группы — 90% оставить как было, а 10% сделать другим цветом и разместить их в самом конце, сказав, что их прием ОБЯЗАТЕЛЕН.

Профит!

Дюжина типов мышления среди дизайнеров

Дюжина типов мышления среди дизайнеров

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

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

Второй тип мышления воспитывает отношение к дизайну, как к деятельности созидательной, результатом которой является трансформация исходной ценности, зачастую формулирование самой проблемы в расширении ценности исходного объекта.
Дизайн как расширение задачи — «Найти вариант написания для вывески “Мы открылись”».
Дизайнер анализирует сотни похожих решений, сочетаний слов, композиций, шрифтов и понимает, что ценность сообщения будет выше если его филологически разработать. Начинает разбираться с функцией слов, смыслом сообщения, желаемым результатом. Возникающей эмоциональной связи. Начинает складывать новые слова в комбинации в рамках 12-15 знаков.

Простые альтернативы с демонстрацией заинтересованности, от самоуверенной радости «А вот и мы!» (10 знаков), до нейтральных «Заходите в гости» (16 знаков, перебор), «Мы вам рады» (11 знаков), до буквальности и констатации выгоды — «Вкусно — здесь!» (13 знаков).

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

Всё и сразу

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

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

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

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

Это, к слову, отличная иллюстрация модели двойного алмаза, о которой я писал ранее https://t.me/bukhtiyar/74 — вначале мы взяли максимально большой охват проблем (стадия дивергентного мышления), а после углубления стали отсекать какие-то части (конвергентное мышление).

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

Глобальная причина одна — увеличить базу мастеров. Но у неё есть два следствия.

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

Второе — смена бизнес модели в сторону автоматизации, путем отказа от администраторов и ввода системы обратного аукциона (подробнее я рассказывал об этом здесь — https://t.me/bukhtiyar/88). Но для корректной работы автоматического режима системы необходимо иметь большое количество пользователей — чем больше мастеров в системе, тем корректнее происходит распределение заказов, формирование цены заявки и т.д. В этом случае правильно построенные пользовательские сценарии, вкупе с быстрой регистрацией, будут способствовать вовлечению и удержанию новых мастеров.

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

Недожали

Сегодня речь пойдет о таинственной формулировке «недожали» или особенности преподавания UI.

Как вы помните, UI не самая моя сильная черта (https://t.me/bukhtiyar/161), поэтому я поделюсь взглядом человека, которому нужен был спасательный круг в этой новой сфере. И судя по отзывам, многие, из пришедших в британку, также ждали прокачки своих скиллов в визуале. Но были ребята и с богатым опытом в полиграфии и иллюстрации — им, безусловно, было легче. Но ни я, ни многие другие не получили должного внимания со стороны преподавателей. Давайте попробуем разобраться почему.

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

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

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

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

Но однажды я все же получил небольшое пояснение этого термина. Одним вечером, после занятий я решил спросить, Сергея, что же делать когда ничего не получается? Он поделился своим опытом — когда ничего не получается можно начать решать проблемы постепенно, брать какую-то одну небольшую часть проекта, например, контролл и доводить его до совершенства. То есть фокусируешься на одном моменте, не отвлекаясь ни на что больше. И… постепенно «дожимаешь» весь проект.

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

На зачете по блоку UI наша команда предоставила три одинаково плохие концепции, и Женя Бондарев посоветовал смешать несколько идей из каждой концепции. На этом его активное участие в обучении закончилось. А мы остались один на один с очень сырым UI, и тут же стали его переделывать. Про мои страдания вы можете почитать в прошлом посте, скажу лишь, что все майские праздники я потратил на погружение в особенности работы над UI. Это время не прошло зря, я открыл для себя много нового и из зачаточных мои навыки стали чуть более крепкими.

Что же по обратной связи — то блок, который вел Женя закончился, и чтобы получать хоть какую-то обратную связь я стал донимать Сергея Гальцева, на что однажды получил комментарий, что он уже не отвечает за блок UI, т.к. со второго семестра является куратором курса. Исторически он вел блок UI, в первом семестре так и было. Но во втором семестре блок UI вел Женя Бондарев, при этом Сергей также продолжал комментировать макеты и принимать активное участие. Но четкого понимания, кто рулит процессом и несет ответственность не было. Я уже молчу про ситуации, когда комментарии разных преподавателей по одному макету противоречили друг другу.

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

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

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

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

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

Переговоры: возможность принять финальное решение

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

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

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

Посмотрите, может быть у вас так же?

Вопрос: расскажи, какими должны быть должностные обязанности менеджера?

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

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

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

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