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

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

Итак, с чем вы, вероятно, можете столкнуться:

1. У вас много дизайнеров, ими сложно управлять.
2. Разработчики не понимают как работают дизайнеры, но почему-то выдвигают требования к их внутренним процессам.
3. Менеджмент воспринимает команду дизайна как «чёрный ящик».
4. Дизайнеры жалуются на микроменеджмент. Последнее выражается в прямом назначении задач, сроков, приоритетов и каких-то указаний, мешающих качественно выполнять работу и прочее «Поиграйте шрифтами...»
5. Много команд разработки со своими правилами и особенностями, к которым непонятно как адаптироваться.
6. Регулярно запускается процесс коллективного поиска простых ответов в статьях и лекциях о каких-нибудь дизайн-системах, дизайн-токенах, фасилитаторах, трендах, дизайн-спринтах суперинструментах автоматизации и прочей белиберде, которая якобы поможет решить проблемы, но в сухом остатке отнимает ресурсы и время.
7. Консультанты со стороны активно трудятся над назначением сроков, поиском виноватых и распределяют ваш бюджет между собой.
8. Хождение кругами и конфликты из-за всего вышеперечисленного.

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

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

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

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

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

Займитесь дисциплиной. Без неё будет сложно.

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

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

Далее нужно настроить процесс проверки решений с дизайнером, который дублирует его функции. Это освободит вас от рутинного перебора сотен макетов, а дизайнеру даст напарника, об которого можно подумать и поискать ошибки и несостыковки.

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

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

Теперь можно брать требования разработки и разбираться в природе их возникновения. Мне встречался такой набор:

1. Дизайнера не устраивают технические ограничения, поскольку он не может добиться требуемого результата имеющимися инструментами. Это исправляется привлечением дизайнеров к постановке задачи на ранней стадии.
2. Дизайнер меняет макеты, когда разработчики уже взяли задачу в работу. Похожая ситуация, что и в первом пункте, иногда напрямую с ним связанная. Но в этом случае нужно добавить регулярные встречи на которые дизайнер приносит прототипы и предложения, а разработка задаёт вопросы и разбирает задачу. Также на этих встречах нужно проводить промежуточные демонстрации. Если у вас есть отлаженный процесс создания документации, встройте туда дизайн.
3. Разработчик погружается задачу, разбирается в ней, но не проводит финальную и промежуточную демонстрацию результата. Это приведёт к тому, что на выходе получится не то, что задумывалось. Крайне сложно написать исчерпывающую документацию даже если на это есть время. Очевидные вещи для дизайнера, не всегда очевидны для разработчика в силу того, что последний не обладает такой же насмотренностью и не знает используемых паттернов построения интерфейсов, даже если говорит что знает.
4. Задачу на реализацию интерфейса пишет аналитик, который думает, что он дизайнер. Скажите ему, чтобы он перестал.
5. Кто-то из команды занимается не решением задачи, а самореализацией. Например, разработчик пишет идеальный код, дизайнер делает идеальный дизайн, аналитик или владелец продукта обещают что-то сделать руками вышеперечисленных, забыв с ними это обговорить. Пострадавший тут бизнес, который почему-то за это должен платить. Как это исправлять и так понятно.
6. Бардак. Согласование и обсуждение требований в чатах и по телефону без фиксации. Использование сторонних сервисов и личных облачных хранилищ с документами. Сепаратные переговоры с участниками без фиксации (см. про чаты и телефоны). Прогулы встреч или пренебрежение подготовкой к ним. В таких случаях вопросы исключительно к эффективному менеджменту. Ничего оригинального не нужно, изучите опыт предков.

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

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

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

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

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

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

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

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

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

Манипуляции сознанием начинающих специалистов или специалистов смежных профессий, рассказами о простых решениях, приводят их к плохим привычкам. Таким, например, является скоростной перебор «костылей» и коллективный дизайн. Это, пожалуй, самый распространённый пример непрофессионализма. Когда дизайном занимаются все у кого растут глаза на голове. Дизайнеры жалуются и сокрушаются, вступают в конфликты.

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

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

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

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

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

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

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

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

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

Есть соблазн перейти к использованию наглядных показателей, не погружаясь, скажем так, в глубины. Сейчас это называют дизайном основанным на данных или data driven design. К сожалению, это очередная ловушка или приём для упрощения принятия решения в момент времени.

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

↑ Наверх

2 января, 2023
Пётр Лутов
Дизайн в разработке программного обеспечения