Стоит только коснуться производственной специфики, как стандартные подходы разваливаются на куски — даже если у вас уже есть огромная дизайн-система на основе популярной методологии Material Design. Я — Аня Труфанова, делаю дизайн для MES (manufacturing execution system). Нам пришлось взять дизайн-систему и наполнить ее уникальными фичами и кастомными компонентами, адаптированными под нестандартные условия. Сейчас я поделюсь, что именно мы переосмыслили и какие фичи добавили.
Работа в крупных компаниях — это не только ДМС и корпоративный мерч. Это большой поток информации, связанный и не очень с дизайном.
Чтобы приступить к проекту, нужно раскопать документацию, пообщаться с командой, поисследовать гипотезы. В корпорациях проект может длиться несколько месяцев и даже лет. Документация устаревает, носители знаний выходят из команд...
Помимо информации вам нужен большой инструментарий: Figma, Framer, Miro, а ещё дизайн-система.
Я лид дизайн-системы. В статье расскажу, как мы наладили диалог с дизайнерами в 100 продуктовых командах. Читайте, если вы уже заняты в продукте, или хотите работать в корпорации и не знаете, чего ждать. Также будет интересно всем, кто хоть раз пытался собрать комьюнити или встречу более чем на три участника.
Если поставить цифровые продукты в один ряд с объектами промышленного дизайна, первые отличаются большей пластичностью и стремлением к изменениям из-за более короткого дизайн-цикла.
Финтех давно перестал быть чем-то исключительным, став доступнее для широкой аудитории. Управление личными финансами, инвестиции, а в b2b — выполнение рабочих задач, превратились в рутину, наравне с вызовом такси или заказом продуктов. Любой из этих сервисов вносит лепту в формирование представления о «хорошем сервисе».
Большинство финтехов плюс-минус выровнялись по функционалу. Озадачившись выбором одного из конкурирующих сервисов, пользователи всё чаще учитывают современность, удобство и привлекательность.
В статье расскажу, как мы обновляли визуальный стиль десктопной версии Альфа-Бизнес. История будет полезна как начинающему дизайнеру продукта, так и дизайн-менеджеру. Я подробно опишу пройденные шаги, сложности, с которыми мы столкнулись во время реализации, достигнутые результаты и мои выводы проекта.
Привет, Хабр! На связи Дмитрий Парфёнов (СТО) и Антон Смирнов (дизайн-директор). Сегодня хотим поделиться нашим опытом создания и внедрения дизайн-системы для ускорения разработки сайта и мобильного приложения Сравни. Сразу скажем, что процесс это был непростой, не обошлось без всевозможных затыков — о них тоже пойдет речь.
Надеемся, что статья будет полезна всем, кто участвует в разработке крупных приложений в компаниях с большим количеством уже работающих продуктов.
Всем привет, я Алексей Сизиков, руководитель отдела User Experience в Yandex Cloud. В этой статье я хочу поделиться новостью: мы выпустили нашу дизайн-систему и библиотеку компонентов Gravity UI в опенсорс.
Под катом — рассказ, зачем мы сделали Gravity UI, как его используем, в чём особенности и преимущества нашего подхода и как мы планируем развивать его дальше. А ещё — как настроить разные цветовые схемы в своих проектах и почему у нас четыре темы вместо двух стандартных.
Я постарался придумать самое простое объяснение дизайн-токенов на примере житейских ситуаций. Что это такое, как работают и зачем они нужны — в этой статье.
Про принципы наименований, экспорт токенов из фигмы и передачу токенов разработчикам.
При планировании проекта команде дизайна приходится отвечать на много вопросов. Главные — что делать, как долго и сколько это будет стоить. Ответы есть не всегда и точно не у дизайнеров, которые занимаются отдельными задачами и не видят картину в целом.
Меня зовут Александр Самсонов, я руководитель отдела UX в СберТехе. Вместе с командой работаю над продуктом Platform V UK Kit — дизайн-системой React-компонентов корпоративного масштаба. Расскажу, как мы начали оценивать затраты ресурсов при разработке дизайн-системы, и как метод помог нам лучше планировать работу, точно отвечать на вопросы и не выглядеть в глазах бизнеса нервными белыми воронами в чёрных толстовках.
Привет, Хабр! Меня зовут Саша, я Full-Stack разработчик и последние 7 лет пишу фронтенд, 6 из которых я работаю в американском стартапе.
Я думаю ни для кого не секрет, что бизнес процессы в стартапах, мягко сказать, хромают. Я же как оптимист вижу возможность в каждой трудности, поэтому всегда считал, что это отличная возможность проявить инициативу и попробовать что-то автоматизировать или улучшить процессы команды (ну или хотя бы попробовать).
Сегодня хочу рассказать, как можно легко реализовать документацию для дизайн-токенов в Storybook, и заодно поделиться тем, как и почему я пытался это сделать, и что из этого вышло. Статья будет полезна для разработчиков, которые уже используют дизайн токены и ищут лёгкий способ их документации.
В этой статье я расскажу как упорядочить цвета в макетах и в уже готовом продукте; как перейти от стилей к токенам (variables), а также поделюсь рекомендациями для тех, кто только собирается внедрять стили и переменные для цветов.
Если вы следите за новинками экосистемы JavaScript, то должны были слышать об интересной библиотеке пользовательского интерфейса (user interface, UI) под названием shadcn/ui. Вместо того, чтобы распространяться в виде пакета npm, компоненты shadcn/ui добавляются с помощью интерфейса командной строки (command line interface, CLI), который помещает исходный код компонентов непосредственно в ваш проект. Разработчик библиотеки указывает причину такого решения на официальном сайте shadcn/ui.
"Почему код для копирования/вставки, а не библиотека?
Идея заключается в том, что вы полностью владеете и контролируете код. Это позволяет вам решать, как именно будут построены и оформлены ваши компоненты.
Начните с настроек по умолчанию, а затем кастомизируйте компоненты под свои нужды.
Используя пакет npm, можно наткнуться на один недостаток — стиль всегда связан с реализацией. Дизайн компонентов должен быть отделен от их реализации".
На самом деле, shadcn/ui — это не просто очередная библиотека компонентов, а технология, позволяющая представить дизайн-систему в виде кода.
Цель этой статьи — изучить архитектуру и реализацию shadcn/ui.
Если вы еще не использовали shadcn/ui, я советую просмотреть ее документацию и немного поэкспериментировать с ней, чтобы извлечь из статьи максимальную пользу.
Привет! Меня зовут Олег Скирюк, я лидирую контент-разработку в одной из команд билайна. Сам я перешёл в мобильную разработку из веба три года назад, после чего собрал и обучил одну из первых Flutter-команд в компании. Вместе с этой командой мы постоянно экспериментируем и пробуем различные решения, чтобы совершенствовать наши приложения.
В этом посте я хочу рассказать про архитектуру Flutter-приложений, о том, как мы в билайне это делаем, чего мы достигли и как это у нас работает. Поговорим о создании архитектуры, организации управления состояниями и зависимостями, о привычных и не очень методах и концепциях, затронем Mobx, GetX и Flutter modular, а также разберём всё это на живом примере — на нашем мобильном приложении для дилеров.
Мы обсудим его особенности, технические сложности, и посмотрим, как реализовать такое крупное приложение. Затем — углубимся в вопрос управления состоянием, зависимостями, приложением.
Всем привет! Буквально за 5 минут расскажу, как сделать parallax-эффект, который помог нам наглядно показать стилистические различия между светлой и темной темами на сайте «Дизайн-система НЛМК».
Parallax-эффект позволяет пользователю увидеть изменения темы у компонентов при скролле страницы, причем сами компоненты зафиксированы, а линия смены темы двигается синхронно со скроллом.
Привет, я – Герман Гришин, ведущий дизайнер продуктового направления «БАРС Груп». Наша команда разрабатывает дизайн-систему, которая помогает максимально быстро и качественно собирать макеты на готовых компонентах.
В нашем портфолио несколько собственных программных продуктов — например, HR-платформа Т1 TalentForce, приложение для налогового мониторинга Т1 EasyTax и система оценки эффективности бизнес-процессов Т1 Watchman.
Чтобы унифицировать UI и ускорить запуск новых сервисов, мы сформировали собственную дизайн-систему. И уже использовали её при разработке CRM-решения. Далее расскажем, как мы подошли к этой задаче.
На небе только и разговоров, что о дизайн-системах и дизайн-токенах. Но информация представленная здесь строится исключительно на собственном опыте.
Поводом для написания такого гайда стала практика и упорядочивание всей этой информации в голове. Когда я начинал этот путь, то в русскоязычном сегменте было минимум информации и приходилось по крупицам собирать общие практики.
Сегодня я подвожу итог этой темы и суммирую добытые знания, попробовав составить ультимативный гайд по теме. Хотя бы для общего понимания процесса и наводки, в какую сторону копать для таких же жаждущих знаний.
Меня зовут Женя, я руководитель UX-направления в компании Usetech. На досуге веду телеграм-канал «Мамкин Дизайнер», где рассказываю о вот таких штуках.
Я сам — дизайнер, но мне важно было понять, что такое дизайн-токены, как они работают, как компилируются из JSON и как помогают в работе.
Привет! Я – Лера Егорова, frontend-разработчик в Мир Plat.Form. Про дизайн-системы чаще пишут дизайнеры – и это понятно. Но, так как первый кирпич в создании нашей собственной дизайн-системы был заложен со стороны разработки, то хотелось бы рассказать о ней со своей колокольни. Собранная «на коленке» дизайн-система со временем обросла интересными фишками и инструментами для разработчика. О том, какими, читайте под катом.
Дизайн-система позволяет быстро взаимодействовать с компонентами, легко вносить изменения во все макеты и в целом прививает дизайнеру навык организации больших объемов информации.
Зачастую, дизайнер начинает делать дизайн-систему аккуратно, придавая ей должное внимание. Но в по мере увеличения экранов становится, как мне кажется, морально труднее вносить новые компоненты и корректировки. Но помните одну вещь - чем больше времени уделить дизайн-системе, тем больше времени она сэкономит в будущем.
Основное правило дизайн-систем: чем меньше компонентов — тем лучше и вам, разработчику и конечному юзеру. Это касается количества цветов, шрифтов, иконок и так далее. Дизайн будет выглядеть более консистентным и единым.
Жила-была небольшая CRM-система для рекрутмента от команды hh.ru. Не было у нее дизайн-системы, а был маленький UI-китеныш и десяток компонентов. Дизайнер и фронты не думали про Pixel Perfect, а макеты и верстка их отличались. Так бы и жили себе тихонечко, если бы не пришел запрос на освежение дизайна.
Привет! Меня зовут Женя, я дизайнер продукта. Сегодня я поделюсь с вами историей о том, как мы с фронтами подружили Figma и React. В своей статье я затрону всё, что связано с Figma: выбором плагина, созданием токенов и передачей выгруженного json в разработку. Подробнее про техническую часть ждите во второй статье от моего коллеги Ильи.