Функции дизайн-системы
Хочется продолжить брюзжание на тему дизайн-систем. Обычно я делюсь мыслями, исходя из реального рабочего процесса, но сейчас, будучи безработным, возьму материал из собеседований. 😁
Недавно, рассказывая о своих дизайн-системах, столкнулся с удивлённой реакцией: у меня в документации подробно описаны свойства и поведение компонентов, но нет чёткого указания, когда и как их использовать. Например, чем чекбокс отличается от свитчера? Или насколько «зелёную» кнопку должен выбрать дизайнер? Как же дизайнер поймёт, что ему делать?
Причина простая — такой потребности просто не возникало. Дизайн-система для меня — это инструмент, а не диктатура. Я никогда не стремился бить дизайнеров по рукам, навязывая им, как именно им делать свою работу. Ответственность за пользовательский опыт и принятие решений лежит на продуктовых дизайнерах. Ну и общее правило, которое я подрезал у знакомого разработчика, и постоянно цитирую: «Миром правит любовь, в её отсутствие — здравый смысл».
Поэтому меня искренне удивило, что именно этого ждали от дизайнера ДС. Более того, с предыдущим кандидатом, как оказалось, попрощались именно из-за того, что он не определял сценарии применения компонентов. Ну и совсем меня убило: рекрутер сделал вывод, что раз я не описал правила использования, значит, сам их не знаю. 🤯
Мне повезло: во всех компаниях, где я строил ДС, я параллельно либо лидил продуктовых дизайнеров, либо возглавлял всё дизайн-направление. Это позволяло настраивать процессы так, что за качество пользовательского опыта всегда отвечали именно продуктовые дизайнеры. Ведь если дизайнер ДС берёт на себя ещё и проработку всех сценариев, то либо их (дизайнеров ДС) рано или поздно станет практически столько же, сколько продуктовых дизайнеров, либо система превращается в ограничивающий инструмент. В итоге — узкие горлышки, нехватка компонентов, невозможность сделать хорошо, а только «как позволяет система».
При этом я вовсе не против best practices и гайдов по использованию прямо в документации ДС. Особенно если продуктовым дизайнерам удобно получать информацию там. Но источник этих знаний должен быть в продуктовых командах, а не исключительно в голове дизайнера ДС.
А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать?
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Хочется продолжить брюзжание на тему дизайн-систем. Обычно я делюсь мыслями, исходя из реального рабочего процесса, но сейчас, будучи безработным, возьму материал из собеседований. 😁
Недавно, рассказывая о своих дизайн-системах, столкнулся с удивлённой реакцией: у меня в документации подробно описаны свойства и поведение компонентов, но нет чёткого указания, когда и как их использовать. Например, чем чекбокс отличается от свитчера? Или насколько «зелёную» кнопку должен выбрать дизайнер? Как же дизайнер поймёт, что ему делать?
Причина простая — такой потребности просто не возникало. Дизайн-система для меня — это инструмент, а не диктатура. Я никогда не стремился бить дизайнеров по рукам, навязывая им, как именно им делать свою работу. Ответственность за пользовательский опыт и принятие решений лежит на продуктовых дизайнерах. Ну и общее правило, которое я подрезал у знакомого разработчика, и постоянно цитирую: «Миром правит любовь, в её отсутствие — здравый смысл».
Поэтому меня искренне удивило, что именно этого ждали от дизайнера ДС. Более того, с предыдущим кандидатом, как оказалось, попрощались именно из-за того, что он не определял сценарии применения компонентов. Ну и совсем меня убило: рекрутер сделал вывод, что раз я не описал правила использования, значит, сам их не знаю. 🤯
Мне повезло: во всех компаниях, где я строил ДС, я параллельно либо лидил продуктовых дизайнеров, либо возглавлял всё дизайн-направление. Это позволяло настраивать процессы так, что за качество пользовательского опыта всегда отвечали именно продуктовые дизайнеры. Ведь если дизайнер ДС берёт на себя ещё и проработку всех сценариев, то либо их (дизайнеров ДС) рано или поздно станет практически столько же, сколько продуктовых дизайнеров, либо система превращается в ограничивающий инструмент. В итоге — узкие горлышки, нехватка компонентов, невозможность сделать хорошо, а только «как позволяет система».
При этом я вовсе не против best practices и гайдов по использованию прямо в документации ДС. Особенно если продуктовым дизайнерам удобно получать информацию там. Но источник этих знаний должен быть в продуктовых командах, а не исключительно в голове дизайнера ДС.
А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать?
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Экспериментальный формат!
Связь дизайна с разработкой и мышление при проектировании компонентов — одни из самых недооценённых тем. Чаще всего материалы дизайнеров заканчиваются в Figma, но сегодня попробуем зайти дальше: сначала спроектируем решение, а затем посмотрим, как оно превращается в код.
Покажет, что происходит с дизайном по ту сторону кода, мой давний коллега, разработчик с огромным опытом, с которым мы вместе построили не одну дизайн-систему — Сергей Азаров (подписывайтесь на его канал).
🔹 О видео
Идея родилась спонтанно, из запроса нашего общего коллеги. Без сложного продакшна решили проверить, интересно ли кому-то будет наблюдать за нашим ходом мыслей. Поэтому будем очень благодарны за фидбек: стоит ли развивать формат, какие темы хотелось бы разобрать в следующих выпусках?
🔹 Стрим?
Во время записи меня посетила мысль: а что если сделать из этого прямой эфир? Заранее выбирать тему/задачу, собирать зрителей, вовлекать вас в процесс через вопросы. Если такая идея вам откликается — напишите, интересно ли было бы прийти на такой стрим.
Смотреть в ВК | Смотреть на Дзене
Связь дизайна с разработкой и мышление при проектировании компонентов — одни из самых недооценённых тем. Чаще всего материалы дизайнеров заканчиваются в Figma, но сегодня попробуем зайти дальше: сначала спроектируем решение, а затем посмотрим, как оно превращается в код.
Покажет, что происходит с дизайном по ту сторону кода, мой давний коллега, разработчик с огромным опытом, с которым мы вместе построили не одну дизайн-систему — Сергей Азаров (подписывайтесь на его канал).
🔹 О видео
Идея родилась спонтанно, из запроса нашего общего коллеги. Без сложного продакшна решили проверить, интересно ли кому-то будет наблюдать за нашим ходом мыслей. Поэтому будем очень благодарны за фидбек: стоит ли развивать формат, какие темы хотелось бы разобрать в следующих выпусках?
🔹 Стрим?
Во время записи меня посетила мысль: а что если сделать из этого прямой эфир? Заранее выбирать тему/задачу, собирать зрителей, вовлекать вас в процесс через вопросы. Если такая идея вам откликается — напишите, интересно ли было бы прийти на такой стрим.
Смотреть в ВК | Смотреть на Дзене
VK Видео
Привет, Сергей! Выпуск 1 - виджет звонка.
Связь дизайна с разработкой и мышление при проектировании компонентов — одни из самых недооценённых тем. Чаще всего материалы дизайнеров заканчиваются в Figma, но сегодня попробуем зайти дальше: сначала спроектируем решение, а затем посмотрим, как оно превращается…
🔥16🤯3
Библиотека иконок дизайн-системы в Figma
Тема казалась мне слишком очевидной, но наткнулся на несколько статей на Хабре, где советовали складывать все иконки в один мастер-компонент через варианты. Более того, на мой комментарий в духе «Вы что творите?» откликнулась целая армия защитников такого подхода. Особенно впечатлил аргумент: «...особенно удобно в больших дизайн-системах...»🤦♂️
Ну… кажется, автор этого комментария не работал с по-настоящему большой системой. Хотелось бы взглянуть на 1000+ иконок, организованных таким образом, да ещё и с разными размерами и стилями начертания.
Если у вас тоже закралась мысль сложить все иконки в варианты — не надо так!
Первая и главная проблема в том, что такие иконки нельзя будет нормально искать при замене. Когда их становится много, а дизайнеров хотя бы 3–5 в команде, поиск превращается в бесконечный скролл вариантов. В случае же отдельных мастер-компонентов можно искать иконки не только по названию, но и по описанию (description), добавляя туда ключевые слова, в том числе на русском, что сильно облегчает навигацию.
Выбор иконок через панель свойств можно настроить через swap instance, вынеся пропсу в свойства компонента и привязав её к нужному элементу. Варианты уместны, но только в рамках одной иконки — например, для размеров, начертаний контуром или с заливкой. При этом важно, чтобы единообразие сохранялось для всех иконок библиотеки. Но объединять разные иконки в один компонент с вариантами — плохая идея.
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Тема казалась мне слишком очевидной, но наткнулся на несколько статей на Хабре, где советовали складывать все иконки в один мастер-компонент через варианты. Более того, на мой комментарий в духе «Вы что творите?» откликнулась целая армия защитников такого подхода. Особенно впечатлил аргумент: «...особенно удобно в больших дизайн-системах...»
Ну… кажется, автор этого комментария не работал с по-настоящему большой системой. Хотелось бы взглянуть на 1000+ иконок, организованных таким образом, да ещё и с разными размерами и стилями начертания.
Если у вас тоже закралась мысль сложить все иконки в варианты — не надо так!
Первая и главная проблема в том, что такие иконки нельзя будет нормально искать при замене. Когда их становится много, а дизайнеров хотя бы 3–5 в команде, поиск превращается в бесконечный скролл вариантов. В случае же отдельных мастер-компонентов можно искать иконки не только по названию, но и по описанию (description), добавляя туда ключевые слова, в том числе на русском, что сильно облегчает навигацию.
Выбор иконок через панель свойств можно настроить через swap instance, вынеся пропсу в свойства компонента и привязав её к нужному элементу. Варианты уместны, но только в рамках одной иконки — например, для размеров, начертаний контуром или с заливкой. При этом важно, чтобы единообразие сохранялось для всех иконок библиотеки. Но объединять разные иконки в один компонент с вариантами — плохая идея.
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21💯4👀2🙈1
Недавно со мной произошёл, пожалуй, самый странный случай на пути поиска работы. После собеседования в Авито вместо оффера мне прислали... приглашение бухать на вечеринку для дизайн-директоров и лидеров в дизайне - Avito immersive rout 😄
Темой была эпоха Шекспира, но в итоге почти все пришли в чёрном, так что атмосфера больше напоминала вампирский шабаш. 🧛🏻
Проходило всё в Особняке Леман.
Впечатления — огонь! Атмосферно, весело, да ещё и вкусно кормят. 😁
Особенно круто было познакомиться с другими дизайн-лидерами, встретить тех, чьи публикации читаю сам, и пообщаться со старыми знакомыми.
Заодно получилось небольшое мини-исследование: знают ли меня в таком интересном кругу? Оказалось, да, и это приятно! ☺️ Кто-то как «артдира из ВкусВилла», кто-то как «того чела с SDUI», а кто-то даже узнавал в лицо и по имени.
P.S. Отдельный квест — искать в Москве аксессуары для костюма. В итоге удалось раздобыть жабо и крайне стильные очки. 😎
Темой была эпоха Шекспира, но в итоге почти все пришли в чёрном, так что атмосфера больше напоминала вампирский шабаш. 🧛🏻
Проходило всё в Особняке Леман.
Впечатления — огонь! Атмосферно, весело, да ещё и вкусно кормят. 😁
Особенно круто было познакомиться с другими дизайн-лидерами, встретить тех, чьи публикации читаю сам, и пообщаться со старыми знакомыми.
Заодно получилось небольшое мини-исследование: знают ли меня в таком интересном кругу? Оказалось, да, и это приятно! ☺️ Кто-то как «артдира из ВкусВилла», кто-то как «того чела с SDUI», а кто-то даже узнавал в лицо и по имени.
P.S. Отдельный квест — искать в Москве аксессуары для костюма. В итоге удалось раздобыть жабо и крайне стильные очки. 😎
🔥30
Наткнулся на статью: в Salesforce Lightning — тех самых, для которых Jina Anne ещё в 2014 придумала концепцию дизайн-токенов — решили отказаться от самого термина. Сконцентрировались на CSS-переменных и считают, что грядущая спецификация W3C слишком сложная и движется не в ту сторону.
Это мне напомнило, как во времена хайпа вокруг performance review один из авторов метода позже сам признал его неэффективным.
Как бы там ни было, забавно наблюдать, как все бегают с токенами как с торбой, и ждут что W3C спасет мир от хаоса, а потом читаешь вот такое 😁
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Это мне напомнило, как во времена хайпа вокруг performance review один из авторов метода позже сам признал его неэффективным.
Как бы там ни было, забавно наблюдать, как все бегают с токенами как с торбой, и ждут что W3C спасет мир от хаоса, а потом читаешь вот такое 😁
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
D'AMATO
Avoiding tokens
The importance of disclosing the reasons behind decisions.
😁6
Тестовое... Опять...
Я уже делился своим мнением, почему не использую тестовые задания при найме и сам редко делаю.
Но реальность такова, что с тестовыми всё равно сталкиваешься. И тут закономерный вопрос:
Как понять, каким должен быть результат, чтобы вот точно пройти?
Ответ: никак. 🤷🏻♂️
Часто даже сами наниматели не до конца понимают, что хотят увидеть. Плюс задания бывают абстрактными, с внутренними противоречиями и размытым фокусом.
Недавний пример — тестовое на позицию лида дизайн-системы.
Сначала вопрос: «Команда хочет какой-то неведомый компонент. Как будете собирать и обрабатывать требования?»
Следом: «Сделайте этот компонент в Figma».
Но, Карл, ты же сам только что сказал, требований пока даже нет... Что тогда я должен сделать-то?😔
Как быть?
Если есть возможность — задавайте вопросы. Выясняйте, что от вас ждут, какие критерии успеха, есть ли чеклист.
Во ВкусВилле на вайтбордах я, например, всегда проговаривал, что смотрю в первую очередь на мышление и пользовательский путь. А UI — если успеем.
В других компаниях может быть наоборот: фокус на крутой UI. Сделаешь идеальный UX, но провалишь визуал — отказ.
Если вдруг у вас есть знакомые внутри компании, куда вы проходите тестирование — спросите у них, какие стандарты, на что смотрят, как вообще принято оформлять задачи. Это даст хоть какой-то ориентир.
Если никакой информации нет — делайте так, как вы бы делали это в реальной работе. Максимально естественно и честно. В худшем случае просто не совпадёте ожиданиями нанимателя — это нормально.
Отдельная история — когда наниматели сами не знают, чего хотят. Я бы даже не тратил время. У меня были коллеги, которые отбирали людей по принципу «огонь/не огонь» и не могли объяснить, почему. Пройти такой отбор — это реально рулетка.
Ну и ещё. Я не верю в тестовые с ментором — за исключением стажеров и джунов. На старте ментор может помочь структурировать мысли, дать шаблоны, подтянуть результат. Но если у вас уже приличный опыт, ментор может, наоборот, сбить. Он будет транслировать своё видение, а вы бы, возможно, сделали лучше, если бы опирались только на своё.
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Я уже делился своим мнением, почему не использую тестовые задания при найме и сам редко делаю.
Но реальность такова, что с тестовыми всё равно сталкиваешься. И тут закономерный вопрос:
Как понять, каким должен быть результат, чтобы вот точно пройти?
Ответ:
Часто даже сами наниматели не до конца понимают, что хотят увидеть. Плюс задания бывают абстрактными, с внутренними противоречиями и размытым фокусом.
Недавний пример — тестовое на позицию лида дизайн-системы.
Сначала вопрос: «Команда хочет какой-то неведомый компонент. Как будете собирать и обрабатывать требования?»
Следом: «Сделайте этот компонент в Figma».
Но, Карл, ты же сам только что сказал, требований пока даже нет... Что тогда я должен сделать-то?
Как быть?
Если есть возможность — задавайте вопросы. Выясняйте, что от вас ждут, какие критерии успеха, есть ли чеклист.
Во ВкусВилле на вайтбордах я, например, всегда проговаривал, что смотрю в первую очередь на мышление и пользовательский путь. А UI — если успеем.
В других компаниях может быть наоборот: фокус на крутой UI. Сделаешь идеальный UX, но провалишь визуал — отказ.
Если вдруг у вас есть знакомые внутри компании, куда вы проходите тестирование — спросите у них, какие стандарты, на что смотрят, как вообще принято оформлять задачи. Это даст хоть какой-то ориентир.
Если никакой информации нет — делайте так, как вы бы делали это в реальной работе. Максимально естественно и честно. В худшем случае просто не совпадёте ожиданиями нанимателя — это нормально.
Отдельная история — когда наниматели сами не знают, чего хотят. Я бы даже не тратил время. У меня были коллеги, которые отбирали людей по принципу «огонь/не огонь» и не могли объяснить, почему. Пройти такой отбор — это реально рулетка.
Ну и ещё. Я не верю в тестовые с ментором — за исключением стажеров и джунов. На старте ментор может помочь структурировать мысли, дать шаблоны, подтянуть результат. Но если у вас уже приличный опыт, ментор может, наоборот, сбить. Он будет транслировать своё видение, а вы бы, возможно, сделали лучше, если бы опирались только на своё.
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19💯10👍1🤔1
Нерегулярная рубрика этого канала под названием «Дед опять забыл выпить таблетки 💊»
При чём тут вообще Римская империя?
Было время, когда мне часто попадались видео на YouTube и статьи в духе: «Вот во времена Древнего Рима были такие чудовищные достижения прогресса, что даже сейчас мы по отдельным аспектам (социальное развитие, демократия, архитектура, технологии и т. д.) только-только подбираемся к их уровню. А прошло ведь уже две тысячи лет».
И вот примерно об этом же я хотел бы поговорить сегодня — только не про Рим, а про дизайн. Потому что, кажется, у нас, дизайнеров, тоже была своя «Римская империя».
Представьте: 20 лет назад уже существовала среда, которая объединяла в себе облегченный Illustrator, After Effecs, а ещё — собственную IDE для разработки и отладки прямо из коробки.
Да-да, прямо там можно было писать код, прям бизнес-логику, прям фронтенд!
Готовый проект можно было запускать прямо в браузере или упаковать в .exe — и вуаля, у тебя полноценное standalone-приложение. Круто?
Это был великий и могучий Flash.
Когда я впервые познакомился с этим инструментом, он назывался Macromedia Flash. Позже компанию в 2005 году купила Adobe, и он стал Adobe Flash Pro. Популярность флеша была бешеной: на нём делали мультфильмы (помните «Масяню»?), игры, анимированные баннеры, приложения и даже сайты.
Но потом пошёл разговор про уязвимости флеш-плеера, про безопасность… А потом Apple отказалась поддерживать формат на своих устройствах — и это стало последним гвоздём в крышку гроба этой технологии. Эпоха закончилась. Веб пошел путём HTML5 — и дальше мы знаем, как всё развивалось.
Недавно я нашёл в интернете старый установщик и поставил Flash себе снова. Конечно, почти всё забыл, но чисто ради ностальгии и чтобы сделать видео «как это было» — потыкал и записал вам небольшой привет из прошлого.
Внутри — полноценный набор инструментов: библиотеки компонентов из коробки, векторная рисовалка, мощный моушн-редактор. Поддержка ActionScript 2.0 и 3.0 — двух разных версий встроенного языка программирования.
Основной объект для привязки кода — кадр. Причём каждый слой имел свой таймлайн, а каждый объект внутри — свой собственный (!!!). Например, у кнопки был свой таймлайн, где каждый кадр — это её состояние. Переход между состояниями — просто переход по кадрам. А если между ключевыми кадрами задать анимацию — то и переход получался анимированным.
А ещё был прямой импорт .ai и .psd файлов...
Иногда интересно — как всё повернулось бы, занеси Adobe вовремя денег Apple и реши они проблемы с безопасностью.
Но имеем, что имеем.
Эх, ладно, пошёл я дальше придумывать, как связать Фигму с кодом😔
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
При чём тут вообще Римская империя?
Было время, когда мне часто попадались видео на YouTube и статьи в духе: «Вот во времена Древнего Рима были такие чудовищные достижения прогресса, что даже сейчас мы по отдельным аспектам (социальное развитие, демократия, архитектура, технологии и т. д.) только-только подбираемся к их уровню. А прошло ведь уже две тысячи лет».
И вот примерно об этом же я хотел бы поговорить сегодня — только не про Рим, а про дизайн. Потому что, кажется, у нас, дизайнеров, тоже была своя «Римская империя».
Представьте: 20 лет назад уже существовала среда, которая объединяла в себе облегченный Illustrator, After Effecs, а ещё — собственную IDE для разработки и отладки прямо из коробки.
Да-да, прямо там можно было писать код, прям бизнес-логику, прям фронтенд!
Готовый проект можно было запускать прямо в браузере или упаковать в .exe — и вуаля, у тебя полноценное standalone-приложение. Круто?
Это был великий и могучий Flash.
Когда я впервые познакомился с этим инструментом, он назывался Macromedia Flash. Позже компанию в 2005 году купила Adobe, и он стал Adobe Flash Pro. Популярность флеша была бешеной: на нём делали мультфильмы (помните «Масяню»?), игры, анимированные баннеры, приложения и даже сайты.
Но потом пошёл разговор про уязвимости флеш-плеера, про безопасность… А потом Apple отказалась поддерживать формат на своих устройствах — и это стало последним гвоздём в крышку гроба этой технологии. Эпоха закончилась. Веб пошел путём HTML5 — и дальше мы знаем, как всё развивалось.
Недавно я нашёл в интернете старый установщик и поставил Flash себе снова. Конечно, почти всё забыл, но чисто ради ностальгии и чтобы сделать видео «как это было» — потыкал и записал вам небольшой привет из прошлого.
Внутри — полноценный набор инструментов: библиотеки компонентов из коробки, векторная рисовалка, мощный моушн-редактор. Поддержка ActionScript 2.0 и 3.0 — двух разных версий встроенного языка программирования.
Основной объект для привязки кода — кадр. Причём каждый слой имел свой таймлайн, а каждый объект внутри — свой собственный (!!!). Например, у кнопки был свой таймлайн, где каждый кадр — это её состояние. Переход между состояниями — просто переход по кадрам. А если между ключевыми кадрами задать анимацию — то и переход получался анимированным.
А ещё был прямой импорт .ai и .psd файлов...
Иногда интересно — как всё повернулось бы, занеси Adobe вовремя денег Apple и реши они проблемы с безопасностью.
Но имеем, что имеем.
Эх, ладно, пошёл я дальше придумывать, как связать Фигму с кодом
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12
This media is not supported in your browser
VIEW IN TELEGRAM
Пока писал предыдущий пост, подумал: жаль, не сохранилось ни одного файла из того, что я тогда делал во Flash…
Или всё-таки сохранилось?
Перетряхнул старые ящики электронной почты — и да, нашёл рабочий проект!
Это кусочек сайта, который я делал в 2007 году на тему рок-музыки. Треки, конечно, давно не запускаются, но сам плеер жив — всё нажимается, перетаскивается.
Местная фишка — летучие мыши 🦇
Помню, сколько с ними возился: чтобы летали свободно, если их не трогать, убегали от курсора, если подводишь, и наоборот — слетались к активности: наведению или клику.
Интересно, сколько седых волос я бы сейчас заработал, если попытался бы повторить всё это на JS…
В общем, как вам интерфейс почти двадцатилетней давности?
Кажется, дизайн состарился гораздо лучше, чем я ожидал 🙈
Да, UI и визуал кое где протухли, но вот особенно плеер всё ещё выглядит вполне.
Ещё по современным меркам с контрастом беда — но тогда и мониторы были другие.
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Или всё-таки сохранилось?
Перетряхнул старые ящики электронной почты — и да, нашёл рабочий проект!
Это кусочек сайта, который я делал в 2007 году на тему рок-музыки. Треки, конечно, давно не запускаются, но сам плеер жив — всё нажимается, перетаскивается.
Местная фишка — летучие мыши 🦇
Помню, сколько с ними возился: чтобы летали свободно, если их не трогать, убегали от курсора, если подводишь, и наоборот — слетались к активности: наведению или клику.
Интересно, сколько седых волос я бы сейчас заработал, если попытался бы повторить всё это на JS…
В общем, как вам интерфейс почти двадцатилетней давности?
Кажется, дизайн состарился гораздо лучше, чем я ожидал 🙈
Да, UI и визуал кое где протухли, но вот особенно плеер всё ещё выглядит вполне.
Ещё по современным меркам с контрастом беда — но тогда и мониторы были другие.
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍4
Уже довольно давно основным источником новостей и вдохновения в дизайне для меня стали разные дайджесты, подборки и ленты. Наверное, единственный дайджест, который я читаю регулярно — это Дайджест продуктового дизайна, который ведёт Юрий Ветров.
И вот листаю свежий выпуск за март, и вижу: «Сергей Мухин рассказывает…».
С момента, как я начал вести канал и писать статьи, это до сих пор остаётся самым удивительным — когда кто-то находит в твоём тексте ценность и делится им без твоего участия. Но когда видишь свою статью в медиа, которое сам читаешь — это уже буквально чувство из серии: «Мам, я в телевизоре!»
Кстати саму статью я особо никуда не выкладывал, лежит на сайте среди других кейсов в моём портфолио. Тем удивительнее, что она попала в подборку.
Саму статью можно почитать на моём сайте.
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
И вот листаю свежий выпуск за март, и вижу: «Сергей Мухин рассказывает…».
С момента, как я начал вести канал и писать статьи, это до сих пор остаётся самым удивительным — когда кто-то находит в твоём тексте ценность и делится им без твоего участия. Но когда видишь свою статью в медиа, которое сам читаешь — это уже буквально чувство из серии: «Мам, я в телевизоре!»
Кстати саму статью я особо никуда не выкладывал, лежит на сайте среди других кейсов в моём портфолио. Тем удивительнее, что она попала в подборку.
Саму статью можно почитать на моём сайте.
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👍2
Редизайн своего же решения
Поиск постоянного проекта в последнее время только расстраивает. Рынок труда сейчас в крайне странном состоянии. Если вы думаете о смене работы — предостерегаю: момент для этого крайне неудачный.
Зато периодически появляются разные парт-тайм возможности. Например, я вернулся к проекту, для которого лет 4–5 назад рисовал мобильную версию — mirturbaz.ru.
Хочу освежить UI, пересобрать и перераспределить информацию в некоторых сущностях (выкидывать ничего нельзя), обновить UI Kit — тем более Figma за это время сильно продвинулась вперёд — и добавить несколько новых, довольно крупных фич.
Пока что сократил карточку отеля в списке и добавил новую возможность — выбор нескольких номеров (раньше можно было бронировать только один номер за раз).
Необычные ощущения — снова что-то делать руками как дизайнер. А ещё интереснее — переделывать за собой через столько лет. Особенно, когда на вопрос «Кто вообще это сделал?» сам себе отвечаешь: «Ты!» 😁
Кстати, одну идею для экономии места под второстепенный, но обязательный текст в карточках уже попробовал: при остановке внимания или скролла на карточке запускается бегущая строка. Скорость анимации и возможность (или невозможность) прокрутки вручную ещё буду тестировать — пока это скорее концепт. Как вам?
- -
🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru
Поиск постоянного проекта в последнее время только расстраивает. Рынок труда сейчас в крайне странном состоянии. Если вы думаете о смене работы — предостерегаю: момент для этого крайне неудачный.
Зато периодически появляются разные парт-тайм возможности. Например, я вернулся к проекту, для которого лет 4–5 назад рисовал мобильную версию — mirturbaz.ru.
Хочу освежить UI, пересобрать и перераспределить информацию в некоторых сущностях (выкидывать ничего нельзя), обновить UI Kit — тем более Figma за это время сильно продвинулась вперёд — и добавить несколько новых, довольно крупных фич.
Пока что сократил карточку отеля в списке и добавил новую возможность — выбор нескольких номеров (раньше можно было бронировать только один номер за раз).
Необычные ощущения — снова что-то делать руками как дизайнер. А ещё интереснее — переделывать за собой через столько лет. Особенно, когда на вопрос «Кто вообще это сделал?» сам себе отвечаешь: «Ты!» 😁
Кстати, одну идею для экономии места под второстепенный, но обязательный текст в карточках уже попробовал: при остановке внимания или скролла на карточке запускается бегущая строка. Скорость анимации и возможность (или невозможность) прокрутки вручную ещё буду тестировать — пока это скорее концепт. Как вам?
- -
Сайт: uxflow.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥1
На самом деле я готовил для вас большой пост про дизайн-системы. Но в итоге подал заявку на грядущие Дизайн-выходные в Казани — и превратил пост в тему для выступления.
Так что если мне подтвердят участие, ждите полноценный анонс.
Если не подтвердят — ну… тогда значит выйдет пост :)
Так что если мне подтвердят участие, ждите полноценный анонс.
Если не подтвердят — ну… тогда значит выйдет пост :)
👍18