Перестань ходить по кругу: как UX-дизайнеру осознанно выполнять свои задачи

“Я хочу проводить правильные исследования и разрабатывать итеративный дизайн, внедрять инновации, совершенствовать и выпускать действительно отличные продукты, которые устраняют проблемы пользователей, но все, что я делаю, - это штампую каркасы. Ни на что другое никогда не остается времени. ”

Каждому дизайнеру знакомо это чувство. Мы все проходили через это. Вы знаете ситуацию: ужасно недоукомплектованный отдел разработки продуктов, смехотворно оптимистичный план действий, менеджер по продуктам под давлением руководства выпускает функции и, как следствие, дизайнеры штампуют экраны для разработчиков, не имея времени на рассмотрение альтернативных проектов, тестирование с пользователями или даже на размышления. А для исследователей пользователей, возможно, хуже ... время и пространство для исследований открытий? Забудьте об этом!

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

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

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

Мой ответ таков: потому что все являются рабами этих чудовищных близнецов, Метода и Плана.

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

Откажитесь от Agile и всего его уродливого потомства-мутанта. Придите к Zero Sprint с полностью проработанным концептуальным дизайном. Примите определение done.

Неважно, является ли преобладающая философия управления продуктами вашей организации какой-то замаскированной формой waterfall, псевдоверсией Agile — или более конкретно обозначается как Scrum, Канбан и бла-бла. Это всего лишь ярлыки. Для целей этой статьи они не имеют значения. Забудьте о них, они неуместны. Метод заключается в том, как инженеры организуют свои силы и время, необходимые для создания продукта. То же самое касается Jira и иже с ней. Это инженерные инструменты. Перестаньте использовать инженерные инструменты для дизайна. Это просто безумие.

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

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

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

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

Я не призываю вас быть несносными! Это совершенно разумные и конструктивные слова, и когда вы их произнесете, вы, вероятно, будете удивлены тем, с какой готовностью другие люди принимают их правдивость.

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

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

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

В классической среде ‘feature factory’, где ни у кого нет времени думать наперед или проводить какие-либо обдуманные исследования, это также тот момент, когда множество предвзятых представлений и бесполезных предположений о том, что представляет собой продукт и как он работает, также внедряются в решение. Тем не менее, у дизайнера не остается времени на рассмотрение альтернатив, и у дизайнера нет другого выбора, кроме как создавать дизайны экранов, которые просто описывают то, что есть в пользовательских историях, независимо от того, насколько неоптимальным является решение или насколько малую ценность для клиента они создают. Как только вы достигнете этой точки, вы больше не являетесь разработчиком продукта или пользовательского опыта. Мне также было бы сложно описать то, что вы делаете, как дизайн пользовательского интерфейса. Вы просто чья-то каркасная обезьянка.

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

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

В результате задача разработчика sprint zero теперь состоит в том, чтобы рационализировать свой концептуальный дизайн на основе отзывов и создать урезанную версию, которая является первым фрагментом. Я надеюсь, вы понимаете, что это гораздо лучшая отправная позиция, чем пытаться создать весь дизайн с нуля за 8-9 дней.

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

1) Каждый ‘понимает’ видение: Человеческая природа такова, какова она есть, поэтому рассказ о дизайнерских идеях с помощью путешествий пользователей, персонажей и раскадровок никогда не окажет такого воздействия, как по-настоящему привлекательный концептуальный прототип. Когда вы создадите действительно хороший концепт-кар, все узнают, в чем заключается видение. И если вы проделали хорошую работу, они будут в восторге от этого.

2) Разговор о планировании: Поскольку разговор о планировании начинается с того, что все смотрят на концептуальный дизайн, планирование и оценка превращаются в серию дискуссий о том, следует ли принять, адаптировать или изменить дизайн. Короче говоря, концептуальный дизайн формирует и управляет всем обсуждением. Любой отзыв, положительный или отрицательный, является реакцией на концепцию. Каждое альтернативное решение, предлагаемое членом команды, должно быть обосновано ссылкой на прототип (если не это, то почему?). Если руководство и другие внутренние заинтересованные стороны видят концептуальный дизайн и вдохновлены им, то любой компромисс в отношении этого видения должен быть объяснен им.

3) Больше никаких ‘MVP’: Столь ненавистный MVP или Продукт с Минимальной стоимостью обычно это результат компромисса за компромиссом, поскольку время поджимает, а масштабы произвольно сокращаются до тех пор, пока на самом деле не будет создано ничего ценного. Как только кто-нибудь говорит: "это MVP", все ожидания от хорошей работы функции вылетают в трубу. При планировании концептуального дизайна MVP заменяется ’первым фрагментом‘. Это различие может звучать как семантика, но первый фрагмент качественно отличается. Хотя его возможности могут быть аналогично ограничены рамками MVP, благодаря концепт-кару, обеспечивающему видение, все в команде (и, надеюсь, руководство!) Знают, как должно выглядеть полное воплощение видения, и ожидают увидеть его реализованным в последующих выпусках. В отличие от MVP, гораздо более вероятно, что за первым фрагментом последует второй и так далее. Все дело в установлении ожиданий.

4) Меньше дизайнерских тупиков, возникших в первых выпусках: Концепт-кар представляет собой законченный, функционально насыщенный прототип, для создания которого потребовалось бы несколько выпусков. Очевидно, что для любого первого выпуска потребуется массовая доработка в паре. Однако, поскольку это отправная точка, задача создания детального дизайна выпуска 1 должна на 80-90% состоять в удалении элементов из концептуального дизайна! Позже последующие релизы могут развить первый таким образом, чтобы улучшить дизайн, потому что они были предусмотрены и учтены в оригинальном дизайне.В общем-то это не все мысли, которыми я хотел поделиться сегодня, но большая часть. Возможно, в дальнейшем я разовью эту тему еще. А пока приходите ко мне в канал, там еще не много людей, но много хороших дизов которые смогут вас наставить в начале пути. Также скоро буду публиковать вакансии для дизайнеров https://t.me/design_poryadok