В эту пятницу, 24 июня, собираемся в Новосибирске на офлайн DevDay, чтобы обсудить дизайн внутренних и b2b-продуктов. Естественно, бесплатно, но с предварительной регистрацией.
Html-sketchapp — залог единства программистов и дизайнеров
Перевод
Марк Далглейш, руководитель подразделения, занимающегося разработкой дизайн-систем в компании SEEK, говорит, что если взглянуть на любую команду, которая использует дизайн-систему, можно обнаружить, что у такого подхода имеются совершенно очевидные преимущества. Заключаются они в том, что дизайнеры и программисты трудятся продуктивнее, чем без наличия такой системы, результаты их работы становятся единообразнее, взаимодействие между различными группами сотрудников оказывается более чётким и слаженным.
Домашняя страница интерактивного руководства по стилю компании SEEK
Однако у большинства дизайн-систем есть фундаментальный недостаток. Дизайнеры и разработчики, даже при внедрении чего-то довольно-таки современного, продолжают работать в совершенно разных средах. В результате для того, чтобы поддерживать код и материалы дизайна в согласованном состоянии, приходится прикладывать немалые усилия, иначе те материалы, с которыми работают дизайнеры и программисты, с течением времени, уходят друг от друга всё дальше.
Неудивительно, что у компаний, использующих дизайн-системы, возникает ощущение, что в деле разработки инструментов в нашей индустрии наблюдается застой. Эти инструменты не приспособлены к той среде, в которой мы работаем, они не особенно полезны в важнейшем деле переноса того, что сделано разработчиками, в среду, в которой работают дизайнеры.
Неужели всё действительно так плохо? Марк полагает, что в ближайшем будущем нас ждут изменения к лучшему. В этом материале он рассказывает о том, как в SEEK смогли сблизить системы, в которых работают дизайнеры и разработчики настолько, насколько это позволяют современные технологии.
Домашняя страница интерактивного руководства по стилю компании SEEK
Однако у большинства дизайн-систем есть фундаментальный недостаток. Дизайнеры и разработчики, даже при внедрении чего-то довольно-таки современного, продолжают работать в совершенно разных средах. В результате для того, чтобы поддерживать код и материалы дизайна в согласованном состоянии, приходится прикладывать немалые усилия, иначе те материалы, с которыми работают дизайнеры и программисты, с течением времени, уходят друг от друга всё дальше.
Неудивительно, что у компаний, использующих дизайн-системы, возникает ощущение, что в деле разработки инструментов в нашей индустрии наблюдается застой. Эти инструменты не приспособлены к той среде, в которой мы работаем, они не особенно полезны в важнейшем деле переноса того, что сделано разработчиками, в среду, в которой работают дизайнеры.
Неужели всё действительно так плохо? Марк полагает, что в ближайшем будущем нас ждут изменения к лучшему. В этом материале он рассказывает о том, как в SEEK смогли сблизить системы, в которых работают дизайнеры и разработчики настолько, насколько это позволяют современные технологии.
Как мы уместили таблицы в экран смартфона и унифицировали в рамках дизайн-системы
Мы разрабатываем рабочие инструменты для сотрудников и партнеров заказчика. Большинство созданных нами модулей содержит таблицы, реестры, карточки с детальной информацией.
Изначально основная часть модулей была заточена под веб, потому что с системами работают офисные сотрудники со стационарных компьютеров. О том, как мы проработали дизайн-систему для веба, мы писали ранее.
Но жизнь постоянно ускоряется, так что скорость принятия решений возрастает в разы. Нашим пользователям нужно быть в курсе дел в любой момент, а не только сидя на рабочем месте. И мы понимаем, что должны предоставлять с мобильного информацию, достаточную для принятия оперативных решений.
Для дизайн-проектирования это ставит нам 2 задачи:
1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.
2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.
В этой заметке поделимся тем, как мы подходили к решению задач перевода таблиц в списки и унификации представления разных списков.
Изначально основная часть модулей была заточена под веб, потому что с системами работают офисные сотрудники со стационарных компьютеров. О том, как мы проработали дизайн-систему для веба, мы писали ранее.
Но жизнь постоянно ускоряется, так что скорость принятия решений возрастает в разы. Нашим пользователям нужно быть в курсе дел в любой момент, а не только сидя на рабочем месте. И мы понимаем, что должны предоставлять с мобильного информацию, достаточную для принятия оперативных решений.
Для дизайн-проектирования это ставит нам 2 задачи:
1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.
2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.
В этой заметке поделимся тем, как мы подходили к решению задач перевода таблиц в списки и унификации представления разных списков.
Дизайн-система в Figma. Взгляд на интерфейс через компоненты
Какой должна быть оптимальная дизайн-система в Figma? Что такое переиспользуемый компонент? Как понятнее и удобнее организовать структуру внутри панели Instance? Каковы этапы разработки подобного продукта? И так далее. Ответы на эти и многие другие вопросы я постараюсь дать в этой статье.
Дизайн цифровых продуктов. Цель, роль, метод
Мне довелось создать с нуля подразделение дизайна в Альфа-Банке и поработать дизайн-директором. На это ушло пять лет. В результате у нас получилась дизайн-система (в коде) и подход к диайну цифровых продуктов. Собственно, про этот подход я и расскажу здесь. Точнее, это — текст лекции, которую я читал в начале 2018 года в Москве, Перми, Новосибирске и Петербурге. В мае я принял решение покинуть банк, теперь дошли руки опубликовать текст лекции.
В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).
Важная оговорка: весь текст рассказывает о работе дизайнера в скрам-команде. Это очень важная оговорка, которую надо держать в голове. На лекциях я это упоминал мимоходом, как само собой разумеющееся, поэтому кто-то мог потерять смысл рассказа. Для канбана и традиционных подходов (договор-дизайн-верстка-сборка-акт) такой метод скорее всего может даже навредить. Поэтому, если вам понятие «скрам» ново, изучите подход — может быть кому-то это поможет лучше организовать работу у себя. По ходу текста я насыпал ссылок на статьи и книги.
В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.
В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).
Важная оговорка: весь текст рассказывает о работе дизайнера в скрам-команде. Это очень важная оговорка, которую надо держать в голове. На лекциях я это упоминал мимоходом, как само собой разумеющееся, поэтому кто-то мог потерять смысл рассказа. Для канбана и традиционных подходов (договор-дизайн-верстка-сборка-акт) такой метод скорее всего может даже навредить. Поэтому, если вам понятие «скрам» ново, изучите подход — может быть кому-то это поможет лучше организовать работу у себя. По ходу текста я насыпал ссылок на статьи и книги.
В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.
Переход от UI-кита к дизайн-системе в QIWI
Дизайн-система стала таким же модным и почти обязательным инструментом для IT-компании, как использование канбан-досок и agile. Существует множество определений дизайн-системы: кто-то понимает под ней только UI-кит, а кто-то считает, что дизайн-система обязательно включает в себя компонентную базу в коде.
От том, как мы поняли, что пора переходить от UI-кита в sketch к отображению стилей в коде — под катом.
От том, как мы поняли, что пора переходить от UI-кита в sketch к отображению стилей в коде — под катом.
Figma компонент и организация экземпляров на примере Userpic
Туториал
Качественная дизайн-система в Фигме всегда учитывает возможные состояния определенных компонентов. Если до появления Global Styles вариант был лишь один — всегда создавать новый компонент для каждого состояния (например текстовое поле может быть default, а может быть focused), то после внедрения стилей многие UI-элементы удалось унифицировать лишь до одного в своей категории, а разнообразие создавать экземплярами, присоединяя лишь новые стили и цвета.
Как создать UI kit, который продается. Этапы разработки коммерческой дизайн-системы
Веб-дизайн *Разработка веб-сайтов *Разработка мобильных приложений *Интерфейсы *Управление проектами *
Туториал
Сегодня у любого дизайнера есть возможность заработать на собственном дизайн-продукте. Иконки, иллюстрации, шаблоны сайтов и приложений можно превратить в цифровой продукт и продавать по всему миру. Кому-то ваша поделка поможет ускорить работу и человек за нее заплатит. Другой может купить, чтобы посмотреть как это сделано. Третий — оформить свой ресурс вашими дизайн-решениями. Ваш продукт может выстрелить и попасть в топ, а может оказаться никому не нужным. Но стоит попробовать сделать это хотя бы ради прокачки навыков, работы с продажами, шанса отказаться от офисной работы или работы на клиента.
Я расскажу о поэтапном плане создания коммерческой дизайн-системы. Узнаете как сделать и выпустить на рынок свой продукт. Расскажу что сделать перед началом работы, как подготовиться и составить план. Отдельно рассмотрю этапы разработки дизайн-системы для Figma. В последней части дам советы как продвигать и раскручивать. В статье только личный опыт и наблюдения самоучки.
РИТ++ 2020: консультации с инженерами Авито в Зуме
Привет, Хабр! 25 и 26 мая будет РИТ++. Это большая онлайн-конференция для всех, кто делает интернет. В обычных условиях мы бы встретились на стенде Авито в зале мероприятия, но 2020 перевернул всё с ног на голову. Так что общение переносится в Зум, где 11 наших инженеров из разных команд ответят на вопросы про базы данных, перформанс, мониторинг, микросервисную архитектуру и многое другое.
Участвовать в консультации можно независимо от того, есть у вас билет на конференцию или нет. Все встречи доступны любому желающему. Расписание, экспертные области участников и нужные ссылки — под катом. Кроме консультаций мы подготовили пару развлечений, о них в конце анонса.
Стилизация Android-приложений и дизайн-система: как это сделать и подружить одно с другим
Блог компании Ситимобил Разработка мобильных приложений *Разработка под Android *Дизайн мобильных приложений *
Туториал
Привет читателям!
В какой-то момент любое крупное приложение разрастается так, что сложно везде поддерживать однотипный дизайн и динамично реагировать на любые изменения и тенденции в дизайне и UX-требованиях.
Поэтому решили внедрить в наше приложение дизайн-систему и добавить поддержку нескольких тем оформления.
Изучив различные способы, выработали свой подход к решению такой задачи. Хотелось сделать так, чтобы дизайн-систему и поддержку стилей можно было повторно использовать в других своих проектах. В соответствии с этой идеей разрабатывались компоненты и темы.
Numl – Альтернативный язык разметки и стилизации для веб
Всем привет! Меня зовут Андрей, я профессионально разрабатываю веб-интерфейсы уже больше 11 лет и последний год развиваю проект Numl, который можно назвать языком разметки и стилизации для веб. В этой статье я расскажу, как в попытке перебороть ряд особенностей CSS и упростить вёрстку веб-проектов получился целый язык, который не только удовлетворил все наши потребности в стилизации, но также позволил уменьшить кол-во JS-кода и улучшить доступность.
Дизайн-система: что это, для чего и как создать
Всем привет!
Я рад вернуться к вам, дорогие читатели сообщества, и поделиться опытом и знаниями, полученными благодаря работе в IT-компании Omega.
Тема дизайн-систем, казалось бы, уже рассмотрена со всех сторон: можно найти множество статей, постов, докладов и других материалов. Несмотря на это, у каждого, кто сталкивается с этим термином, возникает множество вопросов. Я постараюсь подробно ответить на главные из них:
Привет, Хабр! Я Павел Наумов, лидер стрима «Мобильный банк» в ВТБ. Полтора года назад мы собрали команду, чтобы доработать банковские приложения для iOS и Android. Первоначально речь шла об их «перекраске», но в итоге пришлось переписать половину унаследованного кода и сделать новые приложения с новым микросервисным бэкендом. Попутно мы сократили сроки релизов с 1,5 месяцев до 2 недель. С чем нам пришлось столкнуться, как мы решали проблемы и какие уроки из этого вынесли, мы с ребятами из команды рассказываем под катом.
Сколько цветов нужно, чтобы было норм, как эти цвета назвать и как ими пользоваться?
Рассказываю о небольшом цветовом фреймворке, который используется в нашей ДС. Сначала, как обычно, небольшой обзор бест-практисов, а затем мой велосипед.
Ховеры бывают разные
Когда у нас в eLama компонентов в библиотеке стало достаточно много, мы заметили, что ховеры не имеют системы: меняется цвет заливки, цвет рамки, цвет текста, появляется тень и т.д.
Мы делали это не со зла, в отдельных проектах так работало лучше, но глядя на интерфейс в целом, стало понятно, что это проблема.
Гайд по UI анимации. Как начать анимировать интерфейсы
Привет! Меня зовут Айгуль, я продуктовый дизайнер в Райффайзенбанке, а до этого работала в Mail.ru Group, OneTwoTrip и приложила руку к нескольким стартапам. Как-то я взяла на себя задачу продумать систему UI-анимаций для дизайн-системы. Но когда я начала над ней работу, удивилась, как мало написано практических материалов. В статьях часто перечисляют правила анимации Уолта Диснея, которые никак не помогают в UI, или авторы делают подборку красивых гифок без намека на то, как такое реализовать.
В этой статье хочу поделиться своим опытом: рассказать, как можно задавать UI анимации, на какие правила стоит обращать внимание при их продумывании и как описать анимацию так, чтобы она была понятна разработчикам в реализации.
Paradigm 2.0 — как мы переосмыслили дизайн-систему Mail.ru
Про дизайн-системы сказано и написано уже многое. Дизайнеры прошли долгий путь от обсуждения шаблонов в Sketch к компонентам в коде, а от компонентов — к рамкам в дизайне и границам системности. В этой статье мы расскажем не о том, как создавать дизайн-системы, а о том, как с ними жить: что делать, если система больше не работает, как пересобрать ее заново и как «продать» ее коллегам.
Контрастность компонентов: работа над ошибками
Привет, я Антон, UX-дизайнер. Работаю над библиотекой компонентов eLama. Расскажу о том, как мы обнаружили один из недостатков библиотеки и как его исправили.
Когда мы начали работать над компонентами, изначально мы уделили мало внимания контрастности. Поняли мы это быстро благодаря отзывам от недовольных пользователей.
Мы не учли, что цветопередача мониторов, условия работы и особенности зрения пользователей довольно сильно отличаются, поэтому один не может отличить плейсхолдер от заполненного поля, а другой — разглядеть текст заблокированной кнопки.
О дизайн-системе замолвите слово
Практически каждая продуктовая компания рано или поздно приходит к мысли, что неплохо бы перестать раз за разом разрабатывать визуальные компоненты для каждого экрана в отдельности, что нужно подойти к этому вопросу более системно. В частности – сделать свою дизайн-систему. Мы в hh не стали исключением, и в этой статье хотим поделиться нашим собственным опытом разработки дизайн-системы, которая сейчас является общей для двух платформ – Android и iOS.
Мы поговорим о балансе между хаосом и системой, переиспользовании и дублировании, пройдемся по отношениям между дизайнерами и разработчиками, а также выясним, фронтенд – это только про покраску кнопок или нет?
Если вам удобнее не читать, а смотреть или слушать, то вы можете посмотреть выпуск о дизайн-системе в нашем видео-блоге “Охэхэнных историй”.
Создаем ячейки в iOS
Блог компании HeadHunter Разработка под iOS *Разработка мобильных приложений *Swift *Дизайн мобильных приложений *
Типичный день мобильного разработчика: получил json, распарсил, отрисовал на UI ячейки, PROFIT.
Как элегантно колдовать с ячейками без изобретения велосипеда мы рассказали в одном из эпизодов «Охэхэнных историй», а потом сделали из него статью.
В сегодняшней программе ячеек в iOS: разберемся какие ячейки бывают, посмотрим на ячейки в дизайн-системе hh.ru и их реализацию в коде и попробуем собрать свою ячейку.