Подкаст в аудио формате

Качество пожал максимально чтобы получить 50 Мб из почти двухчасового видео. Вроде слушабельно.

Таймкоды:
00:07 Вступление
03:42 Метрики в B2C и B2B
12:40 Простые способы подсмотреть дизайн-решения конкурентов в B2B-сегменте
16:31 Где и как собирать данные в продукте
23:15 Насколько сложно в команде прокачать скиллы работы с аналитикой метрик
25:34 Что делать, чтобы начать получать данные метрик из аналитики
27:20 Об отсутствии мотивации работать с аналитикой у дизайнеров
30:35 О разнице приоритета данных между B2C и B2B
35:39 Почему важно думать про аналитику уже на этапе проектирования
41:50 Об эффективности дизайнера
46:30 На что чаще обращают внимание в CV и в портфолио дизайнеров
49:50 Что делать, если нет метрик для кейса в портфолио
54:15 Про фантастичность прямого влияния изменений в UI на бизнес-показатели
57:33 Можно ли судить о профессионализме дизайнера по портфолио
01:01:03 Про вайтборд челлендж
01:05:07 👉 Ищем дизайнеров продукта в Магнит
01:06:40 Почему мы в Магнит решили попробовать вайтборд челлендж
01:09:37 Как узнал про вайтборд челлендж и как его проводил
01:13:48 Можно ли вайтборд использовать как прокачку уже нанятых дизайнеров
01:18:42 Как давал обратную связь по вайтборд челленджу
01:21:50 О «Манго-академии»
01:22:54 Методология «насильного внедрения знаний»
01:24:48 Можно ли сформировать идеальную команду «заряженных» дизайнеров
01:27:22 Способы повышения общего уровня команды дизайна
01:36:10 Зарядить тех, кто не хочет заряжаться, можно лишь временно
01:38:34 Челлендж по замеру хард скиллов в Фигме и его влияние на команду
01:42:42 О балансе между зарплатой и интересом
01:46:18 Где дизайнеру начать карьеру: в студии, продукте или стартапе
01:49:29 Завершение


@designboat

Срок годности блюд

В комментариях к посту выше мне напомнили, что похожая фича уже давно есть у «Вкусвилл». А что насчёт срока годности продуктов? Такое вроде бы только у «Лавки». Очень актуальная и крутая фича👍


@designboat

Про DesignOps

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

Если обратиться к определениям и трактовке термина, к примеру, в этом, довольно полно описывающем суть вопроса цикле статей, станет понятно, что DesignOps — это отдел (один или несколько специалистов) в составе дизайн-департамента наравне с отделами продуктового и коммуникационного дизайна, исследователей и редакторов.

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

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


@designboat

Экраны ошибок

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

Ну и в целом, про проектирование экранов ошибок:

🔹Не забывать о всех корнерах, особенно про экраны ошибок. Даже синьоры косячат и пролюбливаются на этом очень часто. Хорошо, если экран ошибки сам по себе будет каким-то интересным в плане иллюстрации или анимации, что будет сглаживать негатив пользователя. Но это уже в доп. Минимум, на экране ошибки не должно быть такого хлама, бесконтрольно тянущегося с бэкенда;

🔹Проводить препрод дизайн-ревью перед каждым релизом. Желательно чтобы это было утверждённым процессом в команде;

🔹Совместно с редактором и иллюстратором периодически проводить ревизию экранов ошибок во всём приложении.

P.S.: спасибо подписчикам Захару и Сергею за то, что поправили меня в комментариях — благодаря вам отредактировал пост для более точной и корректной передачи мысли. Спасибо вам! 🤝


@designboat