Как и зачем оценивать себя дизайнеру внутри профессии

Для вашего удобства мы подготовили детальную расшифровку лекции.

[0:00]

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

[0:37]

Голова и руки дизайнера

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

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

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

[1:50]

Для чего декомпозировать навыки

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

Здесь несколько причин.

Первая — чтобы планово и прицельно совершенствоваться.

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

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

[4:27]

Из чего складывается грейд в Red Collar

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

[5:03]

Отношение к знаниям

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

Следующая ступень — это когда я впитал достаточно чужого опыта и начинаю накапливать свой. У меня появляется некая экспертиза, которой я уже могу начать делиться. Общаясь с другими дизайнерами, я уже могу поведать им что-то новое. Это похоже на то, как если бы вы проходили какую-нибудь игру RPG, где на следующем уровне вроде как одни и те же истории, одни и те же механики, но каждый игрок может рассказать другому, что с ним произошло. На этой ступеньке у вас появляется такой опыт и такая экспертиза, которой вы уже можете поделиться. Следующая ступенька — когда вы полноценно этим опытом делитесь с другими дизайнерами. Вы транслируете свой опыт на все сообщество. У вас появляется возможность кого-то менторить, арт-директить, вы можете сказать другому человеку: «Я уже с этим сталкивался несколько раз, это работает по-другому» То есть, вы накопили некую массу знаний и готовы их транслировать. 

[6:41]

Отношение к решениям

Следующая штука — это отношение к решениям.

Первая ступенька тут — я решаю четко обозначенные проблемы четко определенным способом. Это уровень джуновый.

Мне говорят, какую задачу я должен решить, как я ее должен решить, а, поскольку я обучаюсь еще каким-то хардовым вещам, я просто пробую ее решить так, как мне сказали. Никто не говорит, что у вас тут не может быть какого-то своего мнения, просто его нужно очень много и очень часто обстукивать об арт-директоров, или более старших дизайнеров, если у вас есть такие знакомые — просто-напросто для того, чтобы не наделать фигни. Потому что на этой ступеньке опыта мало и именно поэтому все проблемы обозначаются за вас. Это делает либо бизнес, либо продакт-оунер, либо лидирующий дизайнер, если такой есть на вашем проекте. Эти же люди определяют способ, которым вы эти проблемы будете решать. Повторюсь, потому что на этой ступеньке еще рано брать на себя ответственность за проблемы и способы решения. Просто еще маловато по скиллам. Следующая ступенька — это то, что проблемы все еще обозначаются четко. То есть приходит бизнес, и говорит что вот, у меня такая проблема, решай ее, пожалуйста как-нибудь. Но разница тут в том, что способ, которым ты собираешься решать эту проблему, определяется тобой самим. На этой ступеньке харды выросли уже достаточно: мы знаем, как обращаться с инструментом, мы знаем, как отрисовывать элементы, как работать с автолейаутами, компонентами и разными другими хардовыми штуками. Мы знаем, как технически дизайнить в принципе, но не хватает еще вещей, которые влияют на алгоритмы принятия решений. Чтобы мы посмотрели системно на какую-то штуку, поняли, в каких звеньях этой системы есть проблемы, определили это сами, пришли к заказчику и сказали: «Ты знаешь, у нас тут есть вот это, вот это и вот это, давай попробуем разобраться». Это как раз про следующую ступеньку, когда дизайнер сам определяет проблемы и способы их решения. То есть, он делает то, про что я сейчас проговорил. К нему можно прийти с совершенно абстрактной задачей, и мы можем быть уверены, что он ее решит. Потому что он может проанализировать какой-то объект, который ему предлагается задизайнить, определить проблемы, которые в нем присутствуют, определить потребности аудитории, свести их с потребностями бизнеса, придумать какое-то общее решение, протестировать, задизайнить, и решение будет классным с большой степенью вероятности. 

[9:41]

Влияние на результат

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

[12:38]

Отношение к контролю и самостоятельность

Отношение к контролю и самостоятельность — еще одна штука. Это то, насколько у вас хватает самостоятельности, чтобы принимать решения. То есть на первой ступеньке здесь необходим полный контроль, полное включение арт-директора, лидирующего дизайнера или дизайн-директора, в зависимости от того, как это называется в вашей команде или в вашей паре, если вы работаете в паре со старшим дизайнером, например. То есть, необходимо постоянное включение, причем как на уровне смыслов, так и на уровне технического исполнения — нужно постоянно подглядывать, не наворотил ли дизайнер делов. Такое случается, и часто, особенно на ступеньке джуна. Следующая ступенька — это когда включение арт-директора становится редким. Растет степень уверенности в техническом исполнении, растет степень уверенности в том, каким образом дизайнер принимает решения. Здесь арт-директор включается в роли советника (здесь я условно называю это «арт-директором», в вашей команде или дизайнерской паре это может называться по-другому). Соответственно, здесь уровень технического  исполнения становится более уверенным, на него  можно просто иногда посмотреть и поправить какие-то мелкие вещи, но в роли советника в плане каких-то смыслов, концепций, предлагаемых решений. Арт-директор все еще включается, но уже изредка, так что степень самостоятельности здесь растет. И последняя ступенька этого — это когда дизайнер сам выступает ментором и арт-директором для младших дизайнеров. То есть человек на третьей ступеньке выступает лидирующим дизайнером для первой и второй. То есть, роли перераспределяются, и человек, которого я до этого называл арт-директором, находится на третьей ступеньке того, что можно назвать пищевой цепочкой. 

[15:02]

Модель декомпозиции навыков

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

[16:31]

Навыки для предпроектной аналитики

Еще раз напомню: модель состоит в том, что мы смотрим, на каких этапах процесса какие навыки дизайнера включаются. Первый этап — предпроектная аналитика. Что я здесь выделил? На этом этапе можно смотреть на навык ресерча по открытым источникам. Это очень важно. 

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

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

[19:50]

Навыки для прототипирования

Дальше идет работа со структурой и логикой. То есть, мы побрифовали, мы проанализировали, мы протестировали, мы собрали большую предпроектную штуку, пласт информации. Дальше идем по модели двойного алмаза: сначала мы шли вширь, теперь сужаемся в сторону логики и структуры. Соответственно, тут важные скиллы — умение работать с диаграммами бизнес-процессов. Заказчик может передать то, что у него работает на бэке и в целом в бизнесе в виде каких-то диаграмм, которые еще не являются прототипами — предпрототипный такой этап. Их важно уметь прочитать, с ними важно уметь поработать. Далее — прототипы низкой и высокой детализации. Тут важно отличать, где мы можем просто квадратиками нарисовать какие-то блоки, чтобы понять общую структуру страницы портала или чего угодно. Либо нам нужно уже детально спускаться и располагать какие-то функции в нужных местах, примерно предполагать, сколько будет текста в этом блоке, какие кнопки будут в этом блоке и т. д. То есть, тут в том числе, мы прототипируем на вот этом этапе, и этот навык как раз про это. Проектирование пользовательских сценариев — это когда мы не просто собираем экранчики, мы еще смотрим на то, насколько это укладывается в некий проектный сценарий. Мы смотрим на то, как пользователь будет его проходить, в какие состояния он может попасть: здесь ошибка, здесь — какое-то пустое состояние, начало сценария, конец сценария, результирующий экран, еще какие-то вещи. Все это необходимо учитывать. UX-насмотренность — то важно для того,  чтобы человек располагал нужные элементы в нужном месте, соответствуя какой-то логике страницы. То есть, ему важно знать какие-то типовые элементы, как они работают и что с ними делать, знать фундаментальные эвристики типа эвристик Нильсена или, которые пишет Nielsen Norman Group. Уметь кастомить типовые элементы так, чтобы они все равно оставались понятными. В целом иметь какую-то насмотренность, регулярно отсматривать что-то новое, подмечать для себя какие-то вещи в UX и т.д. Здесь важно уметь собирать. Из софтов это просто внимательность и аккуратность, умение не упускать какие-то детали, учитывать корнер-кейсы и держать порядок в итоговом решении. Вот вы собрали кучу прототипов, и нужно, чтобы кроме вас, это мог еще прочитать какой-то другой человек, желательно, все — и заказчик, и другой дизайнер, и аналитик, и кто угодно. 

[22:52]

Навыки для формирования визуальной концепции

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

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

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

[25:48]

Навыки для масштабирования

Ну, и последний этап, когда мы уже сформировали визуальную концепцию и согласовали ее, у нас идет масштабирование. На этом этапе важны более системные вещи. Не помню, говорил ли я про это, но это скилл-сет, который мы разрабатывали именно в своем, сервисно-продуктовом направлении. Если вы работаете с брендингом, если вы работаете с коммуникационными задачами, с бумажной продукцией, просто с графическим дизайном, или работаете с no-code, возможно, у вас этот процесс будет уложен иначе, и, соответственно, скиллы, которые попадут в него, тоже будут другие, но можно сделать по аналогии с этим. То есть, бизнес-модель остается. Мы берем и раскладываем дизайн-процесс на блоки и наполняем их навыками в соответствии с этим. Дальше, когда наш сервисный проект приходит к масштабированию, решению и поддержке проекта, важны системные вещи. То есть, системно, итеративно заниматься тем же  развитием и наращиванием. Тут важно уметь собирать интерактивные макеты. У нас часто встречаются случаи, когда сервисный проект для десктопа нужно отобразить  для планшета и для мобилки. Важно следовать какому-то Tone of Voice, если он задан, либо соблюдать однородность текста, если он не задан. То есть, чтобы интерфейс общался с пользователем на одном языке всегда. Чтобы, например, кнопки у нас всегда были глагольные, чтобы формулировки в пунктиках-фактоидах всегда начинались с одних и тех же частей речи, чтобы они отвечали на один и тот же вопрос, чтобы хинты под полями тоже были однородными. То есть, чтобы пользователь не чувствовал, что его вырывают из погружения. Это очень важно, особенно в текстах. Работа с цветовыми и типографскими стилями, сборка и редактирование компонентов. Тут я просто пару скиллов положил в дизайн-систему. Тут важнейшая штука, если мы говорим про сервисные проекты, где очень много элементов и компонентов. Их важно, во-первых, уметь правильно задать и соблюдать их правильную работу, а во-вторых, тут нужно еще их документирование. Это более верхнеуровневая штука, я не положил ее сюда. В этом тоже можно развиваться, посмотреть, как  документируют свои системы Google, IBM, Uber, те же самые российские ВК, Яндекс, Сбер. У них замечательно продокументированные системы. Можно идти и копать в это. Но главное, про что я говорю, это то, что мы умеем задать цветовые и типографские стили, мы умеем собрать компоненты правильно, мы умеем воспользоваться теми видами properties в компонентах, которые нам здесь нужны и здесь подходят, мы делаем это оптимально. Мы не делаем огромные матрицы из кнопок 64х64, как это делалось раньше, мы  изучаем инструменты и делаем оптимальную сборку компонентов и учитываем в них все, что нужно. Ну, и что на этом этапе из софтов нам может понадобиться. Это аргументация и защита решения, потому что это постоянное итерационное развитие, когда  у нас приходит новая задача, мы ее сделали, пошли обсуждать с бизнесом, и начинается такой пинг-понг, типа бизнес говорит: «Мы хотим вот  так, нам кажется, так будет лучше» Дизайн говорит: «Нам кажется, для пользователей так будет лучше,  давайте пойдем поисследуем, давайте посмотрим результаты», и т .д. и т. п. То есть здесь аргументация очень важна. Ну и приходить к консенсусу здесь тоже очень важно. Общение с клиентом, запросами и фидбеком. Здесь то же самое: вы вежливый, вы слушаете, вы предлагаете какие-то здравые вещи, вносите коррективы в свою работу и относитесь к этому нормально, и т. д. и т. п. 

[29:58]

Другие модели декомпозиции. Заключение

Вот такая модель у нас получилась. Сразу проговорю, что это не все скиллы, которые нужны в этих этапах процесса, это основные, которые я накидал из нашего продуктового скилл-сета в Red Collar. Можно ли придумать здесь другую модель для скиллов? Естественно, можно. Я, помнится, однажды закидывал в наш канал «Дизайнерская пыль» другой подход к этому.  Я посмотрел на перки в Фоллауте и подумал, а почему бы мне не попробовать уложить сюда какие-то дизайнерские штуки? Типа харизма, сила, ловкость, выносливость, и в них расписывал то, какие скиллы это составляет. В харизме была как раз защита с заказчиком, аргументация, работа с коллегами, совместная работа. Короче, много всего такого, что касается именно дизайнерской харизмы. В выносливости было про то, насколько ты умеешь концентрироваться, насколько долго ты умеешь работать над одной задачей, насколько тебя вещи выводят из себя, насколько ты стабилен, и т.д, и т.п.

Что я хочу сказать? Когда делаешь свою собственную скилловую модель, к ней можно подходить по-разному, и пробовать описывать ее по-разному. И в зависимости от этого, тут не то, чтобы меняются скиллы, которые ее составляют, но это все к тому, чтобы вы нашли какой-то более простой подход, чтобы свои навыки уложить в какую-то систему и в ней уже жить. Потом уже, в зависимости от того, как вы будете от компании к компании переходить, естественно, все эти системы будут меняться и трансформироваться, потому что там будут свои грейдовые и скилловые системы. Но, тем не менее, вы будете готовы к ответам на вопросы, например, про инструментарий: «Насколько хорошо ты знаешь Фигму?» Вы будете готовы к ответу на вопросы: «А насколько хорошо ты умеешь рисовать иконки? А насколько хорошо ты знаешь CJM-ки? А насколько хорошо ты умеешь проектировать сценарии?». Отвечать самому себе на эти вопросы — это очень важно. Чтобы не поставить себя в ступор, когда нужно будет рассказать про себя в нужный момент, например, при собеседовании, или чтобы более адекватно продать себя заказчику, или пообщаться с другим дизайнером. В общем, все эти вещи я тут уже проговорил, просто пытаюсь как-то резюмировать. Спасибо, что были внимательны, спасибо, что послушали. Рад был рассказать. Всем желаю удачи!