Task → Solution

2021-08-26 10:34:22 ​​Войсчат #1

Хочу провести войсчат здесь, но темы пока нет. Поэтому предлагаю замутить AMA-сессию. Заполняйте гугл-форму своими вопросами. Если наберётся 10 штук — запланируем наш первый войсчат :)

https://forms.gle/V8Gerq5gKnh3gNqA6 Открыть/Комментировать

2021-08-25 11:45:07 ​​Обратная связь на VK Cup

На этих выходных прошёл финал VK Cup — кубок в нескольких дисциплинах, в том числе в дизайне. Мне посчастливилось вместе с Олей быть в жюри финала в прямой трансляции и пообщаться с финалистами.

Я, конечно, волновался, хоть и был в кадре второй раз (первый раз в прошлом году), но было интересно, задорно, весело и круто. А сейчас не об этом. Есть история, которая началась на прошлом VK Cup и продолжилась в текущем году — обратная связь в треке Design.

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

А в чём смысл? Как участники смогут вырасти, если их не критиковать?

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

Во-вторых, любая негативная обратная связь в 90% случаев воспринимается тяжело. Даже через 10 лет опыта. Чтобы этого избежать, нужно доверять человеку как профессионалу и самому её запрашивать (и это не всегда помогает). Новички точно расстроятся.

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

Ко всем работам на конкурсе есть вопросы: где-то типографика плохая, где-то сценарий мутный, композиция поплыла, задача решена странно или ещё что-то там. Если докапываться до мелочей — будем сидеть в лайве 10 часов и страдать, а мы хотим веселиться.

Приходите на следующий VK Cup в качестве участника или участницы.

(За фото спасибо Оле.) Открыть/Комментировать

2021-07-02 15:37:28 В трёх словах: лонгрид, дизайн-библиотека, ВКонтакте.

https://vc.ru/design/265595-publikuem-kanon-biblioteku-znaniy-dizaynerov-vkontakte Открыть/Комментировать

2021-05-25 17:15:16 Стажировка для продуктовых дизайнеров и дизайнерок

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

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

Подробности → https://vk.com/@vkteam-vkontakte-na-praktike-2021 Открыть/Комментировать

2021-05-25 12:00:33 Alfa Battle Camp

Альфа-Банк устраивает бесплатный летний кэмп для UX-исследователей и продакт-дизайнеров.

Сочи, море, сёрфинг, дизайн, брейнштормы и знакомство с профессионалами из Альфа-Банка и индустрии. Сценарий такой: зарегистрироваться и придумать идеи, как улучшить цифровые продукты банков; жюри собирает авторов в команды; команды в онлайне прокачивают свои решения; 50 лучших участников едут на море: сёрфить, отдыхать и защищать решения.

Всё бесплатно, нужно будет оплатить только дорогу до аэропорта в Москве.

Жюри — супер-известные люди: Александр Ковальский, Сергей Попков, Екатерина Лемма, Дмитрий Сатин и Дмитрий Карпов. На кэмпе вы окунётесь в правильную дизайнерскую среду и получите новые знакомства.

Регистрируйтесь → https://link.alfabattle.ru/4z6P3

#реклама Открыть/Комментировать

2021-05-15 22:25:43 Образ мышления и наставничество

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

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

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

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

Если ученик — новичок, то влияние наставника будет большое. И образ мышления будет передаваться почти без изменений. А если ученик поопытнее, с уже сформированным образом, то он просто доуточнит свою «картину мира».

Как это меня успокаивает? Задача перетекает из абстракции и идеализма в реальную форму: научить видеть задачу как я её вижу и мыслить о решении в моём ключе. Это проще.

Кстати, если кто-то ищет в свою команду стажёра, которая знает дизайн-процесс, умеет собирать прототипы, чуть-чуть исследовать и может показать интерфейс — пишите мне на @matthew. Открыть/Комментировать

2021-05-14 14:13:44 Рецепт: больше разговаривать (3/3)

Это главный способ, который позволяет:

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

Всё так просто. Наоборот тоже работает.

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

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

А потом (или уже) вы поймёте, что разговаривать можно не только с разработчиками, но и с менеджерами, тестировщиками, аналитиками, эйчарами и всеми-всеми! Софт-скиллы, ага. Только когда все говорят о софт-скиллах, не очень понятно, как их применить и к чему приводит их отстутствие. Теперь понятно? Открыть/Комментировать

2021-05-14 14:13:08 История про закрытость дизайнеров (2/3)

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

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

Это привело к тому, что многие дизайнерские идеи воспринимались в штыки. Почти каждое решение нужно было защищать перед командой, хотя я уверен, что дизайнер ответственен за интерфейс и имеет полное право продумывать его, а идеи и решения по-умолчанию хорошие (его же наняли и платят ему деньги). Если есть сомнения — нужно обсудить, но никак не строить процесс «сначала докажи, что кнопка должна быть такая».

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

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

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

Интересный факт. Теперь мы используем вопрос «что бы ты сделал(а), если разработчик говорит что макет сложны для реализации» в качестве маркера опыта кандидата. Те, кто уже поварились в сфере, знают, что отвечать. Открыть/Комментировать

2021-05-14 14:12:43 Так нужно или нет? (1/3)

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

Вот тут Серёжа Попов из Лиги А. рассказывает, почему он учит дизайнеров коду и что им это даёт (дизайнерам):

https://vc.ru/hr/242182-100-razrabotchikov-v-komande-i-obuchenie-dizaynerov-frontendu-intervyu-s-serezhey-popovym-rukovoditelem-liga-a

Роман Шамин из Злых Марсиан собрал два треда из твиттера в статьи. Оба крутые. Мы в ВК пользуемся прям всеми правилами оттуда и вам советуем:

https://teletype.in/@romanshamin/what-frontend-want-from-design

https://teletype.in/@romanshamin/what-design-want-from-frontend

Вдогонку к тредам Миша Озорнин поделился примером как выглядит хорошо оформленный макет:

http://mikeozornin.ru/blog/all/what-is-a-good-handoff/

Алексей показывает чек-лист по подготовке макетов для разработчиков (там засветилась наша дизайн-система). На самом деле это даже не чек-лист, а целый гайд, как оформлять макеты:

https://www.notion.so/5c03c7554ff542da9c77a6f420935282

Постик от Макса Десятых (ex. Роботы), в котором он делится приёмами, как подружить дизайнеров и разработчиков:

https://t.me/wannabelikerozov17feb/2439

И нельзя не вспомнить мою статью 2019 года, с жёлтушным заголовком (простите), но простой сутью (важен результат, а понимающий код дизайнер круто помогает его достичь):

https://designpub.ru/images-are-useless-f728cb8c1e39

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

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

2021-04-01 12:41:05 Немного деталей из статьи. Открыть/Комментировать