Важно помнить, что при таком заходе пользователю будет сложнее составить ментальную модель интерфейса (то бишь запомнить, где что лежит), поэтому вариант подойдёт для скрытия Особо Важных и Особо Удобных Элементов, появление которых пользователь никак не пропустит — и при этом будет прекрасно понимать условия их возникновения.
Вариант номер три - «Шик-Шарман». Мы хотим приучить пользователя, где находится нужная кнопка — но при этом не хотим тратить его драгоценное время на бесцельные нажатия.
Штош, прекрасно, вот вам два примера с неактивными кнопками. Что мы делаем: дизейблим кнопку (или чо у вас там), бахаем рядом объяснение, почему кнопка не фурычит:
Вариант номер три - «Шик-Шарман». Мы хотим приучить пользователя, где находится нужная кнопка — но при этом не хотим тратить его драгоценное время на бесцельные нажатия.
Штош, прекрасно, вот вам два примера с неактивными кнопками. Что мы делаем: дизейблим кнопку (или чо у вас там), бахаем рядом объяснение, почему кнопка не фурычит:
Заметьте, что Ноушн справляется с задачей объяснения неактивности кнопок двумя способами: или заставляет читать тултип при наведении(криво работающий, надо сказать), или призывает ориентироваться на шильдик БУЗИНЕСС (типа, нищеброд, не входи, это не про тебя). Решения не безупречные — но вполне работают.
Наконец, имеется вариант номер четыре — «Банкетный». Он самый сложный и подразумевает, что кнопки продолжают работать даже тогда, когда в них нет прямого смысла.
Ловите пример:
Наконец, имеется вариант номер четыре — «Банкетный». Он самый сложный и подразумевает, что кнопки продолжают работать даже тогда, когда в них нет прямого смысла.
Ловите пример:
Этот вариант самый сложный, потому что пользователь загоняется в искусственный тупик - и это должно быть оправдано.
Почему Ноушн не скрывает кнопку INVITE и оставляет ее доступной даже при незаполненной строке адреса?
У меня есть два соображения на этот счёт:
1. Ноушн зарабатывает на командных аккаунтах, а потому хочет повсюду демонстрировать лёгкость и доступность этой функции.
2. Нажатие на кнопку приводит не к окошку «КОГО ТЫ ИНВАЙТИШ СТЕРВА ТЫ ДАЖЕ НИКОГО НЕ ОТМЕТИЛ», но к довольно хитрой конструкции, в которой есть место и объяснению функции, и приглашению подсоединить слак, и чувства тупика не возникает.
Занятно, что такое же поведение мы обнаруживаем в другой денежной штуке — в оплате. Переход на платный тариф — вещь важная, поэтому мы оставляем кнопку суперзаметной, пусть и тупиковой (и, как справедливо замечают в комментах к следующей картинке, не создаём впечатления, что что-то сломалось):
Почему Ноушн не скрывает кнопку INVITE и оставляет ее доступной даже при незаполненной строке адреса?
У меня есть два соображения на этот счёт:
1. Ноушн зарабатывает на командных аккаунтах, а потому хочет повсюду демонстрировать лёгкость и доступность этой функции.
2. Нажатие на кнопку приводит не к окошку «КОГО ТЫ ИНВАЙТИШ СТЕРВА ТЫ ДАЖЕ НИКОГО НЕ ОТМЕТИЛ», но к довольно хитрой конструкции, в которой есть место и объяснению функции, и приглашению подсоединить слак, и чувства тупика не возникает.
Занятно, что такое же поведение мы обнаруживаем в другой денежной штуке — в оплате. Переход на платный тариф — вещь важная, поэтому мы оставляем кнопку суперзаметной, пусть и тупиковой (и, как справедливо замечают в комментах к следующей картинке, не создаём впечатления, что что-то сломалось):
Короче, если вы хотите использовать тупиковые кнопки без вменяемого результата, вы должны ответить себе на два вопроса:
1. Не будет ли лучше, если я эту кнопку просто скрою или задизейблю?
2. Какую историю я смогу рассказать, если пущу пользователя дальше?
Если у вас есть ответ на оба вопроса — поздравляю, вы поёте великолепно.
Главное — ориентируйтесь на пользователя.
Если же к вам придёт какой-нибудь чёрт и скажет «В ПРОДУКТЕ АБСОЛЮТНО ВСЕ КНОПКИ ДОЛЖНЫ СЕБЯ ВЕСТИ ОДИНАКОВО» — бейте черта, гоните его, и помните, что консистентность по-настоящему работает, когда она строится во имя пользователя, но не поперёк его интересов.
#изкрестьянскогобыта
1. Не будет ли лучше, если я эту кнопку просто скрою или задизейблю?
2. Какую историю я смогу рассказать, если пущу пользователя дальше?
Если у вас есть ответ на оба вопроса — поздравляю, вы поёте великолепно.
Главное — ориентируйтесь на пользователя.
Если же к вам придёт какой-нибудь чёрт и скажет «В ПРОДУКТЕ АБСОЛЮТНО ВСЕ КНОПКИ ДОЛЖНЫ СЕБЯ ВЕСТИ ОДИНАКОВО» — бейте черта, гоните его, и помните, что консистентность по-настоящему работает, когда она строится во имя пользователя, но не поперёк его интересов.
#изкрестьянскогобыта
Друзья, щас будет парадокс: мой бомбаж по суперкапитанской теме (наверное, самой капитанской за всю историю Хуикса).
Интересно? А вот вам для начала пара реальных историй.
История первая. Есть хороший дизайнер с руками (2 шт.), головой (1 шт.), неравнодушием (1 ведро) и всем таким. Не подкопаешься.
Этот дизайнер идет на встречу с высоким руководством представлять свое решение. Он показывает огненные слайды, отталкивается от реальных проблем, метрик - в общем, ведет себя как продуктовый дизайнер. Все до поры до времени сидят, кивают и слушают. Стоит благодать.
А дальше происходит вот что. На слайде №5, когда приходит пора рассказать про отрисованное решение, дизайнер уходит в обстоятельный, нуднейший рассказ про отступы, про ВОТ ТУТ БЫЛ КОМПОНЕНТ С ОТСТУПОМ 10 ПИКСЕЛЕЙ А ВОТ ТУТ БЫЛ КОМПОНЕНТ ТОЖЕ С ОТСТУПОМ 10 ПИКСЕЛЕЙ А ВОТ ТУТ НА ПЕРЕСЕЧЕНИИ КОМПОНЕНТОВ ПОЛУЧАЛОСЬ 20 ПИКСЕЛЕЙ И ВОТ МЫ СДЕЛАЛИ ОДИН КОМПОНЕНТ ЧТОБЫ БЫЛО 10 ПИКСЕЛЕЙ НО У НАС СРАЗУ НЕ ПОЛУЧИЛОСЬ ПОЭТОМУ МЫ ПОШЛИ К РАЗРАБОТКЕ А ОНИ НАМ ГОВОРЯТ ДЕЛАЙТЕ 20 ПИКСЕЛЕЙ НО МЫ СДЕЛАЛИ МЕГАКОМПОНЕНТ С ЕДИНЫМ ОТСТУПОМ 10 ПИКСЕЛЕЙ А ПОТОМ…
Короче, с этого момента дизайнер уходит в детальные, поистине чудовищные дебри.
Что делает высокое руководство? Оно сперва засыпает, потом начинает беситься, потому что сон в его задачи не входит, потом понимает, что ничего изменить нельзя, влезает в подсчет пикселей, не на шутку увлекается, раздает ковровые ценные указания по мегакомпоненту, дизайнер начинает с ним спорить, время выходит, занавес. Руководство уходит с ощущением “НУ И ХЕРАБОРА”. Цель - рассказать руководству, что вот такая проблема решена, мы молодцы и вот что хотим делать дальше - не выполнена. И это фейл.
История вторая. Есть классный, топовый дизайнер, который ищет новую работу. Он жаждет новых челленджей и горизонтов.
Этот дизайнер идет на собеседование с нанимающим руководством, где должен презентовать свой опыт. Он готовит рассказ про фичи, над которыми он работал, разворачивает решаемые проблемы, вкусно показывает решение, приводит итоги запуска, расписывает роадмап на далекую перспективу. Фича расписана так, что в нее невозможно не влюбиться.
Дальше начинается само собеседование. Дизайнер с места в карьер уходит в зажигательный рассказ про фичи, показывая их так, как даже сам Джобс свой айфон не показал бы. Тайминг выдержан четко, композиция - тоже. У истории про фичу есть своя завязка, кульминация и развязка. Нерв трепещет.
Короче, все в высшей мере драматично. Проблема лишь в одном: дизайнер ни единым словом не упоминает про свой вклад, степень участия, лично им решенные проблемы и полученный опыт. Его как будто не существует.
И что же нанимающее руководство? Оно выходит со встречи с ощущением, что ему показали крутые фичи, но забыли показать самого дизайнера. Цель - убедить нанимающее руководство, что перед ними классный, топовый дизайнер, который станет ценным добавлением в команду - не выполнена. И это тоже фейл.
Интересно? А вот вам для начала пара реальных историй.
История первая. Есть хороший дизайнер с руками (2 шт.), головой (1 шт.), неравнодушием (1 ведро) и всем таким. Не подкопаешься.
Этот дизайнер идет на встречу с высоким руководством представлять свое решение. Он показывает огненные слайды, отталкивается от реальных проблем, метрик - в общем, ведет себя как продуктовый дизайнер. Все до поры до времени сидят, кивают и слушают. Стоит благодать.
А дальше происходит вот что. На слайде №5, когда приходит пора рассказать про отрисованное решение, дизайнер уходит в обстоятельный, нуднейший рассказ про отступы, про ВОТ ТУТ БЫЛ КОМПОНЕНТ С ОТСТУПОМ 10 ПИКСЕЛЕЙ А ВОТ ТУТ БЫЛ КОМПОНЕНТ ТОЖЕ С ОТСТУПОМ 10 ПИКСЕЛЕЙ А ВОТ ТУТ НА ПЕРЕСЕЧЕНИИ КОМПОНЕНТОВ ПОЛУЧАЛОСЬ 20 ПИКСЕЛЕЙ И ВОТ МЫ СДЕЛАЛИ ОДИН КОМПОНЕНТ ЧТОБЫ БЫЛО 10 ПИКСЕЛЕЙ НО У НАС СРАЗУ НЕ ПОЛУЧИЛОСЬ ПОЭТОМУ МЫ ПОШЛИ К РАЗРАБОТКЕ А ОНИ НАМ ГОВОРЯТ ДЕЛАЙТЕ 20 ПИКСЕЛЕЙ НО МЫ СДЕЛАЛИ МЕГАКОМПОНЕНТ С ЕДИНЫМ ОТСТУПОМ 10 ПИКСЕЛЕЙ А ПОТОМ…
Короче, с этого момента дизайнер уходит в детальные, поистине чудовищные дебри.
Что делает высокое руководство? Оно сперва засыпает, потом начинает беситься, потому что сон в его задачи не входит, потом понимает, что ничего изменить нельзя, влезает в подсчет пикселей, не на шутку увлекается, раздает ковровые ценные указания по мегакомпоненту, дизайнер начинает с ним спорить, время выходит, занавес. Руководство уходит с ощущением “НУ И ХЕРАБОРА”. Цель - рассказать руководству, что вот такая проблема решена, мы молодцы и вот что хотим делать дальше - не выполнена. И это фейл.
История вторая. Есть классный, топовый дизайнер, который ищет новую работу. Он жаждет новых челленджей и горизонтов.
Этот дизайнер идет на собеседование с нанимающим руководством, где должен презентовать свой опыт. Он готовит рассказ про фичи, над которыми он работал, разворачивает решаемые проблемы, вкусно показывает решение, приводит итоги запуска, расписывает роадмап на далекую перспективу. Фича расписана так, что в нее невозможно не влюбиться.
Дальше начинается само собеседование. Дизайнер с места в карьер уходит в зажигательный рассказ про фичи, показывая их так, как даже сам Джобс свой айфон не показал бы. Тайминг выдержан четко, композиция - тоже. У истории про фичу есть своя завязка, кульминация и развязка. Нерв трепещет.
Короче, все в высшей мере драматично. Проблема лишь в одном: дизайнер ни единым словом не упоминает про свой вклад, степень участия, лично им решенные проблемы и полученный опыт. Его как будто не существует.
И что же нанимающее руководство? Оно выходит со встречи с ощущением, что ему показали крутые фичи, но забыли показать самого дизайнера. Цель - убедить нанимающее руководство, что перед ними классный, топовый дизайнер, который станет ценным добавлением в команду - не выполнена. И это тоже фейл.
Что объединяет эти истории? 2 вещи: их главными героями являются дизайнеры - и они вообще не понимают, кому они рассказывают свои презентации.
Дорогие мои, запомните очень простую, но проблемную штуку - в презентации важно учитывать не только то, что, как и зачем вы презентуете, но и отвечать на 2 вопроса:
1. Кому я презентую свое решение.
2. Как личность слушателя влияет на то, что, как и зачем я презентую.
Личность слушателя важна до безумия. Если вы рассказываете свое решение другим дизайнерам в рамках дизайн-критики, то надо показывать всю подноготную ваших решений. Если вы показываете макеты своему непосредственному руководителю - то надо давать чуть меньше деталей, но позаботиться о достоверности общей картинки. Если вы показываете свое решение топ-менеджменту - там должно быть только самое главное, что не утомит слушателя и передаст ему, что и вы, и ваше решение прекрасно (а если есть проблемы - то четко очертит их и планы по их решению. Если вы показываете свое решение нанимающему дизайнеру - вы должны показать ему, что вы хорошо знаете свое дело, теорию и практику вопроса, имеете опыт работы в разных ситуациях и можете многому научить. Если вы показываете решение широкой публике - то ей вообще нужно будет показать веселые истории про фичу и ее применение, а на проблемах, команде и роадмапах можно не останавливаться. И так далее.
Путать эти кейсы и ходить повсюду с одной презентацией - смерти подобно, особенно если вы дизайнер: вы по долгу службы должны понимать, что у каждого решения есть свой потребитель со своими особенностями, и отстраивать свою подачу от этого. Когда я вижу, что дизайнер на собеседовании не может спроектировать собственную презентацию - у меня возникают вопросы и к здравомыслию дизайнера, потому что ну камон.
Вроде капитанская вещь, а, блин, вижу эти ошибки раз за разом. Не наступайте на эти грабли, пожалусто.
#изкрестьянскогобыта
Дорогие мои, запомните очень простую, но проблемную штуку - в презентации важно учитывать не только то, что, как и зачем вы презентуете, но и отвечать на 2 вопроса:
1. Кому я презентую свое решение.
2. Как личность слушателя влияет на то, что, как и зачем я презентую.
Личность слушателя важна до безумия. Если вы рассказываете свое решение другим дизайнерам в рамках дизайн-критики, то надо показывать всю подноготную ваших решений. Если вы показываете макеты своему непосредственному руководителю - то надо давать чуть меньше деталей, но позаботиться о достоверности общей картинки. Если вы показываете свое решение топ-менеджменту - там должно быть только самое главное, что не утомит слушателя и передаст ему, что и вы, и ваше решение прекрасно (а если есть проблемы - то четко очертит их и планы по их решению. Если вы показываете свое решение нанимающему дизайнеру - вы должны показать ему, что вы хорошо знаете свое дело, теорию и практику вопроса, имеете опыт работы в разных ситуациях и можете многому научить. Если вы показываете решение широкой публике - то ей вообще нужно будет показать веселые истории про фичу и ее применение, а на проблемах, команде и роадмапах можно не останавливаться. И так далее.
Путать эти кейсы и ходить повсюду с одной презентацией - смерти подобно, особенно если вы дизайнер: вы по долгу службы должны понимать, что у каждого решения есть свой потребитель со своими особенностями, и отстраивать свою подачу от этого. Когда я вижу, что дизайнер на собеседовании не может спроектировать собственную презентацию - у меня возникают вопросы и к здравомыслию дизайнера, потому что ну камон.
Вроде капитанская вещь, а, блин, вижу эти ошибки раз за разом. Не наступайте на эти грабли, пожалусто.
#изкрестьянскогобыта
Вспомнилась мне одна поучительная история.
Делали мы как-то сайт для одной сетевой чайхоны — ну, знаете, пацанчики с кальянами, диваны, горы плова и все такое.
Заказчик нам попался, надо сказать, с выдумкой: он решил не просто сбацать сайт, но устроить из этого социалистическое соревнование по мотивам сказки «Царевна-лягушка» — позвал два агентства (включая нас) и наказал каждому сделать такой дизайн, что ни в сказке сказать, ни пером написать. И сказал: у кого дизайн лучше выйдет — тому тендер и пол-казана плова в придачу.
Сперва все шло как по маслу: мы по уши влезли в проектирование по методу персон (кстати, в следующий раз про него поговорим), отрисовали охапку CJM, то-се. Заказчик смотрел на это и радовался: мол, вы молодцы, не то что те другие гоблины, аж сердце пляшет. А мы и рады-радёхоньки.
Радовались мы ярко, но недолго: дальше произошла фатальная штука, которая прозвучит как анекдот — мы с треском, хрустом, кряканьем провалились на, смешно сказать, вайрфреймах.
Делали мы как-то сайт для одной сетевой чайхоны — ну, знаете, пацанчики с кальянами, диваны, горы плова и все такое.
Заказчик нам попался, надо сказать, с выдумкой: он решил не просто сбацать сайт, но устроить из этого социалистическое соревнование по мотивам сказки «Царевна-лягушка» — позвал два агентства (включая нас) и наказал каждому сделать такой дизайн, что ни в сказке сказать, ни пером написать. И сказал: у кого дизайн лучше выйдет — тому тендер и пол-казана плова в придачу.
Сперва все шло как по маслу: мы по уши влезли в проектирование по методу персон (кстати, в следующий раз про него поговорим), отрисовали охапку CJM, то-се. Заказчик смотрел на это и радовался: мол, вы молодцы, не то что те другие гоблины, аж сердце пляшет. А мы и рады-радёхоньки.
Радовались мы ярко, но недолго: дальше произошла фатальная штука, которая прозвучит как анекдот — мы с треском, хрустом, кряканьем провалились на, смешно сказать, вайрфреймах.
Не, сперва-то все шло хорошо: мы с собратом-креативным директором разложили наши CJMы и прочие навигационные диаграммы, поплевали на руки и нарисовали в матушке-Акшуре (Фижмы тогда и в планах не было) черно-белые прототипы — условные и очень квадратные.
«НОРМАЛЬНО, — сказал один из нас, — НО ЧТО ТО ТЕРЯЕТСЯ ИДЕЯ ПРО ГОРИЗОНТАЛЬНЫЙ СКРОЛЛ ДАВАЙ КА И ЕГО ПОКАЖЕМ И ЗАОДНО ОТРАЗИМ КАК МЕНЮ СБОКУ ДЕЛАЕТ ВЖИК ВЖИК»
Штош, можно! Поклонились мы матушке-Акшуре и сделали скролл да вжик-вжик.
«КАЙФОВО, — заключил кто-то из нас, — НО ЧТО ТО АКЦЕНТЫ ТЕРЯЮТСЯ ДАВАЙ КНОПКИ ПОКРАСИМ»
Можно и это! Сделали кнопки цветные и шрифты заодно подхомячили.
«И ТО ДЕЛО, — одобрили мы, — НО ЧТО ТО НЕ ЧУВСТВУЕТСЯ УПОР НА КОНТЕНТ ТО БИШЬ ЖИЗНИ НЕТУ»
И добавили мы фотки лепёшек, плова, довольных гостей — и, как гвоздь программы, фотографию Шуфутинского на страницу «Наши гости». В конце концов, кто как не улыбающийся дядя Миша сможет передать сытое ощущение после тарелки бараньего хаша?
Ну и так далее. Оттянулись мы от души, не щадя живота своего. И вот черно-белый вайрфрейм на наших глазах ожил, наполнился красками и, протяжно крича, улетел к заказчику.
«НОРМАЛЬНО, — сказал один из нас, — НО ЧТО ТО ТЕРЯЕТСЯ ИДЕЯ ПРО ГОРИЗОНТАЛЬНЫЙ СКРОЛЛ ДАВАЙ КА И ЕГО ПОКАЖЕМ И ЗАОДНО ОТРАЗИМ КАК МЕНЮ СБОКУ ДЕЛАЕТ ВЖИК ВЖИК»
Штош, можно! Поклонились мы матушке-Акшуре и сделали скролл да вжик-вжик.
«КАЙФОВО, — заключил кто-то из нас, — НО ЧТО ТО АКЦЕНТЫ ТЕРЯЮТСЯ ДАВАЙ КНОПКИ ПОКРАСИМ»
Можно и это! Сделали кнопки цветные и шрифты заодно подхомячили.
«И ТО ДЕЛО, — одобрили мы, — НО ЧТО ТО НЕ ЧУВСТВУЕТСЯ УПОР НА КОНТЕНТ ТО БИШЬ ЖИЗНИ НЕТУ»
И добавили мы фотки лепёшек, плова, довольных гостей — и, как гвоздь программы, фотографию Шуфутинского на страницу «Наши гости». В конце концов, кто как не улыбающийся дядя Миша сможет передать сытое ощущение после тарелки бараньего хаша?
Ну и так далее. Оттянулись мы от души, не щадя живота своего. И вот черно-белый вайрфрейм на наших глазах ожил, наполнился красками и, протяжно крича, улетел к заказчику.
И знаете, что было дальше? Дальше было слово, вернее, сразу несколько слов: «ЧТО ЭТО ПОЧЕМУ ОНО ТАКОЕ УРОДЛИВОЕ ПОЧЕМУ ОНО ТАК СТРАННО ДВИЖЕТСЯ И ЧТО ТУТ ЧЕРТ ВОЗЬМИ ДЕЛАЕТ ШУФУТИНСКИЙ ОН НЕ НАШ ГОСТЬ!!!»
Мы, конечно, пробовали объяснить, что это такая условность, что мы нарисуем красивый дизайн, что это все по-быстрому и надо оценивать компоновку… все тщетно: заказчик при виде наших прототипов твёрдо уверился, что это и есть финальный дизайн, и он — полное говно.
И после этого смысл потеряло все: и персонажи, и CJM, и даже тот факт, что конкурирующая партия нарисовала так-себе-дизайн-на-троечку — все затмевалось нашим цветным уродом из недр Акшуры с довольным Шуфутинским на капитанском мостике.
Мораль (куда ж мы без морали) проста: коли вы тащите какой-то непропечённый набросок своим заказчикам или широкой публике — делайте его настолько условным, что даже дитя поймёт, что это прототип, который не нужно пинать ногами.
Это важно даже не потому, что иначе вы формируете ложные ожидания — но и потому, что условный прототип переводит вашего собеседника из режима критики в режим брейншторма. Вы не приносите что-то на суд — вы запускаете творческий процесс и начинаете думать вместе.
Поэтому всегда важно понимать, когда стоит остановиться — особенно если в ваших руках улыбающийся Шуфутинский.
#байкабабайка
Мы, конечно, пробовали объяснить, что это такая условность, что мы нарисуем красивый дизайн, что это все по-быстрому и надо оценивать компоновку… все тщетно: заказчик при виде наших прототипов твёрдо уверился, что это и есть финальный дизайн, и он — полное говно.
И после этого смысл потеряло все: и персонажи, и CJM, и даже тот факт, что конкурирующая партия нарисовала так-себе-дизайн-на-троечку — все затмевалось нашим цветным уродом из недр Акшуры с довольным Шуфутинским на капитанском мостике.
Мораль (куда ж мы без морали) проста: коли вы тащите какой-то непропечённый набросок своим заказчикам или широкой публике — делайте его настолько условным, что даже дитя поймёт, что это прототип, который не нужно пинать ногами.
Это важно даже не потому, что иначе вы формируете ложные ожидания — но и потому, что условный прототип переводит вашего собеседника из режима критики в режим брейншторма. Вы не приносите что-то на суд — вы запускаете творческий процесс и начинаете думать вместе.
Поэтому всегда важно понимать, когда стоит остановиться — особенно если в ваших руках улыбающийся Шуфутинский.
#байкабабайка
Недавно ко мне пришли ходоки к Ленину начинающие дизайнеры и спрашивают такие: «ЛЁХА А ЧЕГО У ДИЗАЙНЕРОВ НА СОБЕСЕДОВАНИИ СПРАШИВАЮТ К ЧЕМУ ГОТОВИТЬСЯ НАМ ГОРЕМЫЧНЫМ?»
Штош, давайте расскажу.
Но начнём с того, что вам надо выкинуть эту тему «А какие вопросы будут» из головы. Спросить вас могут о чем угодно - от того, как настраивать прозрачность в Фигме, до того, какой у вас знак Зодиака или не являетесь ли вы каким-нибудь Кисой Воробьяниновым согласно науке соционике.
(вы вот ржете, а я знал одну компанию, где HR упарывались в гороскопы и соционику. И знаете что? Через полгода вся бережно собранная эзотерическая команда разосралась в хламину)
Важно не то, что спросят - а то, в чем вы не должны облажаться в любом случае. И, возможно, про это стоит рассказать самому.
И это:
1. История вашего развития. Не «Я… эээ… Ваня и я..: эээ… решил вот интерфейсы порисовать», а нормальная история: с завязкой (почему вас волнует дизайн), с развитием (как вы с этим жили), кульминацией (почему вам важно именно это собеседование) - и развязкой (куда вы хотите развиваться дальше на данный момент).
2. Рассказ про свежий опыт. Что вы делали/учили/создавали за последний год. Что вам это дало. Что вам это не дало. Где вы ошибались (!) - и чему это вас научило. Покажите, что вы не кусок гранита, а живой, ищущий человек.
3. Дизайн-процессы, суть дизайна, UX и всего такого. С вас не потребуют хардкора (типа, расписать все кейсы, когда не работает трипл даймонд), но умение внятно объяснить, почему дизайн - он не про картинки и что такое UX - важно.
4. Понимание командной работы. Дизайнер, особенно продуктовый - это командный игрок, потому что дизайн - он на 80% про коммуникацию. Вы должны быть готовы четко и логично рассказать про ваше видение роли дизайнера в команде, с примерами и прочим. То, что вы понимаете, как взаимодействовать с менеджерами, исследователями, разрабами - должно быть видно. Если у вас в этом нет опыта - честно говорите об этом и добавляйте «но вот что я думаю…».
5. Фокус на результат. Очень важно всей логикой повествования во всем уметь показать, что дизайн для вас - не самоцель как таковая, а средство достижения результата. Если вы это не до конца понимаете и ещё не чувствуете - почитайте, подумайте, почувствуйте. Это всегда видно в кандидатах. Это важно. Постоянно прокидывайте логический мостик «вот в какой ситуации я был - вот что я делал - вот что получилось и не получилось».
6. Отношение к критике и ошибкам. Важно быть готовым честно рассказать про свои ошибки, залеты - и чему это вам научило. Для меня всегда красный флаг - когда на вопрос «расскажите о ваших последних факапах» звучит ответ «Такого не было» или «Я слишком трудолюбивый». Живой развивающийся человек всегда ошибается, а на взлёте карьеры - тем более. Покажите своё умение учиться на ошибках и работать с фидбэком.
7. Техника и инструменты. Будьте готовы говорить про инструменты и технику работы с ними - про Фигму, инструменты прототипирования м так далее. При необходимости - будьте готовы показать что-то руками.
8. Тестовое задание. Оно, скорее всего, у вас будет, но это вы и так знаете. Тестовое подчиняется тем же правилам, что и все остальное.
9. Портфолио. Оно у вас должно быть, вы должны уметь о нем говорить. Основные правила: не врать, уметь обосновать каждое решение, не перегружать кучей скринов и деталей, все опрятно структурировать. Портфолио - это залог 80% первого впечатления от дизайнера.
10. Обоснование решений. Вы должны уметь объяснять, как пришли к каждому своему решению - а также то, как вы убедитесь в их работоспособности.
11. Умение остановиться. Это очень слабое место у многих новичков. Старайтесь превосходить ожидания - но вовремя останавливайтесь. Делаете тестовое? Покажите доп.варианты и наброски идей на будущее, но не рисуйте кучу всего, о чем вас не просили. Говорите о себе? Расскажите и о своей результативности, но не разжёвывайте каждый проект в деталях. Не улетайте в космос и не душните - это худшая тактика на собесах.
И вот тут я и сам остановлюсь.
Штош, давайте расскажу.
Но начнём с того, что вам надо выкинуть эту тему «А какие вопросы будут» из головы. Спросить вас могут о чем угодно - от того, как настраивать прозрачность в Фигме, до того, какой у вас знак Зодиака или не являетесь ли вы каким-нибудь Кисой Воробьяниновым согласно науке соционике.
(вы вот ржете, а я знал одну компанию, где HR упарывались в гороскопы и соционику. И знаете что? Через полгода вся бережно собранная эзотерическая команда разосралась в хламину)
Важно не то, что спросят - а то, в чем вы не должны облажаться в любом случае. И, возможно, про это стоит рассказать самому.
И это:
1. История вашего развития. Не «Я… эээ… Ваня и я..: эээ… решил вот интерфейсы порисовать», а нормальная история: с завязкой (почему вас волнует дизайн), с развитием (как вы с этим жили), кульминацией (почему вам важно именно это собеседование) - и развязкой (куда вы хотите развиваться дальше на данный момент).
2. Рассказ про свежий опыт. Что вы делали/учили/создавали за последний год. Что вам это дало. Что вам это не дало. Где вы ошибались (!) - и чему это вас научило. Покажите, что вы не кусок гранита, а живой, ищущий человек.
3. Дизайн-процессы, суть дизайна, UX и всего такого. С вас не потребуют хардкора (типа, расписать все кейсы, когда не работает трипл даймонд), но умение внятно объяснить, почему дизайн - он не про картинки и что такое UX - важно.
4. Понимание командной работы. Дизайнер, особенно продуктовый - это командный игрок, потому что дизайн - он на 80% про коммуникацию. Вы должны быть готовы четко и логично рассказать про ваше видение роли дизайнера в команде, с примерами и прочим. То, что вы понимаете, как взаимодействовать с менеджерами, исследователями, разрабами - должно быть видно. Если у вас в этом нет опыта - честно говорите об этом и добавляйте «но вот что я думаю…».
5. Фокус на результат. Очень важно всей логикой повествования во всем уметь показать, что дизайн для вас - не самоцель как таковая, а средство достижения результата. Если вы это не до конца понимаете и ещё не чувствуете - почитайте, подумайте, почувствуйте. Это всегда видно в кандидатах. Это важно. Постоянно прокидывайте логический мостик «вот в какой ситуации я был - вот что я делал - вот что получилось и не получилось».
6. Отношение к критике и ошибкам. Важно быть готовым честно рассказать про свои ошибки, залеты - и чему это вам научило. Для меня всегда красный флаг - когда на вопрос «расскажите о ваших последних факапах» звучит ответ «Такого не было» или «Я слишком трудолюбивый». Живой развивающийся человек всегда ошибается, а на взлёте карьеры - тем более. Покажите своё умение учиться на ошибках и работать с фидбэком.
7. Техника и инструменты. Будьте готовы говорить про инструменты и технику работы с ними - про Фигму, инструменты прототипирования м так далее. При необходимости - будьте готовы показать что-то руками.
8. Тестовое задание. Оно, скорее всего, у вас будет, но это вы и так знаете. Тестовое подчиняется тем же правилам, что и все остальное.
9. Портфолио. Оно у вас должно быть, вы должны уметь о нем говорить. Основные правила: не врать, уметь обосновать каждое решение, не перегружать кучей скринов и деталей, все опрятно структурировать. Портфолио - это залог 80% первого впечатления от дизайнера.
10. Обоснование решений. Вы должны уметь объяснять, как пришли к каждому своему решению - а также то, как вы убедитесь в их работоспособности.
11. Умение остановиться. Это очень слабое место у многих новичков. Старайтесь превосходить ожидания - но вовремя останавливайтесь. Делаете тестовое? Покажите доп.варианты и наброски идей на будущее, но не рисуйте кучу всего, о чем вас не просили. Говорите о себе? Расскажите и о своей результативности, но не разжёвывайте каждый проект в деталях. Не улетайте в космос и не душните - это худшая тактика на собесах.
И вот тут я и сам остановлюсь.
Если у вас есть ещё наставления молодым да шутливым дизайнерам - давайте продолжим в комментах.
#изкрестьянскогобыта
#изкрестьянскогобыта
Сегодня, дорогие мои котаны, я хочу поговорить с вами про сложную и редко обсуждаемую дизайн-штуку — про то, как жить, когда в вашей команде категорически не хватает дизайнеров.
Причины этой нехватки могут быть самые разные (от рассинхрона в ресурсах между разработкой и дизайном до проблем внутри дизайн-команды), но итог один — у вас перестает хватать людей, чтобы делать дизайн, вам их неоткуда брать, и в команде немедленно запускается 💫💫💫 Серпантин Дизайнерских Страданий (ТМ).
💫💫💫 Серпантин Дизайнерских Страданий (ТМ) обычно выглядит так.
Сидит Валерик, главный по дизайну, и грустит без дизайн-ресурса; к нему приходит Руководство Всея Продукта и говорит такое: ВАРЕЛИК НАМ СРОЧНО НУЖНЫ ДИЗАЙНЕРЫ ПРОЕКТЫ ГОРЯТ.
Валерик виновато шевелит пушистыми усами и говорит руководству, мол, Викентий Тиранославович, ну нету у меня дизайнеров, хучь плачь, надо нанимать. Руководство внимательно выслушивает его и говорит: ВАРЕЛИК НАМ СРОЧНО НУЖНЫ ДИЗАЙНЕРЫ ПРОЕКТЫ ГОРЯТ. Валерик еще более виновато шевелит пушистыми усами и говорит руководству, мол, Викентий Тиранославович, хорошо, будет сделано.
Дальше происходит вот что. Собираются дизайнеры. Валерик прохаживается взад-вперед и толкает вдохновляющую речь, что, мол, отечество в опасности, а потому надо попотеть на всеобщее благо как илон маск в твиттере и поработать не на один проект, как щас, а на парочку. Короче, призывает херачить.
В ответ на немой дизайнерский вопрос, а откуда бы взять время на такие подвиги, Валерик назидательно поднимает палец и покидает собрание. Все преисполняются и отправляются работать, потому что дизайнерская братия — это братия ответственная и, как правило, умеющая херачить.
Поэтому все херачат, выгорают к чертям собачьим и уходят из компании, тем самым усугубляя проблему с нехваткой дизайнеров и оставляя Валерика грустно шевелить пушистыми усами. Валерик страдает, но ничего поделать не может — ресурсов нет, а херачить-то дальше надо.
Хотелось бы мне описать и страдания Викентия Тиранославовича, Руководителя Всея Продукта, но парадокс ситуации заключается в том, что нехватка дизайнерских ресурсов не воспринимается им как какая-то трагедия — напротив, глядя на то, как дизайнеры продолжают херачить за двоих, высокое руководство невольно задается вопросом, а так ли нужно иметь множество дизайнеров в команде, если и имеющиеся прекрасно справляются.
Если же дизайнеры выгорят, то, как рассуждает Викентий Тиранославович: а) далеко не факт, что станет хуже; б) их можно будет заменить кем-то другим; в) ну и правильно, что выгорели - просто надо уметь работать.
И вот все катится в жопу, хотя внешне выглядит очень даже неплохо.
Причины этой нехватки могут быть самые разные (от рассинхрона в ресурсах между разработкой и дизайном до проблем внутри дизайн-команды), но итог один — у вас перестает хватать людей, чтобы делать дизайн, вам их неоткуда брать, и в команде немедленно запускается 💫💫💫 Серпантин Дизайнерских Страданий (ТМ).
💫💫💫 Серпантин Дизайнерских Страданий (ТМ) обычно выглядит так.
Сидит Валерик, главный по дизайну, и грустит без дизайн-ресурса; к нему приходит Руководство Всея Продукта и говорит такое: ВАРЕЛИК НАМ СРОЧНО НУЖНЫ ДИЗАЙНЕРЫ ПРОЕКТЫ ГОРЯТ.
Валерик виновато шевелит пушистыми усами и говорит руководству, мол, Викентий Тиранославович, ну нету у меня дизайнеров, хучь плачь, надо нанимать. Руководство внимательно выслушивает его и говорит: ВАРЕЛИК НАМ СРОЧНО НУЖНЫ ДИЗАЙНЕРЫ ПРОЕКТЫ ГОРЯТ. Валерик еще более виновато шевелит пушистыми усами и говорит руководству, мол, Викентий Тиранославович, хорошо, будет сделано.
Дальше происходит вот что. Собираются дизайнеры. Валерик прохаживается взад-вперед и толкает вдохновляющую речь, что, мол, отечество в опасности, а потому надо попотеть на всеобщее благо как илон маск в твиттере и поработать не на один проект, как щас, а на парочку. Короче, призывает херачить.
В ответ на немой дизайнерский вопрос, а откуда бы взять время на такие подвиги, Валерик назидательно поднимает палец и покидает собрание. Все преисполняются и отправляются работать, потому что дизайнерская братия — это братия ответственная и, как правило, умеющая херачить.
Поэтому все херачат, выгорают к чертям собачьим и уходят из компании, тем самым усугубляя проблему с нехваткой дизайнеров и оставляя Валерика грустно шевелить пушистыми усами. Валерик страдает, но ничего поделать не может — ресурсов нет, а херачить-то дальше надо.
Хотелось бы мне описать и страдания Викентия Тиранославовича, Руководителя Всея Продукта, но парадокс ситуации заключается в том, что нехватка дизайнерских ресурсов не воспринимается им как какая-то трагедия — напротив, глядя на то, как дизайнеры продолжают херачить за двоих, высокое руководство невольно задается вопросом, а так ли нужно иметь множество дизайнеров в команде, если и имеющиеся прекрасно справляются.
Если же дизайнеры выгорят, то, как рассуждает Викентий Тиранославович: а) далеко не факт, что станет хуже; б) их можно будет заменить кем-то другим; в) ну и правильно, что выгорели - просто надо уметь работать.
И вот все катится в жопу, хотя внешне выглядит очень даже неплохо.
Как же не дать раскрутиться 💫💫💫 Серпантину Дизайнерских Страданий (ТМ) и спасти ситуацию?
Есть три варианта.
Первый — встать в фирменную дизайнерскую позу №5. Она предполагает, что вы надеваете на себя самые дорогие шмотки, которые можете придумать, входите в кабинет высокого руководства лунной походкой и показываете ему анимированную презентацию в Keynote, где раскрываете следующие тезисы:
а) кто делает продуктовые задачи без дизайна — тот обрекает себя на дизайнерское проклятье, раннюю импотенцию и смерть от падучей болезни;
б) дизайнеров не хватает (обоснование: возмущения вселенского дизайнерского астрала);
в) вам нужно взять еще 4 дизайнеров;
г) вы согласны и на двоих.
В итоге вы получите одного нового дизайнера.
Казалось бы, вот и хорошо — но у метода есть свое ограничение: он срабатывает только на слабонервном руководстве, которое привыкло видеть в лице дизайнеров смесь магов с единорогами, а потому вас побаивается и на всякий случай решает не связываться. Если в роли вашего руководства выступает хитрый купец, умеющий считать деньги, то этот метод провалится где-то между пунктами а) и б).
Второй вариант — упороться в экономику, то есть рассчитать кривую спроса и предложения и прикинуть, какой эффект на бизнес дизайн оказывает сейчас - и какова будет потребность в дизайне в дальнейшем. Вариант интересный и классный, но есть одно но: дизайн (а вместе с ним и продукт) традиционно не умеет считать эффект от собственных дизайн-усилий. Все настолько тяжело, что мы с вами поговорим про это в отдельном посте, а пока скорбно помолчим.
Есть три варианта.
Первый — встать в фирменную дизайнерскую позу №5. Она предполагает, что вы надеваете на себя самые дорогие шмотки, которые можете придумать, входите в кабинет высокого руководства лунной походкой и показываете ему анимированную презентацию в Keynote, где раскрываете следующие тезисы:
а) кто делает продуктовые задачи без дизайна — тот обрекает себя на дизайнерское проклятье, раннюю импотенцию и смерть от падучей болезни;
б) дизайнеров не хватает (обоснование: возмущения вселенского дизайнерского астрала);
в) вам нужно взять еще 4 дизайнеров;
г) вы согласны и на двоих.
В итоге вы получите одного нового дизайнера.
Казалось бы, вот и хорошо — но у метода есть свое ограничение: он срабатывает только на слабонервном руководстве, которое привыкло видеть в лице дизайнеров смесь магов с единорогами, а потому вас побаивается и на всякий случай решает не связываться. Если в роли вашего руководства выступает хитрый купец, умеющий считать деньги, то этот метод провалится где-то между пунктами а) и б).
Второй вариант — упороться в экономику, то есть рассчитать кривую спроса и предложения и прикинуть, какой эффект на бизнес дизайн оказывает сейчас - и какова будет потребность в дизайне в дальнейшем. Вариант интересный и классный, но есть одно но: дизайн (а вместе с ним и продукт) традиционно не умеет считать эффект от собственных дизайн-усилий. Все настолько тяжело, что мы с вами поговорим про это в отдельном посте, а пока скорбно помолчим.
Наконец, есть третий, компромиссный вариант — научиться обходиться малым дизайн-ресурсом, не пытаясь охватить необъятное и не сжигая при этом дизайнеров заживо.
Для начала нам уйти в теорию и ответить на вопрос — а зачем, собственно, бизнесу нужен дизайн со всеми дизайнерами?
Если вы сейчас оживились и начали думать что-то в духе “ЧТОБЫ НАХОДИТЬ ИНСАЙТЫ НЕТРИВИАЛЬНЫЕ РЕШЕНИЯ ЗАБОТИТЬСЯ О ПОЛЬЗОВАТЕЛЯХ И ПРОЧ” — то с глобальной точки зрения вы, конечно, правы, но с точки зрения бизнеса это ничего не значащая мантра, которая не пытается говорить на языке ресурсов и цифр.
На самом деле, на этот вопрос есть четкий ответ: дизайн нужен бизнесу в первую очередь для того, чтобы минимизировать риски — а именно риски разработки (что впустую будет потрачено время, силы и деньги), риски репутационные (выкатим говно, за которое огребем), риски юридические (выкатим такую шляпу, которая нас под суд подведет) и прочие. Дизайн, с этой точки зрения, выступает важным гарантом того, что мы не творим херню.
Это рассуждение дает нам любопытное следствие: если дизайн направлен на то, чтобы минимизировать риски, то мы должны в первую очередь сфокусировать дизайн-усилия на высокорисковых областях, а низкорисковые области можем делать левой задней ногой по остаточному принципу.
В практическом плане мы должны действовать так: мы садимся с продуктом, смотрим на наши задачи и отвечаем по каждой из них на вопрос: “А что произойдет, если мы быстро выкатим голимое и не особо продуманное решение?”
Если дан ответ “Будет херово, потому что... <обоснованная причина>”, то мы заводим задачу по полноценному дизайн-процессу (исследования-концепции-макеты, Triple Diamond, все дела), высаживаем туда дефицитного дизайнера, действуем по-взрослому.
Если же ваш ответ “Да ничего страшного, на самом деле” или “Главное — чтобы быстро”, то это повод запустить дизайн-задачу по упрощенному процессу — например, сразу сажать дизайнера за макеты без согласований или вообще отдать интерфейсную задачу продакту с разработкой, оставив за дизайнером лишь точечный консалтинг (на уровне двух встреч — в самом начале и ближе к концу) и общий присмотр.
Обычно такой кейс востребован на не особо критичных MVP-запусках, мелких переделках, админках и фичах, нужных полутора пользователям. Главное — не терять влияния дизайнера полностью, но в целом его можно и нужно выпустить из дизайн-процесса, дизайн без дизайнеров тоже может существовать, пусть и в очень узких и контролируемых рамках.
(если вы на этих строках налились кровью и готовитесь гаркнуть “ДА С ХЕРА ЛИ ПРОДАКТ ЗАНИМАЕТСЯ ДИЗАЙНОМ”, то предлагаю вам почитать вот это рассуждение про продуктовый дизайн и продактов)
Этот ход рассуждений, кстати, помогает объяснить и еще один феномен — почему в b2b-решениях, как правило, требуется куда меньше дизайнеров, чем в b2c. Все просто: риски от выкатки плохого UX-решения не так фатальны (где бы мы потеряли в b2c пользователя - в b2b вызовем лишь глухое недовольство), а ценность от быстрой выкатки решения — запредельна. Соответственно, тактика деления дизайна на “экспресс” и классическую схему оправдывает себя в b2b полной мере.
Так что если вас поджали по дизайн-ресурсам — в любом случае не паникуйте и не падайте духом. При помощи описанной тактики вы можете снизить нагрузку на дизайн-ресурс, убрать эффект бутылочного горлышка и в моменте победить дефицит людей, не волнуя своего Главного Викентия Тиранославовича.
А вот про то, как его правильно взволновать — поговорим особо.
#батинаправда
Для начала нам уйти в теорию и ответить на вопрос — а зачем, собственно, бизнесу нужен дизайн со всеми дизайнерами?
Если вы сейчас оживились и начали думать что-то в духе “ЧТОБЫ НАХОДИТЬ ИНСАЙТЫ НЕТРИВИАЛЬНЫЕ РЕШЕНИЯ ЗАБОТИТЬСЯ О ПОЛЬЗОВАТЕЛЯХ И ПРОЧ” — то с глобальной точки зрения вы, конечно, правы, но с точки зрения бизнеса это ничего не значащая мантра, которая не пытается говорить на языке ресурсов и цифр.
На самом деле, на этот вопрос есть четкий ответ: дизайн нужен бизнесу в первую очередь для того, чтобы минимизировать риски — а именно риски разработки (что впустую будет потрачено время, силы и деньги), риски репутационные (выкатим говно, за которое огребем), риски юридические (выкатим такую шляпу, которая нас под суд подведет) и прочие. Дизайн, с этой точки зрения, выступает важным гарантом того, что мы не творим херню.
Это рассуждение дает нам любопытное следствие: если дизайн направлен на то, чтобы минимизировать риски, то мы должны в первую очередь сфокусировать дизайн-усилия на высокорисковых областях, а низкорисковые области можем делать левой задней ногой по остаточному принципу.
В практическом плане мы должны действовать так: мы садимся с продуктом, смотрим на наши задачи и отвечаем по каждой из них на вопрос: “А что произойдет, если мы быстро выкатим голимое и не особо продуманное решение?”
Если дан ответ “Будет херово, потому что... <обоснованная причина>”, то мы заводим задачу по полноценному дизайн-процессу (исследования-концепции-макеты, Triple Diamond, все дела), высаживаем туда дефицитного дизайнера, действуем по-взрослому.
Если же ваш ответ “Да ничего страшного, на самом деле” или “Главное — чтобы быстро”, то это повод запустить дизайн-задачу по упрощенному процессу — например, сразу сажать дизайнера за макеты без согласований или вообще отдать интерфейсную задачу продакту с разработкой, оставив за дизайнером лишь точечный консалтинг (на уровне двух встреч — в самом начале и ближе к концу) и общий присмотр.
Обычно такой кейс востребован на не особо критичных MVP-запусках, мелких переделках, админках и фичах, нужных полутора пользователям. Главное — не терять влияния дизайнера полностью, но в целом его можно и нужно выпустить из дизайн-процесса, дизайн без дизайнеров тоже может существовать, пусть и в очень узких и контролируемых рамках.
(если вы на этих строках налились кровью и готовитесь гаркнуть “ДА С ХЕРА ЛИ ПРОДАКТ ЗАНИМАЕТСЯ ДИЗАЙНОМ”, то предлагаю вам почитать вот это рассуждение про продуктовый дизайн и продактов)
Этот ход рассуждений, кстати, помогает объяснить и еще один феномен — почему в b2b-решениях, как правило, требуется куда меньше дизайнеров, чем в b2c. Все просто: риски от выкатки плохого UX-решения не так фатальны (где бы мы потеряли в b2c пользователя - в b2b вызовем лишь глухое недовольство), а ценность от быстрой выкатки решения — запредельна. Соответственно, тактика деления дизайна на “экспресс” и классическую схему оправдывает себя в b2b полной мере.
Так что если вас поджали по дизайн-ресурсам — в любом случае не паникуйте и не падайте духом. При помощи описанной тактики вы можете снизить нагрузку на дизайн-ресурс, убрать эффект бутылочного горлышка и в моменте победить дефицит людей, не волнуя своего Главного Викентия Тиранославовича.
А вот про то, как его правильно взволновать — поговорим особо.
#батинаправда