Московский: Дизайн & Тимлид

Дизайнер пишет про работу, заметки в телеге
Оглавление и об авторе

Матрица согласований

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

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

После этого интерфейс превращается в компромисс, пытающийся учесть всё и сразу.

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

У нас тоже были часовые общие синки: куча мнений, бесконечные согласования. Силы уходят не на продукт, а на отстаивание решений.

Нашёл для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть.

Выход — составить матрицу согласований

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

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

Как построить матрицу

Удобнее всего вести её в виде таблицы.

В ней фиксируются:

— Роль / должность;
— Заинтересованность — насколько человеку важна ваша работа и её результат (низкая, средняя или высокая);
— Мотивация — что человек получает от участия. Она может быть честная (результат), а может быть человеческая (самоутверждение, влияние);
— Насколько может повлиять? — от 1 до 5, где 1 — влияние минимально, а 5 — последнее слово;
— Текущий уровень доверия — низкий, нейтральный, средний, высокий. Есть ли напряжение в общении и затягивание согласования, или это «свой» человек;
— Заметки и риски — что важно помнить;
— Нужный уровень вовлечения по RACI — подробнее ниже.

Где тут наука

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

RACI-матрица помогает разделить роли:
Responsible — кто делает;
Accountable — кто принимает финальное решение;
Consulted — с кем консультируемся;
Informed — кого информируем.

Power—Interest Grid показывает, кого вовлекать глубже, а кого просто держать в курсе.
Salience Model учитывает влияние, легитимность и срочность требований.

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

Алгоритм по сборке

  1. Выпишите всех, кто комментирует / блокирует / одобряет дизайн (продакт, тимлид фронта, бэкенд, аналитик, редактор, исследователь, саппорт-лид, маркетинг и т. д.). Посмотрите орг-схему или историю согласований.
  2. Расставьте оценки по критериям: заинтересованность, мотивация, влияние и т. п. В файле в Фигме есть подсказки, чтобы делать это проще.
  3. По итогам оценок определите роль каждого участника по RACI.
    Сократите круг влияющих: оставьте ключевых A, остальным — C или I.

Для каждого участника нужен свой подход:

R — отвечает за выполнение (обычно дизайнер или тимлид).
A — участвует в согласовании с самого начала, ранние черновики, мини-синки, финальный апрув.
C — короткое информирование, ранний показ черновиков (например, для оценки реализуемости).
I — короткое информирование, регулярные демо.

Шаблон матрицы

Что это даёт?

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

Матрица также повышает эффективность: решения перестают «обстукивать» обо всех. Ответственность становится конкретной, а не размытой по всей команде.

Короч

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

Полезные ссылки

  1. RACI-матрица:
    Atlassian про RACI
  1. Power—Interest Grid:
    http://www.projectmanagement.com/wikis/368897/stakeholder-analysis--using-the-power-interest-grid
  1. Salience Model:
    https://projectmanagers.net/understanding-the-stakeholder-salience-model/

Интервью с победителем дизайн-конкурса Telegram: карьера в дизайне, профессиональный рост и путешествия

Поговорил с Кирилл Сидорец — победителем дизайн-конкурса Telegram про его карьеру, как он интересно и не стандартно начинал, где путешествовал и как работалось в МТС и VK, а теперь в The Open Platform

Подборка видео про презентации

Всем привет! Для презентации своих идей я использую Фигму. Это видео будет всем, кому нужно сделать презентацию.

В ходе урока мы сделаем 4 базовых слайда. Вы можете посмотреть по ссылке шаблон презентации и взять то, что вы хотите использовать. https://www.figma.com/community/file/1290426330962568110/presentation-template

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

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

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

8 частых ошибок дизайнеров в тестовом задании

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

Копировать и вставить — обновление Figma. Быстрый разбор новых возможностей

В этом видео я собрал самые важные изменение Фигмы при обновлении функции copy/paste: позиционирование вставляемого элемента, мульти-вставка, paste here, вставка с заменой, вставка в зону видимости. Во второй части рассказываю как копировать стили в figma, как скопировать «as PNG» и как SVG.

Горячие клавиши в Фигме, которые я использую: как запомнить и как работать быстро (Figma Hotkeys)

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

Исходник с презентацией

Figma: Интерактивные компоненты (бета)

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

Ненужные функции

В админке CRM wordpress есть выбор первого дня недели.

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

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

Выступления в финале на хакатоне от вконтакте

Участвовал в двухнедельном хакатоне от вконтакте. Наша команда заняла 6 место из 600+ команд. Для финала за сутки нужно было продумать и презентовать случайную и смешную тему. У нас было приложение с дополненной реальностью для занятий спортом диснеевских принцесс. Было весело делать и выступать.

Из полезного: можно посмотреть или скопировать презентацию в фигме (для просмотра нажмите плей)

Дизайн мобильных приложений. Летний интенсив в Британке

После обучения в Бюро Горбунова я хотел попасть на обучение в Британку. Это случилось на летнем интенсиве 2019. Расскажу про свой опыт и проект, который мы там делали.

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

В ходе обучение было весело, было сложно и было сжато. На что уходит месяц, нужно было сделать за 4 дня и применять новые знания, которые параллельно нам рассказывались.

На лекциях было много информации от разных спикеров.

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

Наша презентация не обошлась без юмора

Наш концепт Яндекс Почты

Один из слайдов из презентации

Мое мнение: на интенсив я пошел уже имея за плечами почти год работы в Яндексе. Там еще раз прошелся по знакомым темам и структурировал знания. Узнал, что-то новое, но многое уже знал. Плюс прокачал навык презентации. Новичкам советую. Ссылка на интенсивы

Как дизайнеру перестать думать статически

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

Образно, как я думал над макетом

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

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

Мой наставник по стажировке дал мне совет, в духе «начни представлять как будет работать интерфейс, что будет в динамике». Полностью прочувствовал этот совет совсем недавно :-)

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

Проектируется не страница, а история

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

Выводы: для проектирования интерфейсов представляйте как ваш интерфейс работает, как вы с ним взаимодействуете, прокрутите сценарий в голове от начала до конца. Все ли было окей? Где логика хромает? Если сложно представить, то поможет быстрый прототип в фигме, который можно дать «потыкать» кому-то ещё.

Проект Здоровье

Год назад принимал участие в интеграции приложения Яндекс Здоровье в приложение Яндекс . Задача заключалась в том, чтобы перевести функциональность приложения на новые компоненты и быстро запустить.

Посмотреть приложение можно внутри приложения Яндекс.
Ранее Ctrl + ↓