— Отличная работа, Егор! Я вам на почту правочки прислал по прототипу. Взгляните.
У меня от этой фразы что-то внутри ёкнуло. Захожу в почту, к письму прикреплён вордовский документ (на дворе 2009 год). Открываю… 55 комментариев. Пронумерованных. На четыре страницы.
Пробегаюсь по списку. Часть из них вносятся буквально за пять минут. А часть — перечёркивают мою двухнедельную работу.
Я откинулся в кресле, посмотрел в потолок. «Что не так с этим клиентом?». Нет, неправильный вопрос. «Что я делаю не так?». И, главное, как мне не оказываться в таких ситуациях в будущем?
Сегодня, спустя 15 лет, я знаю ответ на эти вопросы. И сейчас попробую уместить в одну статью почти всё необходимое для того, чтобы клиенты, начальники и коллеги принимали результат работы проектировщика (или дизайнера) с первого раза.
Для начала немножко контекста. Меня зовут Егор Камелев, я проектирую интерфейсы с 2006 года. Работал в агентствах, внутри компаний, на аутсорсе. Основал Проекторат. Специализируюсь на сложных информационных системах. До сих пор в деле. Вроде, всё. Теперь поехали!
1. Сначала разговоры — потом работа
— Ни слова больше! Я точно знаю, что вам нужно!
Такого мои клиенты от меня не слышат. А когда-то давно слышали. И очень часто.
Перед проектированием я общался, собирал вводные по проекту и, опираясь на прошлый опыт, внезапно начинал верить, что точно знаю, что именно нужно спроектировать, чтобы клиент остался доволен.
Я прямо светился уверенностью, что результат будет тот, что надо. Уходил на неделю-другую, чтобы сваять прототип, возвращался… И слышал от клиента: «Кхм, это не совсем то, что я себе представлял. Можно кое-что подправить?».
Сегодня такое невозможно. Даже если мне кажется, что я уже точно знаю, чего именно хочет работодатель, я всё равно слушаю его до конца и стараюсь получить как можно больше деталей перед началом работы. Не зная броду — не суйся в воду.
2. Без глоссария с терминами — никак
Для начала нужно убедиться, что все говорят на одном языке.
Для кого-то прототип — это перелинкованные экраны. А для кого-то — минимальная версия готового работающего проекта.
Комплект товаров в интернет-магазине может оказаться отдельным товаром со своей ценой и свойствами под тегом «комплект», а может оказаться парой различных товаров, автоматически объединённых системой.
Управляющий АЗС может оказаться продавцом на кассе, а может — человеком, который сидит в отдельном кабинете и смотрит в монитор. Или и тем, и другим сразу.
В общем, с самого начала работы важно фиксировать все термины, которые могут трактоваться по-разному. В противном случае можно к середине срока понять, что проектировал кабинет администратора сайта, а ЛПР (лицо, принимающее решения) имел в виду администратора магазина. И всё. Переделывать!
3. Сразу готовим исходники к правкам и дополнениям
Тут не требуются дополнительные комментарии, большинство из нас и так пользуются этим правилом. Напомню только основные моменты:
Называем страницы, разделы, элементы осознанно и единообразно;
Если в макетах есть элементы, повторяющиеся больше одного раза — превращаем их в мастера, компоненты и т.п.;
Не приступаем к работе над динамическими и составными элементами, пока не разобрались с их статическими составляющими (например, не надо показывать, как красиво выплывает менюшка до того, как согласовали все её состояния для разных пользователей).
Если исходники сразу не готовятся к правкам — количество трудозатрат на их переподготовку увеличивается лавинообразно. Просыпаются капризность и нежелание этим заниматься. Включается режим чрезмерной защиты всех своих решений, который приводит к разладу в общении.
4. Приступаем пораньше и сразу показываем первые результаты
Есть такой тип работников, которые не готовы показывать промежуточные результаты, т.к. «недоработанный макет может создать неверное впечатление». Но проблема в том, что правки, скорее всего, всё равно будут. И лучше, если это сразу небольшие корректирующие замечания к полуфабрикату, нежели просьба сделать из готовой «утки» «кролика».
Я обычно первым делом показываю проработанное навигационное решение (за очень редкими исключениями). Оно занимает у меня один-два дня работы вне зависимости от сложности проекта. Команда сразу начинает привыкать к быстрой работе короткими итерациями и не успевает вылетать из контекста.
А ещё это позволяет мне, человеку ленивому, не расслабляться и не ждать конца недели, чтобы проделать работу в последний момент. Лучше я её проделаю в последний момент уже перед встречей через два дня.
5. Не показывать объёмных результатов, требующих больше одного подхода для изучения
В истории, с которой начал эту статью, я уселся за 55 правок в тот же день и проработал десять часов кряду. А на следующее утро меня ждало новое письмо с ещё 30 правками. Я тогда подумал, что клиент не дружит с головой и просто решил меня завалить этими комментариями.
И только через несколько лет, когда я сам оказался на его месте, до меня дошло, что он просто физически не мог подготовить всю обратную связь за один присест.
Поэтому, чем короче итерации, — тем лучше. Особенно в начале работы, когда мы только синхронизируемся с клиентом и командой. Долгие подходы и доработки можно оставить на конец, когда все основные вопросы уже будут решены и ожидания сформированы.
6. Сперва проектируем атомарные разделы, которые вряд ли будут правиться, а затем — те, которые из них состоят
Представьте такую структуру экранов. Дэшборд по компаниям в системе, список компаний, карточка компании.
Многие начали бы работу с дэшборда, как с главного экрана. Но дело в том, что дэшборд будет использовать данные из своих подразделов, которые ещё не спроектированы. И поэтому вероятность переделок дэшборда стремится к ста процентам в тот момент, когда мы приступим к его внутренним сущностям.
Правильная последовательность: карточка компании, список компаний (использует информацию из карточки компании), дэшборд (использует информацию из списка компаний и карточки компании).
7. Превращаем субъективную обратную связь в объективную
— Этот раздел выглядит «пустовато».
— Здесь не хватает какого-то онбординга.
— Кнопка слишком мало притягивает к себе внимание.
Услышав подобные комментарии, я не спешу вносить изменения. Нет, изменения, скорее всего, внести всё равно придётся. Но важно не проделать напрасную работу, неправильно поняв автора обратной связи. Задаю уточняющие вопросы, показываю референсы. Идеально, когда можно отрабатывать такую субъективную обратную связь прямо во время переговоров, в режиме расшаренного экрана.
И потом выясняется, что на самом деле не «раздел выглядит пустовато», а «не хватает предзаполненных данных». Что не «онбординг» нужен, а «иконка с всплывающей подсказкой». И что кнопка нормально притягивает к себе внимание, просто должна быть не только в первом экране, но и появляться при скроллинге.
8. Сохраняем промежуточные результаты в отдельных файлах
Часто случалось так, что от того или иного решения приходилось отказываться. Я удалял его из прототипа и двигался дальше. А через месяц клиент вспоминал о нём и заявлял: «Всё-таки тот ваш первоначальный вариант был ничего! Давайте к нему вернёмся!». А возвращаться-то было и не к чему. Приходилось заново делать.
Поэтому теперь каждый раз, когда в проекте что-то удаляется, я сохраняю его под новой версией. Иногда, конечно, можно просто спрятать не пригодившуюся часть в отдельный раздел. Тут уж как кому удобнее. Кто-то писал даже, что можно гит для отслеживания версий использовать. Я же люблю, когда к концу работы прототип называется как-нибудь вроде Project_v12 и можно посмотреть на 12 предыдущих версий в папочке.
В общем, главное, чтобы не пришлось тратить время на воссоздание результатов, которые до этого клиент откинул.
9. Не боимся показывать неудачные рабочие варианты, от которых сами отказались
Иногда во время работы перебираешь несколько потенциальных вариантов интерфейса, останавливаешься на одном, а остальные удаляешь.
Затем показываешь результат со словами: «Вот в итоге такой вариант. Я прикинул ещё три, но они сильно проигрывали». А действительно ли прикинул?
Гораздо выгоднее показать те самые три варианта, даже если они самому кажутся шляпой (или не показывать, если это не к месту, но, главное, чтобы они были). Во-первых, так все увидят, что ты действительно хорошо поработал. Во-вторых, иногда может статься так, что неудачные варианты на деле окажутся не такими уж и плохими.
Такой подход ещё больше повысит шанс на то, что к концу проекта будет не только сделано то, что хотел клиент, но и все увидят, что путь был не линейный и не простой. Это повышает ценность результата и снижает риск правок.
10. Получили 20 комментариев — показали 20 исправлений
Особенно хорошо меня должны понимать те, кто ставят задачи. Человек берёт список из 20 пунктов и приносит обратно 18 исправлений. И вот нет никакого желания похвалить за исправления. Всё внимание сосредоточено на двух невыполненных.
Нет, ничего плохого в том, что человек с чем-то не справился, нет. Если он приходит со словами: «Я сделал 18 правок из 20, а по двум есть дополнительные вопросы, которые предлагаю обсудить».
Но чаще всего человек приходит со словами, что всё сделано, а на вопрос про два невыполненных пункта говорит: «Ой!». И не знаешь — это он невнимательный или хитрый и надеялся на то, что и так прокатит. И ещё неизвестно, что из этих двух вариантов хуже.
Поэтому все комментарии обязательно записываем и нумеруем. Ничего не доверяем крепкой памяти. В противном случае к концу работы, когда уже уверен, что всё готово, внезапно всплывает забытый, но важный для клиента, комментарий, из-за которого нужно переделывать десять разделов.
11. Во время общения с командой не бояться увеличивать их причастность к результату труда
Иногда презентуешь работу и вдруг кто-то даёт комментарий. Например: «О, а нам надо ещё, когда форма отправляется, показать сообщение в модалке, что она успешно отправлена». А у тебя это и так есть в списке дел, ты просто не добрался до этого момента.
И вот можно ответить: «Да, я так и собирался это сделать». И показать, что ты всё продумал и молодец. А автор комментария просто спешит куда-то.
А можно ответить: «О, классная мысль! Поддерживаю обеими руками! Так пользователь поймёт, что всё в порядке, и будет больше доверять нашей системе. Так и сделаем».
И автор комментария внезапно становится причастен к результату моей работы. А значит она ему будет больше нравиться, он будет её больше ценить. А то, что я поддерживаю его идею, сделает для него моё общество более приятным и комфортным. А это способствует уменьшению придирок к финальному результату.
Здесь, правда, оговорюсь. Если по комментарию очевидно, что у комментатора цель — дискредитировать меня, как специалиста, то что мы здесь вообще делаем, а?
12. Иногда надо переделать базовое, фундаментальное решение
А не пытаться спасти его множеством костылей.
Иногда так привязываешься к своему творению, так веришь в то, что оно изначально правильное и достойное, что тратишь слишком много времени на попытки его спасти.
Если я замечаю, что уже больше часа пытаюсь решить проблему с каким-то элементом или разделом, но у меня постоянно возникают конфликтующие сценарии, — я задумываюсь, а правильно ли это дело спроектировано изначально?
Бывает, во время работы появляются новые вводные или дополнительное понимание, с учётом которого необходимо откатываться к самому старту и всё переделывать. И как бы это страшно ни звучало — это всё равно более быстро и эффективно, чем пытаться спасать то, что в корне неверно.
13. В конечном итоге всё равно будет принят вариант, который нравится ЛПРу
Если я не руковожу проектом, не отвечаю за финансовый результат и за сроки. Если я просто проектирую интерфейс, то должен понимать, что финальное решение — не за мной. Да, от меня многое зависит. Мне могут доверять как специалисту. Я могу быть убедительным. За мной могут стоять цифры и факты. Но в конечном итоге ответственность за результат понесёт человек, который платит мне деньги.
И хорошо, когда во время оплаты он чувствует, что получил именно то, что ему нужно.
Как этот пункт связан с правками? Осознавая его суть, будет морально проще с ними работать. Понимание, где нужно настаивать, а где — принять чужой выбор — это тоже часть профессии.
——
Если у вас есть свои методы, как сдавать работу без болота правок — поделитесь в комментариях. Люблю читать чужие приёмы и сравнивать с тем, что у меня сработало.
