Зачем меняю аватарку канала (а ещё и название).
Вы, наверное, замечали, что адрес канала @uxflow (типа UX поток). Тут выяснилось, что и домен этот свободен. Ну а я и купил😁
Из этого сформировалась своеобразная стратегия. В планах есть туда забабахать что-то, предположительно на тильде с дайджестом по самым интересным материалам, больше информации обо мне и через него приводить SEO и рекламный трафик. А канал развивать с точки зрения позиционирования чтобы он больше был связан с доменом и моим именем, личным брендом.
Вот... захотелось с вами поделиться планами.
Как вам, кстати, новая аватарка?😁
Вы, наверное, замечали, что адрес канала @uxflow (типа UX поток). Тут выяснилось, что и домен этот свободен. Ну а я и купил
Из этого сформировалась своеобразная стратегия. В планах есть туда забабахать что-то, предположительно на тильде с дайджестом по самым интересным материалам, больше информации обо мне и через него приводить SEO и рекламный трафик. А канал развивать с точки зрения позиционирования чтобы он больше был связан с доменом и моим именем, личным брендом.
Вот... захотелось с вами поделиться планами.
Как вам, кстати, новая аватарка?😁
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26
Модели состояний. Часть1: Hover & Press.
Уже довольно давно я пишу большую статью о своём подходе к проектированию дизайн-систем: как я преобразую сущности в абстракции. Первая часть была посвящена рецептам компонентов, о которых я уже делал небольшой пост.
Вторая часть должна была затронуть работу с состояниями, но, как часто бывает с крупными замыслами, в условиях нехватки времени процесс затягивается. Поэтому я решил поделиться хотя бы частью материала, который уже подготовлен.
В этой части расскажу о работе с состояниями компонентов в дизайн-системах, а конкретно — о состояниях наведения и нажатия, как не рисовать их для каждого компонента, а проработать модель получения этих состояний один раз, и использовать по всей системе. Такой подход уже помог мне в нескольких дизайн-системах упростить работу с состояниями, сократить количество вариантов в Figma и повысить консистентность и управляемость.
Почти уверен, что существует ещё множество способов добиться аналогичных результатов, но я выбрал два: проверенный метод, проверенный, который не раз использовал, и другой более гибкий но сложный, который считаю потенциально интересным. Будет здорово, если в комментариях поделитесь, как подходите к этой задаче вы в своих дизайн-системах😉
Также интересно, насколько удобен такой формат постов для чтения.
А я в следующей части расскажу о том, как работаю со свойством disabled.
- - - -
#дизайн #uxui #дизайнсистемы #длиннопост #состояния #figma
🛫 Канал: UXFLOW • Сергей Мухин
Уже довольно давно я пишу большую статью о своём подходе к проектированию дизайн-систем: как я преобразую сущности в абстракции. Первая часть была посвящена рецептам компонентов, о которых я уже делал небольшой пост.
Вторая часть должна была затронуть работу с состояниями, но, как часто бывает с крупными замыслами, в условиях нехватки времени процесс затягивается. Поэтому я решил поделиться хотя бы частью материала, который уже подготовлен.
В этой части расскажу о работе с состояниями компонентов в дизайн-системах, а конкретно — о состояниях наведения и нажатия, как не рисовать их для каждого компонента, а проработать модель получения этих состояний один раз, и использовать по всей системе. Такой подход уже помог мне в нескольких дизайн-системах упростить работу с состояниями, сократить количество вариантов в Figma и повысить консистентность и управляемость.
Почти уверен, что существует ещё множество способов добиться аналогичных результатов, но я выбрал два: проверенный метод, проверенный, который не раз использовал, и другой более гибкий но сложный, который считаю потенциально интересным. Будет здорово, если в комментариях поделитесь, как подходите к этой задаче вы в своих дизайн-системах
Также интересно, насколько удобен такой формат постов для чтения.
А я в следующей части расскажу о том, как работаю со свойством disabled.
- - - -
#дизайн #uxui #дизайнсистемы #длиннопост #состояния #figma
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥13
Про идеальные формулы
Когда-то я читал, что в последние годы шахматы перестали быть игрой стратегов. Мастерство шахматистов достигло уровня, где они просто запоминают все возможные комбинации и ходы. Так появились шахматы Фишера, где начальная расстановка фигур случайна, чтобы вернуть игре элемент неожиданности и интереса.
Похожее, кажется, происходит и в дизайне. Вместо экспериментов и рискованных решений всё как будто свелось к «идеальным формулам». Достаточно взглянуть на современные смартфоны или автомобили (особенно боком), чтобы заметить, как они стали практически идентичными. Лишь иногда кто-то осмеливается на эксперимент, создает продукт с авторским дизайном, проваливается в продажах (или изначально не ориентируется на массовый рынок) — и этим укрепляет остальных в вере в «проверенные решения».
В интерфейсах это особенно заметно. Смелый новаторский дизайн в основном обитает в портфолио дизайнеров и дизайн-студий, а в крупных продуктах минимализм стал доминирующим стилем для большинства сервисов, а UI-решения настолько усреднились, что отличить один продукт от другого можно разве что по логотипу и фирменным цветам. Особенно это видно в утилитарных экранах крупных сервисов, например, в каталогах маркетплейсов.
Чтобы развлечься, предлагаю сыграть в игру: попробуйте угадать, какой это маркетплейс, если я уберу узнаваемые элементы.😁
Нет, я уверен, что опытные пользователи всё равно разберутся. Но так или иначе, видно, что дизайн становится всё более единообразным.
- - - -
#дизайн #uxui #маркетплейс #интерфейс #викторина
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Когда-то я читал, что в последние годы шахматы перестали быть игрой стратегов. Мастерство шахматистов достигло уровня, где они просто запоминают все возможные комбинации и ходы. Так появились шахматы Фишера, где начальная расстановка фигур случайна, чтобы вернуть игре элемент неожиданности и интереса.
Похожее, кажется, происходит и в дизайне. Вместо экспериментов и рискованных решений всё как будто свелось к «идеальным формулам». Достаточно взглянуть на современные смартфоны или автомобили (особенно боком), чтобы заметить, как они стали практически идентичными. Лишь иногда кто-то осмеливается на эксперимент, создает продукт с авторским дизайном, проваливается в продажах (или изначально не ориентируется на массовый рынок) — и этим укрепляет остальных в вере в «проверенные решения».
В интерфейсах это особенно заметно. Смелый новаторский дизайн в основном обитает в портфолио дизайнеров и дизайн-студий, а в крупных продуктах минимализм стал доминирующим стилем для большинства сервисов, а UI-решения настолько усреднились, что отличить один продукт от другого можно разве что по логотипу и фирменным цветам. Особенно это видно в утилитарных экранах крупных сервисов, например, в каталогах маркетплейсов.
Чтобы развлечься, предлагаю сыграть в игру: попробуйте угадать, какой это маркетплейс, если я уберу узнаваемые элементы.
Нет, я уверен, что опытные пользователи всё равно разберутся. Но так или иначе, видно, что дизайн становится всё более единообразным.
- - - -
#дизайн #uxui #маркетплейс #интерфейс #викторина
Please open Telegram to view this post
VIEW IN TELEGRAM
💯7😁3🔥2
UX FLOW • Сергей Мухин
Про идеальные формулы Когда-то я читал, что в последние годы шахматы перестали быть игрой стратегов. Мастерство шахматистов достигло уровня, где они просто запоминают все возможные комбинации и ходы. Так появились шахматы Фишера, где начальная расстановка…
Ну как вам формат викторины? 😁
Если интересно себя проверить, ниже будет, как на самом деле всё было.
ПРАВИЛЬНЫЙ ОТВЕТ:
Если интересно себя проверить, ниже будет, как на самом деле всё было.
ПРАВИЛЬНЫЙ ОТВЕТ:
🔥13😁6
UX FLOW • Сергей Мухин
Про идеальные формулы Когда-то я читал, что в последние годы шахматы перестали быть игрой стратегов. Мастерство шахматистов достигло уровня, где они просто запоминают все возможные комбинации и ходы. Так появились шахматы Фишера, где начальная расстановка…
* Пока пишется вторая часть (осталось совсем немного), небольшое дополнение.
Нужно ли отображать все состояния в вариантах компонента в Figma?
И да, и нет. Зачастую достаточно лишь документации, особенно если использовать модели состояний, о которых я рассказываю.
Часто вижу, как для каждой кнопки в Figma прорисовывают disabled, focus и другие состояния...
А вы часто используете все эти свойства в макетах? Если какого-то состояния нет в варианте, но есть в документации для разработчика и для дизайнера инструкция, как его получить, это, на мой взгляд, гораздо эффективнее. Посмотрите на обложке поста, как это выглядело у компонента в одной из моих дизайн-систем: в вариантах нет состояний, а способ получения disabled описан только в документации, с примером на инстансе компонента. За два года работы с этой системой ни разу не пожалели о таком подходе. Пару раз, когда мне или дизайнеру таки понадобился disabled в макете, мы добавляли его за 30 секунд, а поддерживать компоненты в библиотеке стало значительно проще.
Наверное какой-то смысл отражать всё в вариантах появился с внедрением девмода, чтобы из песочницы разработчик мог бы потыкать сам состояния. Но всё равно на мой взгляд это очень избыточно, и проще это лечить через процессы.
- - - -
#дизайн #uxui #дизайнсистемы #состояния #figma
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Нужно ли отображать все состояния в вариантах компонента в Figma?
И да, и нет. Зачастую достаточно лишь документации, особенно если использовать модели состояний, о которых я рассказываю.
Часто вижу, как для каждой кнопки в Figma прорисовывают disabled, focus и другие состояния...
А вы часто используете все эти свойства в макетах? Если какого-то состояния нет в варианте, но есть в документации для разработчика и для дизайнера инструкция, как его получить, это, на мой взгляд, гораздо эффективнее. Посмотрите на обложке поста, как это выглядело у компонента в одной из моих дизайн-систем: в вариантах нет состояний, а способ получения disabled описан только в документации, с примером на инстансе компонента. За два года работы с этой системой ни разу не пожалели о таком подходе. Пару раз, когда мне или дизайнеру таки понадобился disabled в макете, мы добавляли его за 30 секунд, а поддерживать компоненты в библиотеке стало значительно проще.
Наверное какой-то смысл отражать всё в вариантах появился с внедрением девмода, чтобы из песочницы разработчик мог бы потыкать сам состояния. Но всё равно на мой взгляд это очень избыточно, и проще это лечить через процессы.
- - - -
#дизайн #uxui #дизайнсистемы #состояния #figma
Please open Telegram to view this post
VIEW IN TELEGRAM
UX FLOW • Сергей Мухин
* Пока пишется вторая часть (осталось совсем немного), небольшое дополнение. Нужно ли отображать все состояния в вариантах компонента в Figma? И да, и нет. Зачастую достаточно лишь документации, особенно если использовать модели состояний, о которых я рассказываю.…
Please open Telegram to view this post
VIEW IN TELEGRAM
😁30
Короче, я сделал сайт (на самом деле ещё нет 😬 )
Я уже делился планами сделать себе сайт. И вот, дело, наконец, сдвинулось! Выбрал для этого Тильду по нескольким причинам: её удобно оплатить из РФ, есть прямые интеграции с нужными сервисами, например, с Telegram-ботом для парсинга контента с канала.
Когда сам верстаешь свой же дизайн, открывается пара забавных инсайтов.
Первый — оказывается, делать сайт для себя невероятно лень, и, садясь за работу, вдруг не знаешь, чего хочешь, какая будет структура, что главное (становишься типичным «заказчиком»).
Второй — если верстка не выходит в точности по макету, просто делаешь «как смотрится норм», а потом просто правишь в макете👀
Короче, упражнение «Сверстай свой дизайн» до сих пор работает. Только теперь не на понимание, как лучше сделать макет, а чтобы лучше понятьлень боль верстальщиков и заказчиков 😂
- - - -
#дизайн #сайт #боль
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Я уже делился планами сделать себе сайт. И вот, дело, наконец, сдвинулось! Выбрал для этого Тильду по нескольким причинам: её удобно оплатить из РФ, есть прямые интеграции с нужными сервисами, например, с Telegram-ботом для парсинга контента с канала.
Когда сам верстаешь свой же дизайн, открывается пара забавных инсайтов.
Первый — оказывается, делать сайт для себя невероятно лень, и, садясь за работу, вдруг не знаешь, чего хочешь, какая будет структура, что главное (становишься типичным «заказчиком»).
Второй — если верстка не выходит в точности по макету, просто делаешь «как смотрится норм», а потом просто правишь в макете
Короче, упражнение «Сверстай свой дизайн» до сих пор работает. Только теперь не на понимание, как лучше сделать макет, а чтобы лучше понять
- - - -
#дизайн #сайт #боль
Please open Telegram to view this post
VIEW IN TELEGRAM
😁17🔥1👀1
UX FLOW • Сергей Мухин
Короче, я сделал сайт (на самом деле ещё нет 😬 ) Я уже делился планами сделать себе сайт. И вот, дело, наконец, сдвинулось! Выбрал для этого Тильду по нескольким причинам: её удобно оплатить из РФ, есть прямые интеграции с нужными сервисами, например, с Telegram…
Media is too big
VIEW IN TELEGRAM
В продолжение, вот пример неведомой фигни, особенно дизайнерам полезно.
Когда вроде бы всё понятно, что надо сделать, но у кода своё мнение. Хотел скруглить в шаблоне новостного блока все фоточки. Всё просто — скругляешь родительский контейнер и чтобы переполнение было content clip (overflow: hidden).
Но почему-то это каким-то образом влияет на размер элемента... Просидел, наверное, час, пытаясь понять, что не так, в итоге углы остались прямые🐱
Вот если за одно, тут есть знатоки тильды, подскажут, как это, блин, побороть😬
- - - -
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Когда вроде бы всё понятно, что надо сделать, но у кода своё мнение. Хотел скруглить в шаблоне новостного блока все фоточки. Всё просто — скругляешь родительский контейнер и чтобы переполнение было content clip (overflow: hidden).
Но почему-то это каким-то образом влияет на размер элемента... Просидел, наверное, час, пытаясь понять, что не так, в итоге углы остались прямые
Вот если за одно, тут есть знатоки тильды, подскажут, как это, блин, побороть😬
- - - -
Please open Telegram to view this post
VIEW IN TELEGRAM
🙈6
Про состояние фокус (focus)
Подходов к реализации focus существует множество: от полного следования нативному поведению до довольно экзотических методов. И вот недавно в одном комьюнити наткнулся на мнение: "А зачем рисовать отдельно состояние focus? Сделаем его таким же, как hover."
Не делайте так.😱
Расскажу, как я привык работать с фокусом и почему. Главное его назначение — удобство навигации с клавишей Tab, что особенно важно для слабовидящих пользователей. Конечно, Tab используют и вполне хорошо видящие, но они точно не будут против, если вы сделаете фокус чуть более заметным.
Вот и причина номер uno не оформлять его как hover🤨 .
Если перенести эту тему в дизайнерские абстракции, то бывают ситуации, где фокус пересекается с другими состояниями. Например, в нативе для поля ввода фокус — это момент, когда активен курсор. В моих дизайн-системах я разделяю фокус, полученный кликом мыши, и фокус, активируемый клавишей Tab.
Кроме того фокус может комбинироваться с другими свойствами, например, кнопка в фокусе может принять в это время и состояние hover или быть нажата.
Вот и причина номер duos не оформлять фокус как hover🤨 .
Как я это реализую? Ну конечно отдельным компонентом, как же ещё. Я называю его focus frame. Он активируется только через клавишу Tab, в него оборачиваются все элементы, которые могут быть в фокусе, и им передается состояние фокуса. Чаще всего визуально это оформлено как контур, достаточно контрастный и чуть толще обычных бордеров (2 - 3 px). Такой подход позволяет управлять оформлением из одного места, сохраняет консистентность и легко сочетается с другими состояниями компонентов.
Вот такой вот вышел фокус...
- - - -
#дизайн #uxui #дизайнсистемы #состояния #фокус
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Подходов к реализации focus существует множество: от полного следования нативному поведению до довольно экзотических методов. И вот недавно в одном комьюнити наткнулся на мнение: "А зачем рисовать отдельно состояние focus? Сделаем его таким же, как hover."
Не делайте так.
Расскажу, как я привык работать с фокусом и почему. Главное его назначение — удобство навигации с клавишей Tab, что особенно важно для слабовидящих пользователей. Конечно, Tab используют и вполне хорошо видящие, но они точно не будут против, если вы сделаете фокус чуть более заметным.
Вот и причина номер uno не оформлять его как hover
Если перенести эту тему в дизайнерские абстракции, то бывают ситуации, где фокус пересекается с другими состояниями. Например, в нативе для поля ввода фокус — это момент, когда активен курсор. В моих дизайн-системах я разделяю фокус, полученный кликом мыши, и фокус, активируемый клавишей Tab.
Кроме того фокус может комбинироваться с другими свойствами, например, кнопка в фокусе может принять в это время и состояние hover или быть нажата.
Вот и причина номер duos не оформлять фокус как hover
Как я это реализую? Ну конечно отдельным компонентом, как же ещё. Я называю его focus frame. Он активируется только через клавишу Tab, в него оборачиваются все элементы, которые могут быть в фокусе, и им передается состояние фокуса. Чаще всего визуально это оформлено как контур, достаточно контрастный и чуть толще обычных бордеров (2 - 3 px). Такой подход позволяет управлять оформлением из одного места, сохраняет консистентность и легко сочетается с другими состояниями компонентов.
Вот такой вот вышел фокус...
- - - -
#дизайн #uxui #дизайнсистемы #состояния #фокус
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21
Освещение в UI
Недавно решил размять мозг и фантазию, поделав чисто UI на чём-то абстрактном. Цель была сделать максимально стильно-модно-молодёжно, но дизайн-системы проникли уже слишком глубоко в мой мозг.
Хочу поделиться шальной мыслью: нашел интересный концепт — видел в Dribbble шотах, не помню у кого, как свечение одного объекта будто бы отражается на соседних. Там это было сделано точечно, но сразу мысль: а что если построить на этом весь движок?
Идея, в общем, понятна. Создаётся отдельный слой для «свечения» объектов, поверх него накладывается маска поверхностей и обводок. При любых изменениях обновлять оба слоя. В идеале ещё высчитывать длину и направление теней...👀
Поспрашивал разработчиков — говорят, что в теории такое возможно реализовать. Но вот в реальности это может превратиться в кошмар: отладка, чтобы не запороть производительность до 10 fps на среднестатистическом Android-смартфоне.
Интересно, кто-нибудь уже пробовал провернуть что-то подобное на системном уровне? 🤔
- - - -
#дизайн #ui #эксперимент #дизайнсистемы
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Недавно решил размять мозг и фантазию, поделав чисто UI на чём-то абстрактном. Цель была сделать максимально стильно-модно-молодёжно, но дизайн-системы проникли уже слишком глубоко в мой мозг.
Хочу поделиться шальной мыслью: нашел интересный концепт — видел в Dribbble шотах, не помню у кого, как свечение одного объекта будто бы отражается на соседних. Там это было сделано точечно, но сразу мысль: а что если построить на этом весь движок?
Идея, в общем, понятна. Создаётся отдельный слой для «свечения» объектов, поверх него накладывается маска поверхностей и обводок. При любых изменениях обновлять оба слоя. В идеале ещё высчитывать длину и направление теней...
Поспрашивал разработчиков — говорят, что в теории такое возможно реализовать. Но вот в реальности это может превратиться в кошмар: отладка, чтобы не запороть производительность до 10 fps на среднестатистическом Android-смартфоне.
Интересно, кто-нибудь уже пробовал провернуть что-то подобное на системном уровне? 🤔
- - - -
#дизайн #ui #эксперимент #дизайнсистемы
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14
Слоты в компонентах
Наткнулся на пост о том, что в Material Design внедрили концепцию слотов в компонентах. Честно говоря, ощущение, что про слоты дизайнеры дизайн-систем говорят уже пару лет минимум. А тут весь такой большой, технологичный и богатый MD… Может, это у меня завышенные ожидания от систем такого уровня, но, кажется, они могли бы придумать что-то более продвинутое для вариативности дизайн-системы, чем концепция слотов, которой уже пара лет (тот же SDUI из коробки, например 😉).
Но как бы там ни было, для тех, чьи дизайн-системы базируются на нативном MD, это явно приятное событие. И в целом, как описание механики работы слотов, пост получился полезный. К тому же от самих Google!
- - - -
#дизайн #MD #materialdesign #дизайнсистемы #google #android
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Наткнулся на пост о том, что в Material Design внедрили концепцию слотов в компонентах. Честно говоря, ощущение, что про слоты дизайнеры дизайн-систем говорят уже пару лет минимум. А тут весь такой большой, технологичный и богатый MD… Может, это у меня завышенные ожидания от систем такого уровня, но, кажется, они могли бы придумать что-то более продвинутое для вариативности дизайн-системы, чем концепция слотов, которой уже пара лет (тот же SDUI из коробки, например 😉).
Но как бы там ни было, для тех, чьи дизайн-системы базируются на нативном MD, это явно приятное событие. И в целом, как описание механики работы слотов, пост получился полезный. К тому же от самих Google!
- - - -
#дизайн #MD #materialdesign #дизайнсистемы #google #android
Please open Telegram to view this post
VIEW IN TELEGRAM
Material Design
Unlocking component flexibility with slots in Figma
One less reason to “detach instance”
🔥6
Настало время ответить на самый важный вопрос проектирования дизайн-систем — да что там, всего IT!
И это не как назвать правильно токены, и не сколько нужно видов кнопок в системе, это:
Сколько же стоит перекрасить кнопку в крупной компании?
И опережая ваши догадки, ответ не 42...
Давайте посчитаем на примере нашего процесса в мобильном приложении.
1. Дизайн
Кажется, что час работы дизайнера с запасом покрывает задачу. Но не забываем про прототип: мы же в продуктовой компании! Это исследования, юзертесты...
Час уходит на прототипирование, ещё 3–4 часа — на работу исследователя (разработка эксперимента, загрузка в Pathway, сбор данных). После этого дизайнеру нужно подготовить макеты для разработки.
Итог: 6 часов работы. Со средней ставкой в 1500 ₽/час это 9000 ₽.
2. Разработка
Допустим, цвет кнопки не управляется с бэкенда. Тогда в дело вступают iOS- и Android-разработчики (по часу работы каждого). Затем — тестировщики (по часу на каждую платформу). Если обнаружатся баги, это ещё по часу на исправление и проверку для каждой платформы.
Итог: 8 часов работы. Со средней ставкой в 2000 ₽/час это 16 000 ₽.
Общая сумма на данном этапе: 9000 + 16 000 = 25 000 ₽.
А если кнопка сквозная, например "добавить в корзину"?
Ну, это совсем другой разговор. Привет зависимости.😬
Это из-за того, что кнопка используется в компонентах/экранах других команд.
Во-первых, требуется участие архитектора. Это человек, который первым лишится премии или работы, если что-то сломается. Поэтому любое изменение с зависимостями проходит через него. Скажем, его ставка минимум 4000 ₽/час: час на включить компьютер, час на подготовку, час на изучение задачи, час на составление заключения.
Дальше — сложнее. Допустим, кнопка используется в компонентах и экранах пяти команд. Значит, затраты на разработку (16 000 ₽) умножаются на 5.
Итого:
— Разработка: 80 000 ₽
— Дизайн и исследования: 9000 ₽
— Архитектор: 16 000 ₽
Сумма к этому моменту: 105 000 ₽.
Добавляем 30% на встречи, правки и риски, плюс ещё 10% на A/B тестирование. А чтобы оценить результаты тестирования, нужны данные, т.е. нужны логи... ещё 10%.
А ещё забыл совсем про аналитиков😱 Эти ребята сначала должны описать все случаи использования кнопки и все компоненты, в которых она используется. Часов 4-6 со средней ставкой 1500 ₽.
Окончательная сумма:около 170 000 ₽ , чтобы просто перекрасить кнопку.
Понятно, что подсчёты грубые. Но в реальности бывает очень похоже, а то и похлеще. Например, мы уже год пытаемся занести задачу перекрасить ценники в приложении, но постоянно проигрываем гонку приоритетов. Нет ресурсов.😬
- - - -
#деньги #перекраситькнопку #разработка #дизайнсистемы
🛫 Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
И это не как назвать правильно токены, и не сколько нужно видов кнопок в системе, это:
И опережая ваши догадки, ответ не 42...
Давайте посчитаем на примере нашего процесса в мобильном приложении.
1. Дизайн
Кажется, что час работы дизайнера с запасом покрывает задачу. Но не забываем про прототип: мы же в продуктовой компании! Это исследования, юзертесты...
Час уходит на прототипирование, ещё 3–4 часа — на работу исследователя (разработка эксперимента, загрузка в Pathway, сбор данных). После этого дизайнеру нужно подготовить макеты для разработки.
Итог: 6 часов работы. Со средней ставкой в 1500 ₽/час это 9000 ₽.
2. Разработка
Допустим, цвет кнопки не управляется с бэкенда. Тогда в дело вступают iOS- и Android-разработчики (по часу работы каждого). Затем — тестировщики (по часу на каждую платформу). Если обнаружатся баги, это ещё по часу на исправление и проверку для каждой платформы.
Итог: 8 часов работы. Со средней ставкой в 2000 ₽/час это 16 000 ₽.
Общая сумма на данном этапе: 9000 + 16 000 = 25 000 ₽.
А если кнопка сквозная, например "добавить в корзину"?
Ну, это совсем другой разговор. Привет зависимости.
Это из-за того, что кнопка используется в компонентах/экранах других команд.
Во-первых, требуется участие архитектора. Это человек, который первым лишится премии или работы, если что-то сломается. Поэтому любое изменение с зависимостями проходит через него. Скажем, его ставка минимум 4000 ₽/час: час на включить компьютер, час на подготовку, час на изучение задачи, час на составление заключения.
Дальше — сложнее. Допустим, кнопка используется в компонентах и экранах пяти команд. Значит, затраты на разработку (16 000 ₽) умножаются на 5.
Итого:
— Разработка: 80 000 ₽
— Дизайн и исследования: 9000 ₽
— Архитектор: 16 000 ₽
Сумма к этому моменту: 105 000 ₽.
Добавляем 30% на встречи, правки и риски, плюс ещё 10% на A/B тестирование. А чтобы оценить результаты тестирования, нужны данные, т.е. нужны логи... ещё 10%.
А ещё забыл совсем про аналитиков😱 Эти ребята сначала должны описать все случаи использования кнопки и все компоненты, в которых она используется. Часов 4-6 со средней ставкой 1500 ₽.
Окончательная сумма:
Понятно, что подсчёты грубые. Но в реальности бывает очень похоже, а то и похлеще. Например, мы уже год пытаемся занести задачу перекрасить ценники в приложении, но постоянно проигрываем гонку приоритетов. Нет ресурсов.
- - - -
#деньги #перекраситькнопку #разработка #дизайнсистемы
Please open Telegram to view this post
VIEW IN TELEGRAM
😁19💯4🔥1
Что такое абстракции, и зачем ими мыслить? Как это помогает делать масштабируемые дизайн-системы? Что такое модели состояний и рецепты компонентов?
Рассказываю на мини вебинаре
в сообществе
- - - -
#вебинар #pinkman #дизайнсистемы #анонс
Please open Telegram to view this post
VIEW IN TELEGRAM