Читаю много каналов умных людей, и вот натолкнулся на идею, что первый прототип дизайнер должен делать не в Фигме и не в Акшуре, и даже не на бумаге.
А в тикете своего таск-трекера. Текстом. Просто внятно описав словами решение задачи (можно под диктовку владельца продукта). Эврика!
В чем сейчас я вижу проблему, так это в количестве итераций. Даже после проведенных кастдевов, даже после накаляканого вашими менеджерами прототипа из серых квадратиков. Даже после декомпозированной и заведенной в Трелло задачи. Всё равно финализированный чистый дизайн делается и переделывается.
Раньше я думал, что спасают компоненты. Ну мол аргумент «нет в нашей дизайн-системе таких компонент» – это прямо аргумент. Кому как. Оказывается, многие топ-менеджеры свято убеждены в том, что релиз каждой фичи (а лучше вообще каждый спринт) – просто обязаны содержать в себе и апдейты всей дизайн-системы. Иначе, мол, становится скучно жить и вообще «Ну не отлита же она в граните. Как сделали, так и переделаем».
Короче: из первоначальных серых кубиков дизайн долго и мучительно воплощается в нечто достойное. Хотя и задача вроде описана, и синхронизации по переговоркам раз в день строго. Но бежим медленно, тратим много сил и калорий на абстрактные споры еще задолго до релиза и первого, хоть плохонького, но реального А/Б тестика.
А потому, что дизайн – не математика. И тут не может быть единственно правильного ответа, скорее всегда выбор лучшего из зол (если под злом считать в принципе любой видимый элемент интерфейса, ибо по канону Г.С. Альтшуллера идеальный дизайн суть его абсолютное отсутсвие).
И в процессе выбора этого самого оптимального сочетания зла (хотя бы в виде неизбежных на разработку, дизайн, пиар и обучение миллионов пользователей новой фиче) естественно возникают вопросы и предложения.
И тут обычно как говорят:
- Ты, дружище, конечно подходи, спрашивай, не тушуйся, ё-моё. И если я не на встрече, совещании, синхроне, стендапе, презентации, обеде, в соцсетях – я тут же быстренько тебе все поясню. В курилке, например, лови меня...
Но любое пояснение то будет уже пост-фактум, то есть: пусть невнятные, но требования ! – уже описаны и зафиксированы в тикете и менять или оптимизировать их будут Ох как неохотно. Это и понятно: написано ж уже все, чего ломать.
А если спрашивать, пока не написано? Если пустить дизайнера в святая святых – в процесс постановки задач? Если договариваться, что есть наиболее хорошее Зло – на берегу, задолго до прототипирования.
Помните, что в начале было Слово. Это и есть первый прототип и самый лучший дизайн.
Дизайнеры! Попробуйте описать нужную задачу не картинками, а словами прямо сразу, в виде пресс-релиза, описания JTBD или иного формата текста, абсолютно не привязываясь к схемам, рисункам и канвам.
Как это сделать?
Садитесь рядом с владельцем продукта и декомпозируйте, ешьте слона по частям, дробите на подзадачи и формулируйте требования сразу понятными прежде всег овам самим словами. И не оставляющими вопросов и разночтений у вас самих - формулировками. Да, сначала покажется странным что вы сами себе пишете задачу и сами же ее потом выполняете. На самом деле, вы применяете древнейший армейский принцип:
Понял – повтори, а не кивай!
Sad story
Почему это реально важно? Пример: один из стейкхолдеров на встрече вскольз упомянул, что новая фича должна быть похожа на готовую диагностику. Все кивнули, никто из топ-менеджеров не указал это ни в протоколе встречи, ни затем в описании задачи и прототипах.
Прошли дни, затем недели, затем месяцы. бьющий фонтаном креатив извратил итоговую фичу настолько, что по требованиям она не то чтобы перестала походить на Диагностику, так ради нее вообще изобрели 3 новых типа компонентов. Три новых, Карл!
Понятно, что когда внутренний заказчик увидел результат, то первой мыслью было уволить дизайнера. Который НЕ слышал от него задачи, НЕ получал ее, НЕ сидел прототипировал тут же копию диагностики с новыми функциями, даже НЕ конспектировал требования напрямую, а получил их через десятые руки сложной менеджерской иерархии.
Так что в чем виноват дизайнер? А таки и виноват, но ровно в том, что не заставил каждого менеджера первым ставить его в приглашения на любые дизайнерские встречи!
Нейминг
И да, обязательно введите правильную систему нейминга макетов и компонент внутри. Это поможет вам, описывая все словами, сразу называть все вещи правильно, своими уникальными именами. Со временем, когда система нейминга и хорошего текстового описания войдет в привычку, вы вдруг ощутите, что сам макет вам вообще не нужен.
Вот Вася Гордеев, умница, предлагает такой порядок нейминга всего и вся, например. Но вы можете и иначе:
А зачем тогда вообще нужен прототип макет?
Так иногда и правда не нужен:
- Сетка и отступы давно прописаны в дизайн-системе.
- Перечень нужных элементов интерфейса и их порядок тоже описан в нужном формате словами.
- Новые компоненты на ходу не изобретаем.
Бери и верстай, незачем играть в прототипы и макеты лишние пару недель ради одного стандартного модального окна с H1, H3 и mainbutton.active, красота!
Сим победишь выгорание и многочисленные правки!