Пришлось удалить приветственный пост😬
Или я баг в ТГ поймал, или одно из двух...
При написании поста в отложку, каким-то образом текст из него заменил собой и текст из первого поста, где по идее должно было быть "Кто я, что за канал"... И редактировать уже было нельзя! Вот такие вот первые опыты в создании контента😁

- - - - -

Канал: Мыслью по древу

#технологии
Пост - тизер текущей работы.

Уже почти год занимаюсь созданием дизайн-платформы для ВкусВилл под рабочим названием «Манго».

Это новый для меня уровень глубины работы с дизайном. Даже не дизайн-система, а core технология, которая служит базой для ДС. Дошло до того, что в рамках платформы стали делать «свою фигму». Там конечно скорее гибрид получается фигмы, вебфлоу и конструктора, но так звучит мощнее)))

Суть платформы в реализации SDUI подхода в работе с дизайном приложения, полный контроль верстки с бэка, и много-много автоматизации дизайна.

Скоро на этом канале) Не переключайтесь!

- - - - -

Канал: Мыслью по древу

#карьера
Часть 2: Что такое релевантный опыт

Многие думают, видя в вакансии «Опыт от 3 лет», что «ну я же занимаюсь дизайном уже больше 3 лет... », но я вам могу сказать, что учитываю при найме далеко не весь опыт, как релевантный. И думаю, что я такой не один.

Первое, на чем многие теряют очки это затяжной период только фриланса. Год, два и более (встречалось до 10 лет подряд). Фриланс привлекает по многим причинам, однако если вы дальше не собираетесь брать фокус чисто на предпринимательство, открывать ИП и делать студию, я бы посоветовал фриланс держать как доп. В первую очередь из-за специфики экономики фрилансера. Продать себя подороже, сделать быстрее... Что ненавидят все фрилансеры? Верно, правки.

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

Для работы в продукте важно уметь взять ответственность за результат, осознанность, что, для кого вы делаете, и зачем. Умение проверить, достигли ли цели, найти ошибки и исправить их, мыслить итерациями.

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

- - - - -

Канал: Мыслью по древу

С началом рабочей недели! Мем о наболевшем.

Вот шутки шутками, а сейчас заметил, что работа в фигме или с фигмой сократилась до 20-25% времени. Большая часть это таблички и созвоны. Много созвонов!
Сейчас работаю над матрицей навыков, и открыл для себя интересный инструмент — матрица RACI (Ответственности). Как закончу, поделюсь, что получилось.

- - - - -

Канал: Мыслью по древу

#SDUI #технологии

Уже мелькало на канале такое сочетание букв, как SDUI.
Но что же это реально такое?

SDUI - Server Driven User Interface. На самом деле сама концепция не столько про дизайн, сколько про данные и обработку действий. В классическом приложении все действия обрабатывает клиент, на нём же и значительная часть бизнес-логики.

В SDUI приложении же клиент "тупой" на столько, что виджеты умеют только отправлять события на сервер вроде "Ой, на меня нажали". И ждать от сервера инструкции, как должен поменяться интерфейс после нажатия. Вся бизнес-логика уходит на бэкенд приложения.

А клиент умеет только обрабатывать контракт. Контракт это чаще всего JSON с деревом объектов и их параметрами. Такой принцип открывает возможность делать изменения на клиенте без релиза в магазин приложений. И чем вариативнее отрисовщик, чем более управляемый интерфейс, тем больше типов изменений можно делать без релиза.

- - - - -

Канал: Мыслью по древу

#технологии #SDUI #платформаманго #цвет

Референсная палитра

Организация цветов в дизайн-системах интересная тема. И разговоры в комьюнити не утихают, как лучше, как правильно...

Хочу поделиться, что я для себя считаю оптимальным и какой путь выбрал для текущего проекта. И начать с того, что я считаю оптимальной многослойную палитру. Ну то есть когда есть палетка со всеми уникальными цветами а на неё уже ссылаются светлая и темная темы, и прочие семантические штуки.

Вот эта палетка и есть — референсная палитра.

- - - - -

Канал: Мыслью по древу

#технологии #SDUI #платформаманго #цвет

Инструменты генерации палитры

Сейчас есть многообразие решений: leonardo, huetone и другие. Их любят за работу с OKLCH цветовым пространством. Мой любимчик — это Colorbox. Причем по ссылке откроется сразу одна из моих палитр, можно посмотреть мой вариант настроек. За что мне нравится именно этот инструмент: понятный параметрический интерфейс настройки прогрессии, есть плагин для экспорта в фигму. С sRGB я пока для себя не увидел плюсов переходить на что-то модное для P3 экранов, платформа и так не плохо справляется с адаптацией не P3 контента под новые дисплеи. Но это лично моё решение.

На выходе получается палетка как на превью предыдущего поста. Отталкивался я в первую очередь от контрастов, во вторую от светимости, добиваясь коридорных значений по горизонталям в матрице. Ну то есть если взять brand1.L300 и brand2.L300, то контрастность по отношению к белому и темному у них будет примерно одинаковая, то же касается и светимости.

Далее из этих цветов формируется уже семантический слой, например темная и светлая темы. Но об этом постараюсь рассказать в следующих постах.

P.S. Сейчас думаем о том, чтобы воспроизвести что-то типа Колорбокса у себя в инструментах платформы, чтобы сразу получать на выходе токены в нашем формате. Это вообще продвинет работу с палитрой на новый уровень.

- - - - -

Канал: Мыслью по древу

#платформаманго
На фото: фигма, android, iOS.

Первые реальные экраны с бизнес-логикой на новой платформе. Кстати всё выгружено из фигмы без верстальщика.

Внимательные заметят небольшие отличия на андроид, но осталось отловить совсем не много багов отрисовщика, и настанет полный кроссплатформенный пиксельперфект. Что в фигме в макете, то и на проде.

P.S. Приложение полностью нативное.

- - - - -

Канал: Мыслью по древу

Про менторство

«Не умеешь сам, научи другого», —
так я себе вижу большинство курсов и менторов.

«Сделай лучше, раз такой умный», – кто-то скажет. А вот тут есть нюанс.

Запросы на менторство приходят ко мне не прям уж пачками, но довольно регулярно, и есть тенденция на возрастание. Однако, всем я мягко отказываю. Почему?

Смотрите, какая штука, чаще всего с запросом приходят достаточно молодые дизайнеры. Есть у меня ощущение (не подтверждено данными), что условные джуны считают, что сеньоры от всех скрывают какой-то секрет. Вот узнай они этот секрет, так точно сразу в сеньоры.

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

Если бы подобный сеанс обучения произошел, он был бы очень «капитанский»:
— Ну, значит работай, набирайся опыта и через несколько лет станешь мидлом. Бери больше ответственности, через еще несколько лет станешь сеньором.

Получается денег взял, ценности (т.е. секрет) не дал. Всё! Репутационные потери, тонны недовольства. И оно мне надо?!

А где взять ценность? Сесть разработать комплексный курс «От джуна до сеньора и обратно» с фундаментальной теорией, с практикой, домашкой, списками литературы... При переводе времени на деньги — о-о-о-очень дорого. Желание — хотя бы отбить затраты, не говоря уже о выйти в плюс. А как? Значит: реклама, раскрутка, набор в группы, потоки, основание своей школы... И вот уже нифига не занимаюсь дизайном, только админю всё это дело и веду лекции. Что происходит с моими навыками? Они, конечно, начинают устаревать без практики. Ценность курсов падает...
Я лучше пока поработаю 😁

Могу, конечно, где-то ошибаться, но вот таким я себе это всё вижу, потому не берусь за коммерческое менторство. Лучший способ поучиться именно у меня — поработать в моей команде. Вакансии, благо, периодически появляются.

А теперь на других коучей, лекторов, менторов тоже попробуйте через такой взгляд посмотреть 😉

- - - - -

Канал: Мыслью по древу

#технологии

Палитра. Семантический уровень.

В продолжение темы о цветах, хотелось бы рассказать о том, как я создаю следующий слой - семантический. Эта палитра служит для того, чтобы придать смысл цветам из референсной палитры.

Существует несколько подходов к созданию семантики:

1. Элементный
Этот подход заключается в том, что имя токена получает вид border-subtle-selected или text-on-color-disabled, то есть в его основе лежит целевой элемент и его состояние.
Пример ДС: Carbon от IBM.

2. Функциональный
В этом подходе семантика указывает на более общие понятия: тип поверхности, иерархия акцентов, цвета группируются в пары и наборы: brand-primary, on-brand-primary.
Пример ДС: Material от Google

Кроме того существует ещё третий уровень палитры — компонентный. И вот тут единства у дизайнеров нет, что порождает третий подход.

3. Сочетание семантического и компонентного уровней.
Это сочетание одного из вышеупомянутых подходов с примесью компонентного уровня. В этом случае частотные сущности рассматриваются как элементы. Например, когда это выглядит как путь к элементу, но вместо элемента у нас, скажем, кнопка. Получаем: button.primary.accent.bg-color


Мой подход

Я совершенно не понимаю компонентный уровень токенов. Это очень серьезное усложнение, которое приводит к сотням токенов при масштабировании. В интернете есть видео от Atlassian, где они демонстрировали свою систему токенов. Кто-то из сообщества сказал: “Они сфотографировали хаос”.

Подход от состояния и элемента на масштабе также порождает длинные и нечитаемые конструкции, такие как text.primary.neutral.disabled.on-dark.

Мне нравится подход Google, если его правильно адаптировать и докрутить, получаются очень лаконичные и читаемые схемы, понятные всем дизайнерам в команде.
Кроме того, если поработать над состояниями с точки зрения «вынесения за скобки», то получится еще компактнее.

Проектируя компоненты в фигме, вы, наверное, замечали, что рисуете очень много похожих вещей у разных компонентов. Тот же принцип построения нажатий и наведений, disabled, focus. Все это можно вынести в модель. Не описать у каждого отдельного компонента, каким должен быть новый цвет при нажатии, а один раз сформулировать алгоритм или формулу получения нового цвета. Есть много вариантов, самые популярные: HSL или LHC смещение, наложение другого цвета. И часто в макете вы используете наведение, бездействие, фокус? Что проще: прорабатывать все состояния в вариантах компонента, обслуживать огромную матрицу вариантов… или один раз описать принцип в документации и, при необходимости, раз в месяц создавать по нему, например, disable-состояние в макете?

Для текущего приложения ВкусВилл я выбрал именно такой подход. В платформе Манго мы пошли ещё дальше, и расширили семантику микро-темами (контекстами). Но об этом в другой раз.

- - - - -

Канал: Мыслью по древу