Про любовь к делу и выгорание

medium.com/slashdesigner/burnout-cf52c6f0a459

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

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


Тезисно:

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

- Выгорание не зависит от количества денег. Если любишь то, что делаешь, деньги это не главный мотиватор.

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

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

—
Похоже, это редкий пост, который годится и в #первые_шаги, и #для_профи

Справочник всех команд и горячих клавиш Фигмы

Открыть →

Я сделал скриншоты для всех меню Mac и Windows, занёс клавиши в единую базу данных на страницу в Notion и описал на понятном русском языке, что делает каждая команда.

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

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

Мечтаю, чтобы такой справочник был по любой профессиональной программе.

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

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

Не потеряй ссылку. С Новым Годом!

—
#горячие_клавиши  #Notion  #для_профи

Ввожу новую рубрику: #стать_лидом

Этот пост на Медиуме и VK

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


1. Режим дизайнера и режим лида

Для начала поговорим о том, как устроена типичная дизайн-команда в корпорации. Везде, где я работал, существовала одинаковая структура из руководителя и нескольких дизайнеров с разным количеством опыта. В среднем она состоит из 3-5 человек. Моя состоит из 6, включая меня. Для меня это комфортный размер. Если меньше — не полностью реализуется пропускная способность команды, некого вести. Если больше — нереально помогать всем и успевать делать ревью для младших. Я знаю человека, у которого в команде 17 дизайнеров и для меня остаётся абсолютной загадкой, как он справляется.

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

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

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

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

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

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

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

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

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

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

—
#для_профи

Фидбэк продуктовому дизайнеру, который не подошёл на собеседовании

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

Считаю свинством пропадать без решения об отказе. Так часто делали со мной и я всю неделю после собеса сидел как на иголках, что было крайне неприятно. Поэтому, если человек попал ко мне и не подошёл, я считаю хорошей практикой написать хотя бы пару строк «почему нет» и кинуть ссылки, куда копать, чтобы вырасти.

Имя изменено, фидбэк реальный. Посвящается тем, кому отказывали без объяснения причин.

—
Отказ: Средний веб-дизайнер вместо старшего продуктового
Иван Иванов, 35 лет, Москва
Вакансия: Старший дизайнер
Опыт работы: 7+ лет

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

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

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

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

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

4. Есть большие провалы в знании гайдлайнов систем HIG и Material, не знает возможности и отличия систем, названия элементов. Зачем-то кастомит шрифты и объединяет компоненты для iOS и Android, хотя ресурсов у команды на такое упражнение точно нет.

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

6. Другая работа — совсем невнятное приложение по управлению курьерами, непонятно, зачем показывал.

7. Третья работа — по вебу делал цветастый интернет-магазин. Не релевантно.

Видно, что в дизайне давно, какой-то опыт за годы накопился, а правильного нет.

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

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

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

—
#для_профи

Видео-урок про обновлённый Auto Layout. Как верстать таблицы
От Виктора Теплова

https://youtu.be/EmBiYfYFb9k

Не так давно логика работы Auto Layout в Фигме значительно поменялась. Из видео можно узнать о главном нововведении последних месяцев — выравнивании объектов внутри алика. Так Виктор называет фреймы с признаком AL.

Также стало можно настраивать индивидуальные отступы от края фрейма до объектов внутри, что он использовал для вёрстки таблиц. Новый AL позволяет настраивать толщину границ между ячейками и по общему контуру таблицы. Это позволяет через один стандартный мастер-компонент настраивать разные стили таблиц, задавая отступы в 1px и при помощи него формировать границы. Пример: иногда вертикальные линии справа и слева таблицы нужны, а иногда излишни и тогда нужно оставлять только отбивки между строками.

Zen Designer из раза в раз делает так, что снимать видео про функции инструмента на русском языке становится бессмысленным занятием, потому что он уже всё рассказал. Деловито, нескучно, и при этом исчерпывающе.

PS — А ещё Виктор пополнил мою команду и здорово её усилил. Для меня большая честь с ним работать, он крутой специалист и человек.

—
#первые_шаги  #AutoLayout

#стать_лидом №2. Иерархия

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

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

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

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

Управляемость или талант?
Когда тимлид задаётся вопросом, нанимать ли талантливого, но своенравного, либо среднего, но управляемого дизайнера, он уже делает большую ошибку и пренебрегает основами управления.

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

Дизайнер с раздутым эго никогда не сможет компенсировать его своими красивыми картинками и хорошими дизайн-решениями. Он скорее все соки выпьет. В этой ситуации лиду гораздо быстрее засучить рукава и нарисовать все его макеты самому (но лучше  нанять новых).  

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

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

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

Ты тимлид? Давай общаться! Оставляй комментарии об управлении дизайн-командой и задавай вопросы.

Следующий выпуск продолжает тему иерархии.

—
#для_профи

#стать_лидом №3. Иерархия и творческая свобода

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

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

1. Увольнение — никогда не лёгкое решение
Тимлид не может разбрасываться дизайнерами и при первых признаках проблем сливать своих людей, которых сам же нанял. Это показывает его профнепригодность и может дорого обходиться компании. Конечно, он должен иметь крутые софт-скилы, кучу терпения и пытаться договариваться, когда это возможно.

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


2. Нужна иерархия в решениях, а не в манере общения. Почему демократия не работает

Алексей Трусов:
>лучшая модель управления по факту тогда, когда нет пирамидальной иерархии, а когда сотрудники знают, что лид — линейный сотрудник.

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

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


3. Окончательное «делаем так»
Умеренный авторитаризм в решениях оптимальнее полной демократии: у команды есть право высказывать своё мнение и принимать свои решения, но нет права препираться, если тимлид сказал окончательное «делаем так» и не хочет тратить время на доказательство, что именно так правильно. Так экономится много времени на разборки.

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

Продолжение →

← Начало поста

4. Тимлид-тиран и микроменеджмент
Если в команде нельзя открыто высказывать своё мнение и предлагать свои решения, значит, в ней нет безопасной творческой среды. Это приводит к тому, что все творческие решения принимает только тимлид, и это ужасная ситуация.

Na Z:
«Если вам попался тимлид с таким подходом описанным выше - бегите не оборачиваясь. Особенно от заявляющих что правила дизайна должны подчиняться правилам его менеджерской вселенной. ... Указывать и подчинять своим правилам - это фича мало уверенного в себе тимлида, который только и занят тем чтобы ему наконец все подчинились и послушались»

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

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


5. Делегирование и автопилот

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

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

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

—
#для_профи

Выбираем интересные темы в #первые_шаги

Привет. Мне понятно, куда развивать рубрику #для_профи, но с рубрикой для начинающих не всё так очевидно. Прикидываю, какие темы будут наиболее интересны для начинающих дизайнеров среди читателей. Прошу голосовать только тех, кому интересна сама рубрика. Если есть идеи и предложения, буду рад их получить лично: @okunev. Я открыт для общения.

Ноушн-сайт /designer

/designer

Сегодня будет крутой подгон. Я собрал весь контент этого проекта на единой площадке в ноушн-пространстве.

Notion /designer →

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

Что внутри:

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

Оглавление постов — архив всех моих постов по всем площадкам с 2017, с картинками. Рекомендую порыться в архиве, там есть много ценного про инструменты и UX.

Заметки о проектировании, которые были на старом сайте.

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

Пара хороших книг и лекций про шрифты, которые я публиковал.

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

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

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

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

—
#важное  #Notion  #первые_шаги  #для_профи

Обсуждение поста про ноушн-сайт — здесь.

Урок по анимации лоадера

За 12 шагов рассказываю азы работы со Smart Animate — удобным механизмом для настройки анимации переходов между фреймами.

slashdesigner.ru/loader-smart-animate

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

Проект в Figma Community

—
#первые_шаги  #ui_анимация

Как сетка ухудшила UX

Делюсь недавним негативным опытом, как я использовал 12-колонную сетку на проекте системы управления контентом. Я не продумал некоторых нюансов, что ухудшило опыт моих пользователей. В конце рассказываю, как исправил ситуацию.

slashdesigner.ru/grid-ux-fail

Спойлер: если при проектировании системы ориентироваться только на большие экраны (1920), и не брать в расчёт средние на 1280, 12-колонник, разделённый на 3 блока, может слишком сильно жать контент по ширине. Поэтому, на 1280 стоит избегать деления на 3 колонки, если в одной из них происходит что-то важное.

Выводы:

1. Потребности всегда важнее визуального, а контент важнее оформления.

2. Постоянный хороший контакт с моими пользователями позволил сэкономить на формализованных исследованиях.

3. Всегда стоит начинать проектировать от меньшей ширины к большей. Для админок стандарт ширины — 1280.

А какой интересный опыт работы с сетками был у тебя? Расскажи в комментариях.

—
#для_профи  #сетка

Интерактивные компоненты облегчат создание ховеров

Восхищает, как взаимосвязаны релизы новых фич в Фигме. Каждая следующая фича развивает идею предыдущей. Недавним важным шагом, который мы увидели, был релиз «вариантов». Они дали возможность объединять компоненты в специальные группы, внутри которых стало можно переключать состояния. Это уменьшило количество мусора при поиске нового компонента: теперь в выдаче мы получаем только название группы вариантов, например, Button или Switch.

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

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

Если очень любопытно, можно оставить заявку на бета-тестирование этой фичи.

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

—
#первые_шаги  #ui_анимация

Ещё один пример применения интерактивных компонентов — визуальный сахар.

Как это сделано: есть компонент с кругом, у него 4 разноцветных варианта. Вешаем ему на мастер смену варианта по ховеру, а дальше на каждом запускается цепочка переключения на все последующие варианты с дилем на каждом. За гифку спасибо @vdroog.