/designer

#снек 35. Продукт важнее инструментов Самый короткий путь к совершенствованию в дизайне — фокус на создании реального продукта, пусть несовершенного, пусть примитивного и ужасного, но зато реального. Это очень важная идея. Она пронизывает всю творческую деятельность, которой я занимался в жизни. Я вижу множество примеров как в дизайне, в разработке, так и в музыке. И мне потребовалось довольно много лет, чтобы по-настоящему понять её. Мы дизайнеры, потому что у нас есть наш продукт, наш дизайн. Вряд ли кто-то будет серьёзно воспринимать нас, если у нас нет ни одного макета, ни одного выполненного проекта. Любое обучение должно встраиваться в твой текущий проект. В противном случае открывается портал прокрастинации: «Ого! это любопытно, я изучу/скачаю это сейчас, а использую на каких-нибудь будущих проектах». Этого может никогда не случиться. Самостоятельно решить любую одну дизайн-задачу и сделать один макет гораздо важнее, чем лично посетить WWDC, прочитать 10 книг о дизайне, поставить 100 плагинов для Figma и запиратить 10 000 шрифтов. Даже если ширфты будут с поддержкой кириллицы. Никакие инструменты без действия не сделают из тебя творческую единицу. Чтобы сделать дизайн-решение, не нужно знать, кто такой Массимо Виньелли, какова философия дизайна Германа Цапфа. Это можно узнать позже, а затем улучшить твоё решение, сделать новую версию. Самостоятельно забилдить первое iOS-приложение и увидеть слово «Привет» на твоей тестовой сборке Single Page Application гораздо важнее, чем посмотреть сотни видео в библиотеке Apple Developer, не забилдив ни одного. Зарендерить свою кривую модель и получить финальное изображение на твоём рабочем столе важнее, чем просмотреть тысячу роликов на ютюбе по партиклам и материалам, важнее покупки любого курса по 3D. Во всех треках обучения чему-то творческому в первую очередь нужно определять прямой путь между первым шагом и финальным продуктом, который ты сможешь демонстрировать людям. Когда есть продукт, всё обучение можно встроить в пайплайн где-то между командами New Project и Export. Главное, чтобы ты всё-таки когда-нибудь нажал Export/Build/Render, выложил кейс в портфолио или отдал свои макеты в разработку. @slashdesigner #для_профи #майндсет

#стрим Начинаем открытую сессию с Натальей, в котором разберём её портфолио и поговорим о переходе из графического дизайна в UX/UI. https://us06web.zoom.us/j/88594695674 @slashdesigner #первые_шаги

#анонс #стрим Открытая сессия 4. Разбор портфолио 7 мая в 19:00 по Алматы (GMT+5) проведём очередную открытую менторскую сессию по продуктовому дизайну. На этот раз у нас в гостях будет графический дизайнер Наталья, которая хочет найти работу в продукте. Бережно разберём портфолио и обсудим возможности. Наталья отучилась в Uprock на Webdesign и недавно закончила Mobile Pro. Запрос

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

Напомню, что первый стрим был на похожую тему, но каждый соискатель индивидуален и наверняка сможем избежать повторения. Ссылка на Zoom появится в этом канале перед стримом. Запись будет выложена на YouTube /designer. @slashdesigner #первые_шаги #менторство

#снек 34. Об ошибках в логике, чудовищный пример из Notion Я был бы рад, если этот пост смог предотвратить аналогичную ситуацию у кого-нибудь ещё. Самые трудноуловимые ошибки, которые встречаются в интерфейсах — это ошибки в логике. Они не дают явной индикации, что в системе произошло что-то непредсказуемое и чаще всего дизайнеры не способны их отловить. Такие ошибки просто происходят и могут вызывать серьёзные последствия, вплоть до потери данных и времени. Поэтому так важен этап тестирования и пилотные запуски. В этом посте я хочу подчеркнуть важность работы тестировщиков, поскольку они способны исправить любые типы ошибок и предотвращают колоссальные страдания пользователей. Хочу поделиться редким примером серьёзной логической ошибки в интерфейсе, который я встретил впервые и которую не смогли отследить тестировщики Notion. Она привела к порче трёх моих канбан-досок и стоила мне многих часов исправления. Я не понимал, что является тригером ошибки. При помощи функции Parenting в базе данных можно связывать записи в иерархические структуры, где есть родительский проект и его подзадачи. В карточке задачи можно настроить вывод родительского проекта. При взгляде на тикет это удобно освежает в памяти его контекст. Также на доске помимо задач можно выводить и сами проекты через функцию Grouping, управляя проектами также как задачами. Всё было хорошо, пока я не принял решения привести в порядок уровень проектов и актуализировать их статусы. Ситуацию усугубило то, что я распространил такую организацию на все свои доски. В чём ошибка: если мы двигаем карточки проектов и меняем статусы, то статусы задач в этих проектах тоже обновляются. Смотри видео выше. Когда в базе данных 500 тикетов и пара десятков проектов, крайне неочевидно, что вслед за проектом задачи тоже меняют статус. В том числе те, которые уже год как были выполнены и архивированы. Вдруг стали всплывать давным-давно закрытые тикеты и досками стало пользоваться совершенно невозможно. Техподдержка предложила переключать статус проекта, проваливаясь в него, что гораздо менее удобно, чем перетаскивать тикеты. Итог: Хотя функция Parenting в Notion очень удобна при работе с гантами в Timeline View, для канбан-досок ей пользоваться я бы пока не стал. @slashdesigner #Notion #для_профи

Про наш чат «Что за шрифт?» Лучшая реклама нашего чата @whatthefontt — это график его органического роста. Так уверенно не рос даже @figmachat. Готов спорить, что этот чат его обгонит. В основе простая и эффективная механика: не знаешь, что за шрифт — скидываешь картинку в чат, коллективный разум отвечает. С другой стороны, можно отточить свои дизайнерские навыки и попрактиковаться в распознавании шрифтов. Так можно найти что-то неожиданное, наткнувшись на красивую надпись на чьём-нибудь случайном скриншоте. Мы с командой запустили его в августе 2022 и с тех пор он набрал уже 7000+ участников. Более 5000 раз в разных формах участники благодарили друг друга, когда им кто-то помог. Как и всегда, у нас довольно строгая модерация, разговариваем только про типографику. Сквозь все наши чаты работает единый бот @slashdbot, который лишает голоса, если нарушаешь правила. Можно до трёх раз возвращать себе голос самостоятельно. Вступить: @whatthefontt @slashdesigner #типографика #чаты

#снек 33. Зачем нужен продукт оунер Свежий кейс от менти, дизайн-лида, по горячим следам в пятницу вечером. В некоем продукте есть дизайн-команда. А есть SMM Иван, который врывается в планировщик дизайнеров и ставит задачи в пятницу вечером, со сроком в понедельник-утро, аргументируя это тем, что это очень нужно сделать, потому что так сказали топы, инвесторы или активные хейтеры в соцсетях. Все уже устали от его срочных задач, но не отказывать же, ведь мы все вместе одно дело делаем. Ответ кажется очевидным, но в реальных условиях далеко не так просто говорить «нет», особенно, когда Иван обладает уверенным тоном поэта Бездомного. Сам видел такие ситуации в разных компаниях несколько раз. Решение У каждой организованной группы человеческих особей есть лидер, который принимает ключевые решения об общем движении. В коммерческих компаниях обычно он платит, либо распоряжается имеющимся у него бюджетом. Также отвечает за критерии оценки результата, по которым тот будет считаться успешным. Вот два явных признака власти. Через это уравнение люди организуются в команду. В нашем кейсе сломан процесс постановки задач и иерархия, потому что в лабиринтах быстро выросшей IT-компании непонятно кто смог ворваться и начать диктовать свои потребности. Важность задач должен валидировать оунер продукта, который отвечает за распределение доступных ему ресурсов. Он же обычно и является оунером бэклога, в который могут поступать задачи. Инвесторы и даже пользователи напрямую не принимают решений о приоритетах задач дизайн-команды, это право продакта или того, кто выполняет его функцию. Да, бывают разные инвесторы, но даже если это основатель компании, продакт должен быть как минимум в курсе, что команда временно перешла на ручное управление. Своими действиями Иван ворует ресурс у настоящего оунера, который может быть и не в курсе, что в его команду кто-то прибежал и всех запряг. Тем более дизайнеры по поводу требований Ивана могут ничего не предпринимать, но они явно должны получить этот иммунитет от лида. Потому что линейный сотрудник не обязан вникать во всю иерархию компании, он будет смотреть только на своего непосредственного руководителя. Ретивому Ивану можно ответить: «Я понимаю, что ты ратуешь за продукт, но давай всё-таки соблюдать рамки друг друга. Желаю тебе спокойной ночи, до понедельника. В начале рабочего дня я согласую твою важную задачу с [оунером] и тогда он примет взвешенное решение, стоит ли сдвигать все наши планы ради твоей задачи.» Хороших выходных! Не засиживайся на работе и не позволяй другим отнимать у тебя твои выходные. @slashdesigner #для_профи #стать_лидом

Сегодня регулярную открытую сессию пропустим, но завтра вечером будет любопытный стрим от Think UX про исследования и AI. @slashdesigner #первые_шаги #исследования #AI

Всем привет! А у нас первый спикер в рубрике Think UX Talks! Уже в этот четверг, 25 апреля в 18.00 (UTC+5) Илона Методиева расскажет об использовании ИИ и телеграм бота для UX исследований и рекрутинга респондентов. На встрече вы узнаете, как сделать собственного телеграмм бота, набрать базу потенциальных респондентов в нем, встроить в него нейронную сеть, создавать и тестировать гипотезы в режиме реального времени. Ссылка на регистрацию: https://wearecommunity.io/events/lKG43oHShr