Дима десигн

Тестирую генерацию плагинов Последние погода занимался созданием плагинов в Cursor'е, а сейчас решил попробовать новую функцию фигмы. По итогу за 15 мин сделал рабочий плагин, который генерирует ключевые слова для компонентов с иконками (чтобы легче их искать было), причем с учетом того, что иконки у имеют несколько компонентов в зависимости от размера

Навайбкодил первый плагин Недавно сел изучать тему вайбкодинга, и только начал смотреть первые уроки по написанию промтов. Но, я не люблю теорию, проще все осваивать на практике. И тут подвернулся срочный рабочий кейс: нужно было импортировать в фигму 1000+ иконок, а встроенный drag'n'drop стал терять огромную часть файлов при переносе. В итоге за 30 мин сделал плагин, который решает этот вопрос. Это действительно новая эра в решении задач. В будущем буду освещать это подробнее, как это все делать, тема актуальная

Нейросети нас заменят Недавно обсуждали эту тему внутри команды, и что пора потихоньку учиться укладывать плитку. Я думаю, что нейросети возьмут часть более рутинных процессов на себя, а сильные продуктовые дизайнеры превратятся в модераторов результатов их работы. При этом, большая часть специалистов (60-70%), которые, скажем так, не сильно любят думать о качестве того что они делают, действительно могут лишиться работы. Основным критерием того, останетесь ли вы у дел, заключается в том, может ли вашу работу заменить нейросеть: если заказчик/менеджер проекта даёт вам задачу и результат который он получает не будет сильно отличаться от того что ему выдаст условный ChatGPT, то зачем ему вы? Когда смотришь на немалую часть продуктов, возникает вопрос: человек, который это проектировал, он вообще думал о том, как этим будут пользоваться? Дизайнер должен тщательно продумывать взаимодействие с продуктом, его механику, и регулярно задавать себе вопрос: «А не х*йню ли я делаю?» Но, многие любят вслепую собирать макеты по ТЗ, не сильно углубляясь, превращая свою работу в конвейер примитивных типовых сценариев и экранов. А конвейер автоматизируют, даже не сомневайтесь.

Дорожки на снегу В проектировании городов есть понятие birdshit архитектуры — архитектура голубиного помёта. Это когда со спутника выглядит красиво, но на уровне человека совершенно неудобно. Нам, жителям постсоветских пространств, это особенно знакомо. Классический пример — пешеходные дорожки, когда люди вместо хождения по красивым и геометричным (на плане у проектировщика) маршрутам протаптывают тропинки там, где им удобно. Какой есть простой способ спланировать действительно удобные дорожки? Наступает зима, выпадает снег, и вы просто смотрите как ходят люди в реальности, а уже потом по этим маршрутам кладете свою плитку, асфальт, или что там у вас. Эту практику у нас пробовали в советское время в некоторых локациях, и она себя хорошо показала. Жаль, массовой не стала. К чему было это предисловие? К тому, что это же принципа иногда полезно придерживаться в построении и стандартизации ваших процессов в команде: вы не пытаетесь придумать тот или иной рабочий процесс из вакуума, а берете за основу существующее взаимодействие, которое строилось по «наитию», только исправляете самые краеугольные камни и всё. Не раз наблюдал, когда процессы в командах пытались строить с чистого листа, без учёта сложившейся практики, а они потом, внезапно, не приживались, потому что были сильно оторваны от того, как в реальности взаимодействуют люди.

Почему время специалистов на созвоны — бесплатное? Бесконечные пустые обсуждения — бич индустрии. Ситуация: четыре человека собираются на получасовой созвон, чтобы обсудить, кому поручить задачку, которую делать 15 минут. При этом тот, кто может ее сделать — среди них. Да, вместо траты времени нескольких спецов можно одному из них поручить эту задачу на 15 минут (а оно так и вышло). Но его время «дорогое», когда речь идёт о задачах, но бесплатное, когда нужен созвон. Почему стандартом является то, что полезность выделения ресурса на обсуждения никто вообще не считает?)

25 октября в 14:00 впервые выступаю в родном городе на AAA Conf Буду рассказывать о том, что дизайнер — больше инженер, чем художник. — Взаимодействие дизайнеров с другими специалистами в продуктовом процессе — Как мы повысили проработанность макетов и уменьшили боль разработки — Грань творчества: баланс между унифицированными решениями и кастомом — Документирование изменений в макетах — Создание плагинов и шаблонов для процессов — Внедрение дизайн-ревью в продуктовый процесс

Как сделать тёмную тему в дизайн-системе? Самый простой для дизайнера и для фронта варианта реализации - использовать две таблицы цветов. Смена темы происходит путем замены одной таблицы на другую. Это позволяет в один клик менять тему на макетах дизайнеру…

Как сделать тёмную тему в дизайн-системе? Самый простой для дизайнера и для фронта варианта реализации - использовать две таблицы цветов. Смена темы происходит путем замены одной таблицы на другую. Это позволяет в один клик менять тему на макетах дизайнеру, а разработчик в принципе не задумывается о темной теме. Как легко реализовать в Figma 1. Создаешь свою палитру цветов через Variables в Figma 2. Необходимо сделать два цветовых режима: например, Light и Dark 3. Прописываешь код каждого цвета для тёмной темы . Например: у переменной Text в светлой теме код 1F1F1F1, а в темной FFFFFF. В данном случае текст будет инвертироваться 4. Применяешь к макету переменную Theme в режиме Dark и радуешься Реализация на фронте Создается CSS таблица цветов с переменными, далее такой же принцип по замене одной таблицы на другую, как и в случае с режимами в Figma В следующем посте расскажу подробнее про группы цветов

Расфокус и внимание За несколько лет не нашел ничего лучше, чем техника Помодоро для работы. Что она из себя представляет? Ты работаешь кругами работа-отдых. Классический пример такого цикла: 25 минут работы, 5 минут отдыха. Но, это просто шаблон, не все могут даже 25 минут держать внимание, учитывая современное обилие соцсетей и легкого дофамина от ленты с рилсами. Можно пробовать 20 минут работы и 7 отдыха, можно наоборот 40 работы и 3 отдыха, можно экспериментировать. Самое важное: во время цикла работы отключить все, что отвлекает. Максимум музыка, и то, если задача рутинная и не требует размышлений, к примеру, сборка адаптивов. Во время отдыха - отойти от компа. Взгляд в окно, игра на гитаре, игольчатый коврик, да что угодно. Главное - переключить внимание. Для помодоро полно приложений на любую платформу, а также есть такой сайт

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

27 сентября рассказываю про дизайн-систему на конференции Стачка в Питере - Для чего на самом деле нужна дизайн-система - Как подружить дизайн и фронт - Автоматизация процессов - Не только лишь дизайнеры собирают дизайн Время начала: 14:50 Зал : Дизайн

Не как у всех Нередко как у начинающих дизайнеров, так и у далеко не начинающих заказчиков возникает заветная идея сделать уникальное решение, не оглядываясь на сложившиеся паттерны на рынке. Если действительно на рынке годных решений нет (но согласитесь…

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

Сделай свое хобби - работой, и не будешь работать ни дня в своей жизни (с) Думаю, вы не раз слышали эту романтичную фразу. Ее проблема в том, что любой труд подразумевает под собой обязательства, преодоление своей лени и желания вести праздный образ жизни. И речь не только о работе. Много вы знаете успешных людей, которые придерживаются концепции вечного кайфа? Я ни одного. Всем приходится хоть иногда, но быть трудяжками. Даже рисуя проект "в кайф" для портфолио вам придется делать какую-то скучную, нудную для вас его часть. А в коммерческой работе рутина - это практически всегда неотьемлимая часть деятельности. А если говорить не просто о работе, а о развитии, то решение новых для себя задач часто проходит через стресс. Да, потом будет кайф при успешном результате. Но до него ещё нужно дойти. Уберите из уравнения своей карьеры вечный поиск мифического вдохновения и удовольствия, и все встанет на свои места. Чтобы не разочаровываться - не надо очаровываться (с)

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

Концепция Local Talent Опрозрачить дизайн индустрию в России. Кто и как работает в дизайне, сколько зарабатывает, как работает и как пришел к этому. Формат Анонимные истории дизайнеров собираются через вот эту форму — Анонимная форма Пожалуйста, поделись и ты своей историей Я публикую эти истории в канал, чтобы рынок знал реальные кейсы, а не пьяные рассказы, намешанные с мифами Проект Воркель Влада @designvorkel.

Хорошая идея для понимания рынка

Конечный продукт дизайнера Существует ошибочное мнение, что итогом работы дизайнера является макет, пусть даже с миллионом состояний, в общем что-то хорошо подготовленное для передачи в аналитику, разработку. Большинство проблем в продакшене рождаются из…

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