Т-образные специалисты

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

Хороший дизайн будет не только в макетах, но и на продукте, если дизайнер будет вовлечен во всю цепочку его производства, – считает Юрий Ветров, автор книги «Паттерны дизайн-менеджмента» и преподаватель одноименного курса в BBE.

С разрешения издательства Альпина PRO, где и вышла книга Юрия, публикуем отрывок из книги о необходимости T-образных специалистов в работе над продуктом.

Почему это важно

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

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

Когда использовать

• Нужно повысить качество продуктов.
• Нужно увеличить скорость запуска продуктов и функций.
• Повысить ответственность дизайнера.
• Дизайн на живом продукте хуже, чем в изначальных макетах.
• Дизайнер не понимает, почему требования приходят в таком виде.

Метод (пошаговая инструкция)

1. Транзакционные издержки.
2. Определить навыки дизайнеров, которые нужны в продуктовой работе.
3. Научиться оценивать нанимаемых дизайнеров.
4. Научиться развивать дизайнеров в команде.

1. Транзакционные издержки

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

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

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

Помимо скорости растет и объем знаний, которыми должен владеть современный специалист. В довесок к этому усложняется суть работы — технологических, интерфейсных и бизнес-аспектов становится все больше, мы с каждым годом решаем все более высокоуровневые задачи и проблемы. Раньше было достаточно изучить и применить десять рекомендации ̆Якоба Нильсена, чтобы уровень дизайна вашего продукта заметно отрывался от конкурентов. Сейчас базовый уровень «интерфейсной гигиены» приобрели почти все и надо заниматься более тонкой работой — вовлечением пользователя, построением кросс-канального взаимодействия, проектированием всей цепочки оказания услуги, сложной поведенческой аналитикой.

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

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

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

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

2. Определить навыки

Для такого специалиста важны три аспекта:

Отношение к делу. Общий подход к работе над продуктом и участию в продуктовой команде. Ориентир — повышенная вовлеченность и ответственность.

Навыки. Узкоспециализированные и общепрофессиональные способности. Требования к их ширине и глубине постоянно растут, нужно соответствовать времени.

Инструментарий. Владение им — возможность выжить в условиях растущих профессиональных требований. Ориентир — автоматизация своей работы.

2.1. Отношение к делу

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

Ответственность за продукт

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

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

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

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

Активное участие

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

Тесная связка дизайнера с менеджером продукта

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

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

Джефф Лаш сравнивает продуктового менеджера с президентом. У него также есть советники по разным аспектам (дизайн, бэкенд, фронтенд, маркетинг и т. п.), которые с помощью ответов на частные вопросы «как должен работать продукт» в определенном аспекте помогают решить главную задачу — «что и для кого должен делать продукт». Интерфейс — это то, с чем работает конечный пользователь, и то, что он зачастую понимает под продуктом (это характерно для потребительских сервисов, а в последнее время все чаще и для внутрикорпоративных систем). Хороший же дизайнер или исследователь много знает о пользователях, и эти знания нужны менеджеру для успешного запуска.

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

Многие компании смотрят шире и говорят о концепции «трехногого стула» — тесной связке дизайна, разработки и менеджмента продукта. Она позволит не только найти сильные решения, с которыми продукт улучшит свои позиции на рынке, но и запустить его. Дизайнер находится на стыке бизнес- и технической роли — он должен понимать, что делать и, главное, как.

Переход к командной модели, парной работе

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

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

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

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

Избавление от артефактов

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

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

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

Системное мышление

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

Профессиональная эрудиция

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

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

Что дает такое отношение к знаниям?

1. Быстрые и глубокие исследования новых рыночных ниш, когда приходит рабочая потребность. У тебя уже есть готовая подборка паттернов, исследований, успехов и провалов — все это дает отличную фору.
2. Быстрая реакция на изменения рынка. Часы Apple Watch и Android Wear только появились, а ты уже пару лет следишь за конкурентами и знаешь, как можно строить взаимодействие с такими устройствами. Это же касается и более прагматичных вещей — новой версии Android, подходов к решению интерфейсных задач в конкретных рыночных нишах.
3. Повышение кредита доверия внутри компании и в отрасли в целом. Ты можешь ответить на многие вопросы гораздо раньше и глубже остальных. А значит, чаще востребован коллегами, которые доверяют тебе как профессионалу.

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

Умение договариваться

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

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

Интеграция

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

Работа над продуктом, а не на работе

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

2.2. Навыки

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

Узкоспециализированные (Hard Skills):

Продуктовое мышление и аналитика

• Понимание предметной области и рынка
• Определение и отслеживание интерфейсных и продуктовых метрик
• Построение и проверка продуктовых гипотез
• Поисковая оптимизация в вебе (SEO) и магазинах прило- жений (ASO)
• Статистика, анализ больших объемов данных

Пользовательские исследования и аналитика

• Понимание и описание пользователей
• Проверка дизайн-решений
• Экспертная оценка

Информационная архитектура и проектирование интерфейсов

• Проектирование структуры и навигации
• Проектирование экранов интерфейса и их интерактивных прототипов
• Проектирование взаимодействия вне интерфейса (сервис-дизайн)
• Описание принципов работы интерфейса и паттернов

Визуальный дизайн

• Базовые навыки: композиция и сетки, типографика, цветоведение
• Иконографика и иллюстрации
• Анимация интерфейса и моушн-дизайн
• Создание гайдлайнов
• Визуализация данных
• Айдентика и брендинг
• Шрифтовой дизайн
• 3D

Редактура

• Микрокопирайтинг
• Публикации и презентации

Фронтенд

• Верстка (HTML, CSS, JavaScript) и анимация интерфейса
• Работа с источниками данных
• Настройка рабочего окружения для тестирования и запуска сервисов
• Формализованное тестирование качества

Общепрофессиональные (Soft Skills):

Ориентация на достижения

• Ответственность
• Качество и соответствие стандартам
• Проактивность
• Амбициозность целей

Коммуникация и командная работа

• Управление переговорами
• Аргументация и работа с возражениями
• Фасилитация
• Управленческая зрелость

Креативное мышление

• Конвергентное и дивергентное мышление (методы)
• Насмотренность

Системное мышление

• Комплексность анализа
• Обоснованность выводов

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

По каждому из наборов я вижу четыре уровня:

1. Осведомленность — понимание того, как работает специалист в этой области. Какие задачи выполняет, каков рабочий процесс и инструментарий, методы и практики, какие особенности и ограничения накладываются на него.
2. Умение — способность решать базовые задачи в области. Доделать не очень важный кусок работ за ведущим специалистом, собрать макет или прототип на основе чужих наработок, внести осмысленные доработки в существующий документ и т. п.
3. Экспертиза — выполнение большинства задач в области знаний. От начала до конца, и зачастую самостоятельно. Способность разобраться в нетипичной ситуации.
4. Лидерство — способность передать экспертизу другим участникам команды. Помощь в обучении и профессиональном росте коллег, развитии инструментария и методов работы, повышении общей дизайн-культуры. Возможность указать на проблемную ситуацию в проекте или процессе и помочь в ее решении.

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

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

2.3. Современные инструменты

Нагрузка и требования по знаниям выглядят устрашающе — без современных инструментов им соответствовать крайне сложно. Они есть — шаблоны, программы, плагины, скрипты и веб-сервисы для автоматизации всего и вся появляются в огромных количествах. Когда-то для проектирования интерфейса приходилось запускать требующие обучения штуки вроде Visio или Omnigraffle. Сейчас любой менеджер может набросать свои идеи в Balsamiq (а многие и в Figma). Конечно, опытный проектировщик будет пользоваться специализированным инструментом, но если нужно просто быстро передать идею, низкий порог входа — то, что нужно. Та же история по многим другим направлениям.

Продуктовое мышление и аналитика

Барьер входа для сервисов вроде Google Analytics всегда был минимальным, но благодаря множеству полезных публикаций (например, от Авинаша Кошика) с их помощью можно получать данные поинтереснее простого показателя отказов. Самостоятельно запускать A/B-тесты в рабочем окружении сложного сервиса вряд ли получится, но провести их на небольшом или личном проекте — раз плюнуть с помощью Optimizely или подобного инструмента.

Пользовательские исследования и аналитика

Есть десятки инструментов для проведения опросов и удаленного юзабилити-тестирования, которые предоставляют еще и базу пользователей — UserZoom, Usabilla, UserTesting, SurveyMonkey и множество других, более-менее популярных. Они полноценно доступны не для всех рынков (локализация есть у интерфейса, но не у базы респондентов), но и с этими оговорками очень выручают.

Информационная архитектура и проектирование интерфейсов

Наконец-то есть специализированные инструменты для создания карт сайта, а Customer Journey Map предлагает сделать каждый второй продукт, не считая специализированных.

Визуальный дизайн

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

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

Редактура

Эта часть, наверное, меньше всего развивается за счет новых инструментов. Но полезных материалов более чем достаточно. Да и ChatGPT обещает интересные возможности.

Фронтенд

Хватает обучающих материалов по HTML, CSS и JavaScript, есть пошаговые памятки по React и другим популярным фреймворкам. А Мэн То и вовсе старается написать инструкцию для любого более-менее популярного средства разработки интерфейсов. Это огромное подспорье при работе над дизайн-системой.

Если первая версия сайта уже сверстана, часто проще вносить доработки в нее прямо в коде — спасибо вещам вроде code inspector в Chrome. Многие дизайнеры и вовсе собирают проекты на фреймворках Bootstrap или Foundation. Ко всему этому полно готовых JavaScript-библиотек и CSS-решений на GitHub и CodePen — можно с легкостью вставить интересные анимации и взаимодействия.

Делать одностраничники, лонгриды и хорошие дизайнерские статьи стало проще и дешевле — Webflow, Readymag и другие сервисы выдают в вебе недорогой, но эффектно сверстанный адаптивный результат. Когда-то достижением был WordPress, но мы сильно ушли вперед.

Сделай сам

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

В общем, полный DIY. Не нужно мечтать: «вот была бы у меня команда разработчиков» — многое делается своими руками. Идея о визуальном программировании, давно манящая передовых специалистов вроде Брета Виктора, все ближе к реальности. Нужно выйти за границы рисования макетов и снять с себя часть рутины, чтобы посвятить свободное время развитию и другим интересным вещам. Автоматизация своего рабочего процесса с тем, чтобы делать больше меньшими усилиями, — вот ориентир для современного дизайнера.

Брет Виктор: «...эти прекрасные дизайнеры не могут делать реальные вещи. Они могут только предлагать. Они нарисуют макеты в Photoshop... но они не смогут выпустить ничего, что работало бы само по себе. Вместо этого они полагаются на разработчиков, которые транслируют их идеи в строки кода. Даже в Apple, у этих “аристократов дизайна”, которых вы больше нигде не найдете, всегда было скрытое ощущение беспомощности, а также застенчивости и нерешительности, которые исходят от невозможности положиться на себя. Сейчас модно оправдывать эту беспомощность разговорами о “комплементарных наборах навыков” и прочей болтовней.

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

3. Научиться оценивать нанимаемых дизайнеров

При найме дизайнеров важно понимать баланс между навыками Т-образного специалиста. У каждого будут свои сильные и слабые стороны, поэтому нужно искать правильный баланс для текущих задач компании и команды (подробно этот аспект описан в другой главе книги, «Найм», – прим. редактора).

4. Научиться развивать дизайнеров в команде

Чтобы баланс между навыками Т-образного специалиста был оптимальным, их нужно развивать (а этот аспект – в другой главе книги, «Развитие дизайнеров», – прим. редактора).

Полезные советы

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

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

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

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

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

Примеры других компаний

Сейчас говорят уже о μ-, ς-, π- и [подставьте любую букву]-образных моде- лях, но принцип тот же—нужна связка дизайнеров, сильных в разных навыках.

Домашнее задание

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

→ Подробнее о книги Юрия Ветрова читайте на сайте Альпина PRO и присоединяйтесь к курсам «Паттерны дизайн-менеджмента» и «Копилот цифрового брендинга», которые Юра ведет в нашей школе!