Опубликовали видео с Alfa Design Meetup #1:

1. Вячеслав Киржаев, Альфа-Банк — AI в руках дизайнера цифровых продуктов: приёмы и техники для повышения эффективности

2. Кирилл Викентьев, Альфа-Банк — Скайнет на страже пользовательских ценностей: как мы используем AI в командах роста

3. Ольга Петроченко, Альфа-Банк — Почему я так придираюсь к вёрстке: на что дизайнеры часто не обращают внимание при вёрстке макетов, и как этого избежать

4. Геннадий Мохов, mos.ru — Чем занят дизайн-директор: фреймворки, подходы и ритуалы при управлении командой любого масштаба

#ai #figma #layout #management

Женя Крупина написала о прокачке нетворкинга в компании через совместный просмотр докладов.

— Потребность в этом появилась после реструктуризации, надо было лучше узнать друг друга, научиться работать вместе, научиться обогащать продукт и друг друга за счёт крутых скилов и уникального опыта отдельных специалистов;
— Хорошо себя показал совместный просмотр докладов на продуктовые темы и около того. Он оказался и вовлекающим, и развивающим, и полезным для работы;
— Наибольшую пользу приносит не сам доклад, а его обсуждение: нажимали на паузу, сразу докручивали, как применить в своём продукте, спорили, смеялись;
— В группе просмотр обучающего контента проходит осознаннее;
— В итоге за 3 месяца провели уже 6 просмотров и не только прокачали нетворкинг, но и применили отдельные находки в работе.

#management

Катя Тюхай рассказала о конфликтах в продуктовой команде.

— Самый распространённый — борьба за ресурс, когда дизайнеров или исследователей мало, а продуктовых команд и задач много. Можно перевести их в формат студии, без привязки к продуктовым командам, или чётко разделить, сколько времени можно тратить на задачи конкретной команды;
— Если дизайнеров достаточно, надо легализовать теневые работы вроде дизайн-ревью, которые часто не учитывают при планировании;
— Руководитель не должен выносить конфликты на уровень команды;
— Конфликты могут возникать из-за культурной разницы. Минимизировать их помогает неформальное общение с коллегами (например, в формате Random Coffee), один день поработать рядом с человеком на его рабочем месте, сессии совместной работы;
— Когда сотрудник хочет, но ещё не готов стать лидом, предложите взять какой-нибудь спецпроект, стать лидером компетенции, составить чеклисты или методички, менторить стажёра;
— У команд противоположные KPI (продавцы хотят быстрее совершать сделки, риск-менеджеры — тщательнее их проверять). Надо встретиться, обменяться цифрами и целями на полгода-год и найти точки соприкосновения. Они есть всегда;
— Нет ресурсов на достижение KPI. Ищите команды со схожими целями и KPI. Например, если занимаетесь дизайн-системой, вовлекайте тех, кто получит от её внедрения максимальный буст;
— Непрозрачные процессы. Создавайте чеклисты, шаблоны задач, автоматизируйте прохождение задачи в Jira, внедряйте синки, например, большие горизонтальные демо раз в одну-две недели.

#management

Артур Валиуллин написал о дизайнерских синках.

— Ежедневные синки помогают синхронизировать команду, следить за качеством, растить дизайнеров и чаще проводить ревью;
— Обратная связь, взгляд со стороны нужны постоянно, а не только тогда, когда их попросили;
— Синки оперативнее канбан-доски показывают сдвигающиеся сроки и ситуации, когда продакт решил изменить ранее согласованный сценарий;
— Все знают, над чем работают коллеги;
— Дизайнеры учатся друг у друга;
— Виден текущий уровень дизайнеров: кто готов переходить на новый грейд, обучать новичков, кому не хватает компетенций;
— Достаточно одного часа, если в команде 7–10 человек;
— Если недельные спринты с началом в понедельник, проверять статусы задач можно во вторник и четверг;
— Это скорее групповой менторинг, когда команда помогает находить решения;
— Не все активно вовлекаются. Точечно спрашивайте мнения тех, кто не участвует;
— Вопрос «Если ли вопросы или темы для обсуждения?» в конце формирует доверие в команде. Плюс иногда вопросы появляются;
— Придумывайте ритуалы, например, в понедельник спросить «Как ваши выходные?».

#management

Никита Самутин написал, как тимлиду справиться с потоком дел и повысить свою ценность в компании.

— Бронируйте в своём календаре время для планирования дня, работы над текущими задачами, обеда, ответов на вопросы. Добавляйте не конкретные задачи, а фокусы — группы задач, на которых надо фокусироваться;
— Если поступил срочный вопрос, оцените его неотложность. Лучше накопить вопросы и ответить на все в конце дня в запланированный для этого временной слот. Либо сразу запланировать встречу, если тема объёмная;
— На встречах ведите заметки, так вы лучше всё запомните и повысите свою значимость. Тимлиду важно держать обещания, помнить о правках и вопросах, чтобы команда ему доверяла, поэтому фиксируйте всё, что должно быть сделано: правки, новые задачи, встречи;
— Не стесняйтесь попросить о паузе, чтобы записать важный комментарий. Если информации много (идёт погружение в новый продукт или процесс, по которому нет документации), записывайте встречи на аудио и видео;
— Со временем аргументы по принятым решениям забываются. Чтобы не уходить потом на новый круг обсуждения, в макеты или задачу добавляйте комментарии по неочевидным решениям, скриншоты обсуждений, ссылки на ветки в Слаке;
— Записывайте все сделанные задачи и полученные результаты. В идеале, в виде изменившихся метрик. Это поможет рассказать о сделанном во время регулярной оценки сотрудников и в портфолио;
— Если компания большая, спросите других лидов, какие лайфхаки используют они.

#management

Маргарита Романова написала об управлении доступом к платным возможностям Фигмы.

— Проблема: непонятно, откуда в пространстве появляются редакторы, за которых надо доплачивать сверх плана;
— Команда в Фигме — общее пространство, где хранятся проекты с файлами;
— На тарифе выше Professional появляется сущность «Организация», которая может включать несколько команд;
— У Фигмы есть Design seat и DevMode seat, к каждому может быть доступ Full (платный), Viewer и Viewer-restricted (бесплатные);
— Причина проблемы: в отличие от Viewer-restricted, пользователь с доступом Viewer может самостоятельно переключиться на Full;
— Это происходит, например, когда он переносит файл из черновиков в пространство команды, создаёт файл в проекте, редактирует файл, которым поделились с доступом «Can edit» (на плане Professional, Organization), нажимает на «Edit file» (на плане Enterprise);
— Запретить это можно, установив Viewer-restricted каждому пользователю с доступом Viewer. Можно сделать его доступом по умолчанию для всех новых пользователей (настройка Default seat type);
— Если у пользователя Full seat в 2 разных командах, которые не в одной организации, за доступ заплатит каждая команда;
— На месячном тарифе (на плане Professional), оплата списывается только за пользователей, у которых Full seat на день оплаты;
— На годовом можно выдавать Full seat в пределах количества, выбранного при подписке. Раз в месяц (в число, когда происходит годовая оплата) Фигма проверяет количество Full seats и выставляет счёт, если это количество превышено;
— Добавить мест в годовую подписку можно в любой момент (оплата спишется в конце года), убавить — за 2 недели до годовой оплаты;
— На планах Organization и Enterprise Фигма раз в квартал проверяет количество Full seats. Если есть превышение, в течение 2 недель можно подтвердить добавление этих мест в подписку (с оплатой в конце года), перевести часть на бесплатные места или ничего не делать, тогда дополнительные места добавятся автоматически;
— Можно настроить ежедневный Seat upgrade digests и узнавать обо всех повышениях доступа до Full с комментарием, превышают ли они ваш план.

#figma #management

Александр Букин написал, с чем сталкивается дизайнер, которого повысили до лида.

— Лидерство — руководство отделом из нескольких человек;
— Сообщите подчинённым о своей новой роли. Хороший тон, если это сделает ваш руководитель в чате или на встрече;
— Кредит доверия вам в роли управленца в начале будет нулевым;
— Надо делом доказать команде, что вы на их стороне, а руководству, что команда действует в интересах бизнеса;
— Вежливое, конструктивное и уважительное отношение — залог доверительной коммуникации на старте и потом;
— Лучшее подтверждение навыков — ваши дизайн-решения. Делайте и показывайте отдельные задачи (не большие, на них не будет времени);
— Если в компании нет карты компетенций и регламентированного пути развития дизайнера, связанного с рыночными зарплатными вилками, займитесь этим;
— Кроме этого становитесь связующим звеном между бизнесом и дизайном (абстрактные хотелки → цели и задачи с метриками), улучшайте процессы, получайте бонусы для отдела;
— Чтобы вы завоевали доверие руководства, команда должна выдавать стабильный результат. Вашим результатом становится результат команды;
— В начале будет тяжело, адаптация может занять до шести месяцев. Чаще всего никто не станет объяснять, что делать;
— Смиритесь с тем, что не будете успевать всё. Используйте ICE для приоритизации дел. Делегируйте и примите, что результат будет отличаться от того, чего вы ожидали (это не значит, что он будет плохим);
— Планируйте квартал, месяц, спринт, неделю и день. Разметьте календарь повторяющимися встречами (планирование, груминги, один на один и прочее);
— Если раньше 70% времени вы занимались макетами и 30% коммуникациями, теперь будет наоборот. Постарайтесь поскорее доделать или передать задачи, где вы работаете с макетами. Познакомьтесь и наладьте связь со всеми, с кем будете взаимодействовать;
— В таск-трекере создайте доску для задач команды;
— Подумайте о процессе ревью макетов и перераспределении его на синьоров (чтобы не замыкать на себе);
— Вы будете улаживать конфликты, синхронизировать задачи, цели и файлы в Фигме для наиболее эффективной работы всего департамента и бизнеса в целом;
— Вопросы по дизайн-решениям вашей команды будут задавать не только авторам, но и вам как прямому руководителю. Будьте в курсе (как минимум, у кого что в работе и каков прогресс).

#management

Таня Юдина написала о найме дизайнеров с точки зрения нанимающего лида. Получились советы и соискателям и нанимающим:

— Проще всего находить дизайнеров по рекомендациям коллег. С хорошим отзывом можно попасть на собеседование без резюме и портфолио;
— Если в компании постоянно ищут дизайнеров и проводят собеседования, на поиск дизайнера (middle+, senior) стоит закладывать от 1,5 месяцев;
— На рынке не так много опытных дизайнеров, которые активно ищут работу;
— У новичков тоже есть шансы. Важны софт-скилы (комфортность общения, умение слушать и задавать вопросы), мотивация попасть именно сюда, подход к решению задач (можно показать в презентации тестового);
— Фото соискателя в отклике помогает запомнить его и представить, с кем предстоит общаться;
— Кастомизируйте сопроводительное: объясните, почему хотите работать именно здесь, выделите релевантный опыт, кейсы и навыки;
— Узнать об опыте и знании продуктового процесса помогают вопросы соискателю: как был построен рабочий процесс, какими были задачи и команда, как взаимодействовали с продактами и разработчиками, какие использовали метрики успеха;
— Презентация кейса в Фигме помогает оценить вкус и подтвердить навыки, умение проектировать и работать с дизайн-системой. С сильным кейсом можно обойтись без тестового;
— Вопрос, чтобы понять, как кандидат решает сложные задачи: «Надо продать миллион страховок кредитных карт. Продакт хочет подключать их автоматически, а кнопку отключения запрятать. Что будете делать?»;
— Вопросы соискателя говорят о его мотивации и вовлечённости;
— Примеры вопросов: от кого приходят задачи и в каком виде, роль дизайнера в продуктовой команде, как устроен продуктовый процесс и из каких этапов состоит, насколько развита дизайн-система, как организовано дизайн-сообщество и какие в нём команды, возможности для развития в компании;
— Встреча в офисе позволяет показать атмосферу, познакомить с будущими коллегами и иногда склонить соискателя с несколькими офферами;
— Сделав оффер, не теряйте связь, так как вы можете быть не единственными. Начинайте подготовку к выходу: познакомьте с наставником, расскажите об онбординге, предоставьте материалы для изучения;
— В случае отказа давайте полезную обратную связь, чтобы у соискателя была мотивация прийти потом снова.

Копия статьи. #career #management

Маргарита Романова написала, что с 11 марта изменится в тарифах Фигмы.

— Вместо Design seat, DevMode seat и FigJam seat с разными уровнями доступа будет 4 роли;
— Full seat — редактирование Figma (c Dev Mode), FigJam, Figma Slides;
— Dev seat — редактирование FigJam, Figma Slides, просмотр Figma (c Dev Mode);
— Collab seat — как Dev seat, но без Dev Mode;
— View seat — просмотр всего, но без Dev Mode;
— Design seat станет Full seat и подорожает: $20 в месяц или $192 в год, $55 в месяц для плана Organization;
— FigJam seat → Collab seat;
— Dev Mode seat → Dev seat и станет доступен на плане Professional;
— Для каждой роли можно настроить режим выдачи доступа: а) ручной, б) автоматический, если оплаченных мест хватает, в) автоматический;
— Если у пользователя есть права Edit в файле или проекте, он может запросить платную роль и без апрува ей пользоваться 3 дня;
— Даже если сразу отозвать случайно выданный доступ сверх оплаченных мест, он попадёт в счёт.

#figma #management

Ваня Соловьёв написал, к чему готовиться дизайнерам, ставшим лидами.

— Часто ими становятся дизайнеры, прекрасно справляющиеся со своими обязанностями. Но управление — совсем другая компетенция;
— Учитесь у менеджеров, читайте книги о менеджменте;
— Бизнесу не важно, как вы выстроите процесс, важно, чтобы команда достигала бизнес-целей;
— Чтобы определиться со стилем управления, прочитайте книгу Ольги Лукиной «Бизнес и/или свобода»;
— «Надзиратель» помогает получить быстрые результаты, но подавляет творческую свободу;
— «Яблочное дерево» подразумевает создание условий для развития дизайнеров. Принципы: самостоятельность важнее контроля (возможность совершить ошибку), аргументы выше авторитета;
— При делегировании важно не убить инициативу, передавая только мелкие или скучные задачи, и не оставлять совсем без контроля, чтобы сохранить качество и выдержать дедлайн;
— И придётся научиться конкретно и достаточно детализировано формулировать задачи;
— Детализация зависит от уровня специалиста. Джунам нужны чёткие инструкции, мидлам достаточно видения решения проблемы, синьорам можно лишь задать ориентиры;
— Попросите дизайнера кратко изложить своё понимание задачи, чтобы избежать недоразумений;
— Критикуйте приватно, хвалите публично;
— Микроменеджмент указывает на то, что что-то пошло не так. Возможно, задача не соответствует уровню дизайнера. Но он допустим в период адаптации;
— Фасилитируйте встречи: придерживайтесь темы встречи, давайте высказаться всем, фиксируйте, что обсуждали и о чём договорились;
— Анализируйте свой опыт и извлекайте уроки из ошибок.

#management

Илона Арзуманян написала об онбординге новичков в команду.

— Онбординг нужен, чтобы погрузить во все аспекты работы как можно быстрее и не взорвать его мозг;
— Один документ, где всё описано, лучше отдельных ссылок в мессенджере или проговаривания большого объёма информации;
— Включите в него, что нужно сделать в первые дни: ссылки на программы, инструкции по настройке и получению доступов;
— Соберите ссылки на полезные материалы: редполитика, брендбук, гайды по проведению исследований, работе с дизайн-системой;
— Навигация по проектам поможет найти макет или сценарий, когда сотрудник ещё плохо знает принципы хранения макетов;
— Важно донести структуру компании: кто чем занимается в разных командах, к кому с какими вопросами обращаться;
— В каждой компании есть особенности взаимодействия между отделами. Опишите процесс работы от планирования до релиза. По каждому этапу укажите нужные ссылки, файлы, контакты коллег;
— Подробнее опишите этапы работы именно дизайнера: работа в таск-менеджере, получение (обсуждение и уточнение) задачи, исследование и анализ, работа с библиотекой паттернов, графикой, текстом, исследованиями и дизайн-системой, ревью с дизайн-командой, лидом, продактом и бизнес-заказчиками, ревью на соответствие дизайн-системе, передача макетов и дизайн-ревью;
— Также полезно донести, что вы ожидаете от сотрудника в ближайшие 3 месяца, но это больше относится к процессу прохождения испытательного срока.

#management

Геннадий Мохов написал о регламентах в работе дизайн-команды.

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

#management

Никита Самутин и Елизавета Демченко провели исследование рынка продуктового дизайна и поделились выводами.

— 33% дизайнеров утверждают, что встречи и переписки мешают сосредоточиться. Это не зависит от размера компании. Проблема не в коммуникации как таковой, а в её хаотичности;
— Задавайте правила общения. Даже простое «Если комментарий неясен — обсуждаем голосом» сделает процесс понятнее и снизит напряжение;
— Дизайнерам сложнее общаться не с разработчиками (как многие считают), а со стейкхолдерами и маркетингом. Для взаимодействия с разработчиками есть отлаженные ритуалы, помогающие налаживать контакт;
— Дизайнеры реже чувствуют перегрузку в больших командах, возможно, потому что у них чаще встречаются понятные процессы, чёткое разделение ролей и поддерживающая инфраструктура;
— 58% опрошенных не видят возможностей для карьерного роста. 81% называют нехватку обратной связи от руководства одним из главных препятствий для роста;
— Проводите сессии обратной связи, разрабатывайте понятные карьерные треки (включая горизонтальный, экспертный рост) и вовлекайте дизайнеров в работу над задачами, связанными с бизнес-целями;
— Главные причины выгорания: нереалистичные дедлайны, размытые ожидания и зоны ответственности, конфликты. Йога и психолог помогают справляться со стрессом, а не бороться с его причинами;
— Руководителям следует инвестировать в прозрачное планирование и адекватную оценку сроков;
— Вместо общих курсов по дизайну есть запрос на специализированные и глубокие форматы: разборы реальных задач, рабочих процессов, фидбек;
— 77% не видят в ИИ прямой угрозы для своей карьеры. При этом 49% ощутили его влияние и активно внедряют в процессы;
— Поиск работы стал дольше, но в России он занимает не так много времени, возможно, из-за более коротких процессов найма;
— Только 9% дизайнеров считают, что при поиске работы получили обратную связь в достаточном объёме. Недостаточная обратная связь или её отсутствие ухудшают мнение соискателей о работодателе.

#management

Александр Горчаков поделил команды на 4 типа по уровню стабильности и вызовов и написал, что делать лидерам таких команд.

— Процветают команды (1-й тип) с высоким уровнем стабильности и вызовов;
— Стабильность дают процессы, инструменты для решения задач (принципы, политики, гайды), прозрачное планирование, понятные механики развития команды и влияния на компанию (и внешний мир), разделяемая командой культура взаимодействия, а также лидер, выполняющий обязательства и отстаивающий интересы команды;
— Чем больше стабильности, тем больше команда уверена в завтрашнем дне и тем больше сил тратит именно на задачи;
— Нужна правильная оценка зрелости команды. Performance review повышает стабильность. Но его рано добавлять в стартапе на 5 человек без понятной бизнес-модели;
— Важен баланс. Без должного уровня вызовов стабильность приводит к бюрократии и скуке (2-й тип);
— Вызовы выводят из зоны комфорта, позволяют прокачаться;
— Чтобы избежать скуки при высоком уровне стабильности задача лидера — создавать вызовы и условия для их появления, объяснять их пользу команде;
— Вызовы: сложная задача, новая роль, компетенция или зона ответственности дизайнера, амбициозная цель, усложнённый режим работы;
— Например, задачу по добавлению столбца в таблицу можно предложить сделать с помощью специального компонента. Он позволит быстро делать подобное в будущем, а дизайнер прокачается в сборке компонентов;
— Вызовы без контроля и низкий уровень стабильности приводят к выгоранию (3-й тип);
— В этом случае можно начать с малого: начать планировать задачи, бронировать время дизайнеров на неделю вперёд, разделить людей по компетенциям, начать отстаивать интересы команды;
— В случае стагнации (4-й тип, низкий уровень стабильности и вызовов) кроме перечисленного выше надо ещё продать команде и бизнесу идею дополнительной работы.

#management

Амиран Карацев написал, что делать, чтобы работники-зумеры не уходили из вашей команды.

— В основном молодые специалисты сейчас — зумеры. Принято считать, что они не хотят работать. Проблема в том, что именно они (зачастую впервые в жизни) сталкиваются с сильно просевшим за последние годы управленческим дизайном;
— Они стремятся к гибкости (удалённый и гибридный формат, большая автономия, фриланс) и благополучию (снижение стресса, забота о себе, работа на себя, а не мерседес для акционера);
— Их лояльность работодателю не безусловна, а зависит от среды: отношения в команде, соблюдение личных границ, возможность развиваться, забота со стороны компании, ясность ожиданий;
— Универсалии труда — понятные цели, забота и развитие — важны всем независимо от возраста и системно провалены. Процессы надо адаптировать под контекст компании, а не просто брать «из мемов» (пример с адаптацией дизайн-ревью);
— Решение проблемы с онбордингом: список ролей в компании, шаблоны артефактов, чеклисты, чтобы понимать, как выглядит хороший результат, фидбек через 30, 60 и 90 дней испытательного срока;
— Метрики: Time-to-Value новичка, NPS онбординга, доля задач без эскалаций до руководителя за 30, 60, 90 дней;
— Ритуалы, которые не улучшают координацию или качество решений, надо отменять или проводить асинхронно (как повысить эффективность встреч). Иначе они превращаются в прокси-контроль, вызывают усталость и недоверие процессам;
— Метрики: доля снятых блокеров за спринт, удовлетворённость митингами, MTTR по инцидентам;
— Возврат в офисы снижает гибкость, повышает стресс. Решение: решать в офисе сложные синхронные задачи, проводить плановые парные ревью, живые разборы и сессии наставничества, когда присутствие = рост;
— Конструируйте гибрид: автономия в обмен на прозрачные требования к результатам и времени реакции в каналах связи;
— Если работодатель делегирует результат вместо задач, важна ясность ожиданий и доступность ресурсов. Тогда будет расти ответственность и скорость. Если этого нет, появляется микроменеджмент и выгорание;
— Для повышения ясности опишите дерево ценности: бизнес-метрика → результат работы команды → задачи и критерии их хорошего выполнения;
— Нормируйте нагрузку и убирайте скрытую работу, на 1:1 спрашивайте о нагрузке, достаточности ресурсов, рисках и как сотрудник себя чувствует;
— Обеспечивайте доступ к поддержке ментального здоровья, снижайте стигматизацию через явные политики и обучение лидеров;
— Учитывайте рыночные ожидания по гибкости и льготам, чтобы не терять их просто потому, что конкуренты предлагают ×2.

#management

Александр Букин написал, как упростить поиск актуальных макетов и ответственных за них в большом продукте.

— Иногда работа дизайнера связана с экранами, за которые отвечает другая команда. К кому обратиться за актуальными макетами?
— Создали схему структуры департамента дизайна и исследований (меняется реже структуры продуктовых команд);
— Для каждого дизайнера показаны главные экраны фич, за которые он отвечает (для визуального ориентира), добавлены ссылки на макеты и даты скринов;
— Иногда дизайнеры переходят между командами, и тогда на схеме можно найти их лидов или руководителей направления, чтобы уточнить авторство и актуальность макетов;
— Если за экран отвечает несколько команд, на нём выделяют зоны ответственности разных дизайнеров;
— С ростом карты добавили оглавление со списком ссылок на самые популярные экраны: главный, каталог, корзина, чекаут и несколько других;
— Когда кто-то из дизайнеров переходит из команды в команду или меняет зону ответственности, лид сообщает оунеру карты, который правит схему. (Лид может и сам внести правки.)

#management

Артемий Талалуев написал о повышении эффективности работы продуктовых дизайнеров.

— Когда обратить внимание на эффективность дизайнера?
— Тот использует устаревшие подходы и инструменты;
— Демонстрирует низкую дисциплину и самоорганизацию: опоздания, несоблюдение дедлайнов, отсутствие планов на день, неделю или месяц, хаос в макетах;
— С трудом объясняет решения и коммуницирует с командой;
— Нет инициативы: не предлагает улучшений, слабо участвует в обсуждениях, перекладывает задачи на других;
— После проверки лидом его макеты постоянно требуют доработки, часть комментариев теряется, решения не соответствуют требованиям или предоставляются не полностью, не продуманы пограничные случаи;
— 2–3 месяца работы дизайнера не привели к заметному улучшению метрик или UX-показателей. Значит, он не стремится решать пользовательские проблемы, выжидает, берёт минорные задачи;
— Лид должен фиксировать примеры перечисленного. Когда станет ясно, что это не разовые ошибки, следует встретиться с дизайнером;
— На встрече: обозначьте зону ответственности и ожидания от работы, KPI или OKR, критерии качества работы и покажите, где дизайнер не соответствует;
— Можно запустить Performance Improvement Plan (PIP): зафиксировать проблемы и измеримые критерии их исправления, дать от 2 до 6 недель на это;
— Например, критерий при проблемах с инициативой: «Дизайнер каждый месяц предлагает не менее 4 идей по улучшению продукта»;
— Не оставляйте дизайнера один на один с проблемами. Компания и лид могут помочь, например, предоставить доступы к курсам;
— Неисправление проблем в рамках PIP может быть поводом для увольнения в соответствии с Трудовым кодексом РФ. Для этого по каждому нарушению запрашивайте у дизайнера письменное объяснение;
— PIP можно использовать для развития, а не только как антикризисный инструмент.

#management

Андрей Богданов написал книгу «Дизайн-стройка. Как создать команду мечты за 90 дней», и вот что там было о ревью макетов лидом и другими дизайнерами:

— Созваниваться с дизайнером и вместе пробегаться по макетам оказалось плохой идеей;
— Если макеты оформлены плохо, дизайнер может их пояснить, но всем остальным придётся иметь дело с непонятным артефактом;
— Непроработанные ветки сценариев, корнер-кейсы, используемые компоненты во время беседы выпадают из фокуса внимания;
— Из-за невозможности как следует подумать рекомендации иногда получаются необдуманными;
— В некоторых компаниях встречается кросс-ревью (дизайн-чек в Альфа-Банке), когда макеты смотрит не лид, а другие дизайнеры (в том числе из других команд);
— Эта практика позволяет разгрузить лида и прокачать навыки ревью у дизайнеров;
— Но она не должна замещать ревью дизайн-лида, так как последний отвечает за качество дизайна в своей команде. Без ревью он теряет связь с продуктом и выпадает из контекста;
— Если будете внедрять кросс-ревью, подумайте, как обеспечить ответственный подход ситуативных ревьюеров и разумный контроль со стороны лида.

#design_check #management #book

Опубликован отрывок из книги Юрия Ветрова «Паттерны дизайн-менеджмента», посвящённый Т-образным специалистам.

— У них глубокая экспертиза в ключевых навыках и поверхностная — в широком наборе смежных;
— Если не вовлекаться в формирование требований, могут приходить задачи, которые сложно сделать хорошо;
— При разработке выявляются технические ограничения, мешающие сделать как задумано. При эксплуатации появляется пользовательская обратная связь;
— Сейчас все делают неплохие интерфейсы. Чтобы выделиться, надо прорабатывать вовлечение пользователя, строить кросс-канальное взаимодействие, проектировать всю цепочку оказания услуги;
— Объём нужных знаний ведёт к узкой специализации, что усложняет коммуникацию (каждый создаёт и передаёт дальше свои артефакты), удлиняет производственный цикл, размывает ответственность;
— Это подходит дизайн-студиям и аутсорсерам, которым важна формализация и предсказуемость, так как их клиенты покупают заранее оговоренный результат;
— Но не подходит стартапам (дорого нанимать столько специалистов) и продуктовым компаниям (важна скорость);
— Главный навык продуктового дизайнера — брать на себя ответственность за продукт. Чем именно он поможет команде — вопрос её специфики;
— Лучшие практики и здравый смысл — хорошо, но что если пользователям в конкретном продукте удобно по-другому?
— Важно применять эмпатию и к пользователям, и к коллегам, чтобы принимать дизайн-решения с учётом их болей и задач;
— Дизайнер работает в связке с продактом: помогает формировать продуктовое решение, снабжать продакта знаниями о пользователях, нужными для успешного запуска;
— Собираются ситуативные рабочие группы, где каждый дизайнер силён в своей теме и помогает в ней остальным. Автор дизайна в этом случае — ответственный, кто всё свёл воедино и довёл до результата;
— Лучшая спецификация продукта — работающий продукт. Лучше потратить время на его полировку, чем на эстетичные сопроводительные документы. Артефакты быстро устаревают;
— Важно не просто обрабатывать входящие запросы, а систематизировать наработки, переиспользовать паттерны, автоматизировать часть работы, не пытаться решить все проблемы одним рывком;
— Уровень владения смежными навыками: от осведомлённости (понимание того, как работает специалист в этой области) до умения (способность решать базовые задачи в области, доделывать за специалистом работу, вносить осмысленные правки);
— Есть разница между ролью и специалистом. В разных проектах один специалист может выполнять несколько ролей. Либо одну роль могут закрывать несколько человек;
— Уровни зрелости компании: возникла потребность в Т-образных дизайнерах → часть команды → все дизайнеры Т-образные.

#management #book

Татьяна Бублик поделилась своей системой организации файлов в Фигме.

— Все макеты продукта могут находиться в одном файле;
— Из-за этого он может тормозить и даже перестать открываться, обновления дизайн-системы будут применяться ко всем макетам, даже архивным, команде сложно находить нужные макеты;
— В Фигме есть бранчи, но недоработки этого инструмента и ошибки дизайнеров могут принести больше проблем;
— Заведите папки: для файлов дизайн-системы (сюда можно отнести редполитику и любые вспомогательные материалы), для текущих задач (и шаблонов для новой задачи и мастер-файла), для каждой фичи или микросервиса;
— Макеты по отдельной задаче создаются в отдельном файле, в названии которого есть номер тикета, чтобы легко его находить;
— Появляется такой файл в папке для текущих задач. Дизайнер подключает к нему нужные файлы дизайн-системы;
— При передаче макетов в разработку размещает их на странице For dev;
— После успешного дизайн-ревью и завершения разработки перемещает файл в папку фичи;
— А макеты из файла задачи копирует в мастер-файл фичи, в котором отображаются макеты всех флоу фичи;
— Статусы задачных файлов отличаются от статусов задач в таск-трекере: In progress, Ready for dev, Design review, Freeze, Closed (закрыта, но ещё не перенесена в папку фичи), Archive (перенесена в папку);
— В архивных файлах дизайнер не принимает обновлений ДС, макеты выглядят так, как должны были быть разработаны, что важно разработчикам и тестировщикам;
— Мастер-файлы фич содержат макеты всех флоу, что позволяет команде быстро понимать актуальное состояние фичи;
— Система требует времени для поддержания порядка (час каждого дизайнера в спринт). Плюс команде требуется время, чтобы привыкнуть.

#figma #management