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