Мыслью по древу • UXFLOW • Сергей Мухин

Мыслью по древу • UXFLOW • Сергей Мухин

@uxflow
Изображение канала: Мыслью по древу • UXFLOW • Сергей Мухин
651 подписчик
14 постов
Посты
Функции дизайн-системы
Хочется продолжить брюзжание на тему дизайн-систем. Обычно я делюсь мыслями, исходя из реального рабочего процесса, но сейчас, будучи безработным, возьму материал из собеседований. 😁 Недавно, рассказывая о своих дизайн-системах, столкнулся с удивлённой реакцией: у меня в документации подробно описаны свойства и поведение компонентов, но нет чёткого указания, когда и как их использовать. Например, чем чекбокс отличается от свитчера? Или насколько «зелёную» кнопку должен выбрать дизайнер? Как же дизайнер поймёт, что ему делать? Причина простая — такой потребности просто не возникало. Дизайн-система для меня — это инструмент, а не диктатура. Я никогда не стремился бить дизайнеров по рукам, навязывая им, как именно им делать свою работу. Ответственность за пользовательский опыт и принятие решений лежит на продуктовых дизайнерах. Ну и общее правило, которое я подрезал у знакомого разработчика, и постоянно цитирую: «Миром правит любовь, в её отсутствие — здравый смысл». Поэтому меня искренне удивило, что именно этого ждали от дизайнера ДС. Более того, с предыдущим кандидатом, как оказалось, попрощались именно из-за того, что он не определял сценарии применения компонентов. Ну и совсем меня убило: рекрутер сделал вывод, что раз я не описал правила использования, значит, сам их не знаю. 🤯 Мне повезло: во всех компаниях, где я строил ДС, я параллельно либо лидил продуктовых дизайнеров, либо возглавлял весь дизайн-направление. Это позволяло настраивать процессы так, что за качество пользовательского опыта всегда отвечали именно продуктовые дизайнеры. Ведь если дизайнер ДС берёт на себя ещё и проработку всех сценариев, то либо их (дизайнеров ДС) рано или поздно станет практически столько же, сколько продуктовых дизайнеров, либо система превращается в ограничивающий инструмент. В итоге — узкие горлышки, нехватка компонентов, невозможность сделать хорошо, а только «как позволяет система». При этом я вовсе не против best practices и гайдов по использованию прямо в документации ДС. Особенно если продуктовым дизайнерам удобно получать информацию там. Но источник этих знаний должен быть в продуктовых командах, а не исключительно в голове дизайнера ДС. А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать? - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Внедрение дизайн-системы сложнее чем реализация
Часто в чатиках и дизайнерских комьюнити вижу истории о том, как небольшая команда на молодом проекте берётся за дизайн-систему. Один-два дизайнера, десяток разработчиков, быстрые договорённости с фронтами — и вот, ресурсы выбиты, процесс пошёл. Завидую… Когда дизайнеры начинают работать над дизайн-системой, их главный фокус — сама реализация: какие компоненты нужны, как их организовать, какие механизмы использовать. И это действительно важно. Если команда маленькая, а проект свежий, достаточно просто начать — остальное наладится в процессе. Но что, если у вас сотни разработчиков, миллионы пользователей, а дизайн-системы нет вовсе? Более того, нет даже базового UI Kit’а, от которого можно было бы оттолкнуться? В таких условиях всё усложняется. Конкретные решения уже не так важны, на первый план выходят процессы, политика и поиск союзников. Нужно договариваться, продвигать ценность дизайн-системы, убеждать команды, которые привыкли работать по старым схемам. И главное — внедрять систему так, чтобы не спровоцировать саботаж (а такое бывает), когда команды будут стараться работать старыми методами игнорируя новые процессы и всячески тормозить внедрение новой системы. Иначе даже самая идеально спроектированная дизайн-система останется просто очередной папкой в Фигме. Дизайн-система — это не только про кнопки и компоненты. Это про людей, процессы и умение менять культуру работы. Это важно не упускать, и не зацикливаться только на токенах и компонентах. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Про портфолио продуктовых дизайнеров
Cамый частый запрос сейчас на консультации — прожарить портфолио, дать рекомендации по его оформлению. Решил поделиться самыми очевидными, на мой взгляд, мыслями, чтобы консультации оставить для действительно сложных проблем, которые стоило бы обсудить. ВАШИ КЛИЕНТЫ Если вы продуктовый дизайнер, вы должны понимать, о чём я говорю, ведь портфолио — это ваш продукт. Поймите, кто ваш клиент, как он использует ваш продукт — то есть как и кто читает ваше портфолио и что для него самое важное. Основные "клиенты" вашего портфолио (если вы не фрилансер): 🔺 HR — чаще всего смотрит с чек-листом в руках плюс субъективное восприятие. Для них важно просто наличие портфолио. Иногда у них есть чек-лист от лида, например: «Главное, чтобы не ссылка на Диск». Со временем HR, просмотрев сотни портфолио и наблюдая за реакцией лида, начинают чувствовать, кого точно не стоит передавать дальше. Поэтому здесь лучше минималистичные кейсы: 1–2 картинки + кратко: - Какую задачу решали? - Что делали? - Какой результат получили? 💡 Совет: Экономьте время HR'а, и он это оценит. 🔺Руководитель НЕ дизайнер (чаще всего продакт-менеджер) — им важно понять механизм принятия решений. Достаточно пары ярких картинок, чтобы убедить, что вы умеете в UI, а дальше — раскрыть процесс: - Как вы работали с данными? - Как измеряли успех? - Как принимали решения? 🔺Руководитель-дизайнер — сам опытный дизайнер, поэтому будет копаться в деталях. Он будет смотреть на качество реализации, сборку макета, и на сколько вы технически подкованы. Тут важно: - Показать разные состояния интерфейса, логику работы, динамику и анимации. - Добавить ссылку на Фигму, чтобы пощупать макет изнутри (но Фигма должна быть чистой и понятной, а не свалкой из неподписанных макетов). ПРО ФОРМУ Исходя из выше написанного, оптимальная структура кейса: Первая страница\экран — краткая выжимка для HR + картинка. Скролл вниз или кнопка «Подробнее» → развёрнутое описание. Ссылки на макеты в Фигме, прототипы для дизайн-лидов. Сайт, Dribbble/Behance или Notion — вот в чём вопрос. Dribbble и Behance больше про охваты и лайки, а не про продуктовые кейсы. К тому же они слишком линейные, что не всегда удобно. Notion остаётся хорошим быстрым и дешёвым вариантом, но когда я сам недавно нанимал дизайнеров, понял, что все портфолио в Notion сливаются в единый монолит — сложно запомнить, кто из кандидатов что делал. Лучший вариант — персонализированный сайт (даже на конструкторе). Он помогает выделиться, даёт больше контроля и возможностей, при этом не намного сложнее в реализации, чем Notion. На самом деле вариантов больше. Например, пару лет назад я сделал портфолио прямо в Фигме, оформив его как прототип, и получил с ним оффер от ВкусВилла. Сейчас у меня свой сайт, и вам советую делать так же. КАК НЕ НАДО Я уже писал, что нужно экономить время HR, но это оценят и остальные. Поэтому никаких архивов и ссылок на Яндекс.Диск. Из моей практики самые жёсткие антипримеры: - Архив на Яндекс.Диске, в котором два .doc-файла с ссылками на Behance 🙈 - Логин и пароль от Behance вместо ссылки на портфолио 🤯 Ещё один момент: мокапы. Дизайн не должен мешать получению смысла. Главное - это ваши макеты, а не в какой макбук или айфон вы их вставили. И, я вас заклинаю, не поворачивайте макеты в мокапе ни в какую сторону. Вот прям фронтально показывайте с углом поворота 0°, разглядывать "креативные" мокапы в изометрии болит шея к концу дня. ТОЛЬКО ЦЕННОЕ Финальный совет — пишите о реальном опыте и вызовах. ❌ Никого не интересует, какие шрифты и цвета вы использовали. Никому не важны CJM и персоны, если они не повлияли на финальное решение, и сделаны в момент оформления кейса, а не во время работы над задачей. ✅ Опишите, какие инсайты вы получили и как они повлияли на результат. Если вам кажется, что опыт не релевантный — напишите, чему научились. Опыта мало — вытащите всё полезное и важное из тех кейсов, что есть. Будьте честны, пишите про реальные сложности — и ваше портфолио обязательно заметят. - - #портфолио 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Сколько арт-директоров нужно, чтобы сделать проект по окружающему миру в 4 классе?
Контент выходного дня. Каждый раз поражаюсь школьным домашним заданиям — там проекты один краше другого. Вот, например, в 3 классе задали провести интервью на тему «Кто нас защищает». В итоге пришлось привлечь трёх взрослых: один помог подготовить вопросы, второй дал интервью, третий оформил проект. Но теперь я вообще в шоке. По теме славянской письменности задали сделать отрывок любого текста в старославянском стиле… на состаренной бумаге (!!!) 🤯 Выбрали отрывок из какой-то детской книжки. Не думал я, что в 4 классе буду учить дочь, как рисуется славянская вязь, и чем акцидентный шрифт отличается от текстового. Даже интересно, как выкрутились остальные. - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Как-то в компании пришло время нанимать дизайнеров. И вот впервые мне выдали доступ в HR-CRM, кажется, это был Huntflow. Отказывая кандидату, я увидел выпадающее меню «Причина отказа» и нашёл там пункт «Переизбыток опыта».
"WTF?" — подумал я. Как вообще может быть слишком много опыта? Нет, теоретически понятно: если я прямо сейчас откликнусь на позицию джуна, все покрутят пальцем у виска — "сдурел?" — и нажмут "overqualified". Но мне казалось, что это редчайший кейс. Однако со временем я начал сталкиваться с этим всё чаще. Причины у отказов с пометкой overqualified разные: от завышенных зарплатных ожиданий до перспектив дальнейшего роста. Даже если я прохожу по деньгам, но работодатель видит, что у меня слишком много опыта и мои потребности выходят за рамки роли, логично предположить, что вскоре я начну просить больше полномочий, более интересный проект или просто уйду в другую компанию на релевантную позицию. Поэтому на меня изначально не хотят тратить ресурс, считая заведомо рискованным кандидатом. А мораль этой басни в чём? В начале карьеры все страдают от недостатка опыта, потому что работодатели мечтают о 18-летних джунах с 15-летним стажем. И мало кто задумывается, что однажды опыта может стать слишком много. Кажется, что после определённого уровня найм превратится в рай: компании будут сами стучаться в личку, преклоняться перед твоими скиллами и засыпать оферами. Но на деле процесс найма просто меняется. Вакансий становится меньше, многие из них уходят в непубличный сегмент, а попасть на них можно только через прямые контакты с рекрутерами и руководителями. А в откликах всё чаще мелькает "переизбыток опыта". Найм — это всегда сложно, рискованно и непредсказуемо. Неважно, джун вы или дизайн-директор — на каждом этапе есть свои нюансы, и легко не будет никогда. Всё, что могу посоветовать: заранее продумывайте стратегию поиска, развивайте нетворкинг и не расслабляйтесь.😬 - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Про поиск работы, пет-проекты и отдых
Раньше я не понимал, как люди увольняются «в никуда» — без оффера, да ещё и берут перерыв на отдохнуть от работы. А теперь сам в такой ситуации. Казалось бы, без работы можно наконец спать до обеда и заниматься чем попало. Но привычки берут своё: в 9 утра я уже за рабочим местом. И дел всегда хватает — общение с потенциальными работодателями, созвоны… В общем, как будто мало что поменялось. Поиск новой работы — это всегда приключение. Только привыкаешь к одному процессу, например, будучи сеньором, как всё снова меняется: теперь ты уже лидер. Есть мысль подробно описать этот опыт — как выглядит поиск работы на позициях выше тимлида. Но сначала надо её найти. 😬 Хотя одной интересной деталью точно поделюсь в ближайшее время, не переключайтесь. 😉 Кроме поиска работы я бросил силы на пет-проекты. Некоторые пока секретные (расскажу, когда будет что показать), а часть — это неожиданно стрельнувшие консультации. Сразу несколько заявок прилетело в день поста — даже не ожидал. Теперь стабильно несколько созвонов в неделю по этому направлению. На фоне всего этого я вдруг понял, что про отдых вообще забыл. Пришлось заставить себя взять паузу на неделю и даже выгнать себя в небольшую поездку. Теперь заряд энергии получен, и можно снова фигачить. 💪 - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
КОНСУЛЬТИРУЮ!
Я уже писал о своём отношении к менторству и курсам, и оно не изменилось. Но в последнее время ко мне начали поступать настойчивые запросы на консультации — в том числе корпоративные. Судя по отзывам, удалось причинить ощутимую пользу. Поэтому теперь я официально консультирую. 😅 ЧЕМ МОГУ ПОМОЧЬ? ✅ Аудит процессов дизайна в отделе/компании: поиск узких мест, варианты решения. ✅ Аудит проекта: качество реализации, стандарты, технологические процессы. ✅ Разбор проблемы, брейншторм по вариантам решения (дизайн-менеджмент, продуктовый и UI-дизайн, проектирование дизайн-систем и т. д.). ✅ Формат «вопрос-ответ»: обсуждение накопившихся вопросов, в том числе с вашей командой. ✅ Дизайн-системы: можно обсудить процессы, конкретные решения или уже сформировавшуюся боль, поискать оптимальный вариант. Также можно обсудить и другие форматы, например сопровождение проекта, помощь при запуске или другой формат. ПОЧЕМУ Я? На моём сайте есть подробное описание опыта (а также кейсы и публикации): руководство командами разного масштаба, налаживание процессов, проектирование интерфейсов, дизайн-систем (включая кроссплатформенные, мультибрендовые и даже под SDUI-принцип). По всем вопросам пишите мне в личные сообщения. - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Должен ли дизайнер уметь рисовать?
Имеет место в дизайн-среде такое мнение, что художественное образование — обязательная база даже для UX/UI и продуктовых дизайнеров. Меня эта «база» обошла стороной: навыки самые примитивные, постановки руки нет, техники тоже. Долгое время из-за этого у меня был своего рода синдром самозванца — мол, какой же я дизайнер, если рисовать не умею? Правлильно, не настоящий! Но со временем я заметил, что мой дизайн работает лучше, чем у коллег с художественным образованием. В интерфейсном дизайне умение рисовать может быть не преимуществом, а даже препятствием. Дизайнер интерфейсов ближе к инженеру, чем к художнику. Важно понимать, как взаимодействуют элементы, как они влияют на пользовательский опыт и как система ощущается после реализации — а не просто рисовать красивые картинки. А вот если ставить художественные навыки во главу угла, легко сместить фокус на визуал и забыть о главном: как это всё будет работать. Да, понимание композиции, цвета, света и тени полезно, но рисовать от руки для этого не обязательно. Так же, как и для эффективного взаимодействия с разработчиками — совсем не нужно уметь писать код самому. Но вот что действительно меня в своё время прокачало — каллиграфия. Осознание того, как рисуется буква, как работает штрих и перо, углубляет понимание типографики. Но тут тоже важно не переборщить. Я сам когда-то увлёкся, извёл пару альбомов… и бросил, решил, что мне достаточно. 😁 Короче, всё это не ключевые хард-скиллы для продуктового или UX-дизайнера. Да, классно, если вы умеете рисовать. Но, на мой взгляд, это всего лишь второстепенный софт-скилл. А вы умеете рисовать? Помогало ли вам это в работе? Или, может наоборот, чувствовали, что вам не хватает этого навыка? - - - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru
Изображение поста
Человек-документация
Ещё таких называют человек-википедия — когда огромное количество важной информации о работе процессов или проекта находится только в голове конкретного специалиста. Это может создавать иллюзию незаменимости: мол, без тебя всё развалится, ведь никто, кроме тебя, не знает, как тут всё устроено. Я такое называю «взять компанию в заложники», и на деле это плохой признак — свидетельство неумения организовать управление знаниями. В какой-то момент я осознанно начал работать над тем, чтобы не быть таким человеком-википедией. Одной из моих метрик успеха стало то, насколько легко я могу передать дела, если потребуется уйти из проекта или команды. Сейчас в моей голове остаётся только опыт и экспертиза — то, что почти невозможно полностью передать. А вся передача дел уместилась в пару страниц в Notion. Управление знаниями стало одним из ключевых процессов в моей работе во «ВкусВилл» с самого начала. Поэтому были написаны бесчисленные гайды, а ключевые операционные функции переданы лидеру продуктовых дизайнеров. Осталось зафиксировать лишь часть активностей, завязанных на мне, и описать стратегию — то, как я видел развитие ключевых направлений, включая ближайшие шаги. Я доволен. Нет стресса, всё прозрачно и понятно, нет страха что-то забыть или оставить команду без критически важной информации. - - - - 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Изображение поста
Просто мысли вслух
В последние дни я снова вернулся к работе над Китом в Figma. Ранее я показывал, как можно управлять свойствами через variables, даже после отвязки от библиотеки, и применял это в рецептах компонентов. А сейчас я пошёл дальше — вынес часть параметров из вариантов в modes и variables. Поймал себя на мысли, что теперь хочу Enterprise-тариф с почти бесконечным количеством модов, чтобы вынести в управление через переменные практически всё, что раньше было в вариантах. В теории это должно быть невероятно удобно: все параметры компонента видны в табличке, сразу понятна их связь с токенами. Блин, в такой системе я начинаю понимать, чем полезны токены компонента 😁. Конечно, такой душный подход подходит не всем. Но для меня, с моим складом мышления, табличное отображение параметров гораздо удобнее, чем визуальное управление через варианты частными пересечениями свойств компонента. Главное, чтобы не было ограничений на количество модов, а переменные можно было привязать ко всему. - - - - #дизайн #дизайнсистемы #figma #переменные 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Изображение поста
Первые две недели года я провёл в отпуске, и по этому пропустил самую короткую рабочую неделю в году, и только в понедельник начну "вливаться в работу". Думаю, я такой не один 😁. Чтобы немного размяться перед рабочими буднями, предлагаю небольшой интерактив.
Первый раз захотелось подрезать идею поста (отсюда). Читая оригинал, подумал, что моё бинго выглядело бы совсем иначе. Поэтому представляю вам свою версию бинго душного дизайнера. Делитесь в комментариях, что совпало у вас, и предлагайте, что ещё можно было бы добавить в это бинго! 😉 - - - - #дизайн #бинго #не_своровал_а_интерпритировал 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Изображение поста
Итоги съела собака кошка, по этому...
ДАЙДЖЕСТ 2024 ГОДА Пытался выдавить из себя пост с итогами года, но получается натянуто и вымученно. Но закруглить как-то уходящий год хочется, и со спокойной душой уйти нарезать салатики. По этому давайте вместе вспомним, чего интересного и полезного было на канале в этом году в формате дайджеста. ▶️У МЕНЯ ПОЯВИЛСЯ САЙТ Пока там не так много эксклюзивного контента. Но, как минимум, там можно найти все статьи и выступления в одном месте, а также почитать про мой опыт в формате CV и полистать кейсы. ▶️ ВЫСТУПЛЕНИЯ Хотелось бы, чтобы было их больше. Зато, будет хорошая цель на следующий год 😉 Онлайн мини-вебинар на тему мышления абстракциями при проектирвоание дизайн-систем. Попытался рассказать, как мыслю я, почему важно выходить за рамки ограничений реального мира через абстракции и как это помогает масштабировать дизайн-системы, а ещё показал несколько примеров. То самое выступление на Дизайн-выходных про SDUI платформу, MVP которой мы построили во ВкусВилл. Очень нетривиальное решение сразу и многих проблем интеграции дизайна в разработку, и безрелизных изменений, и даже "собственная Фигма". А ещё было много крутых вопросов от зрителей. ▶️ СТАТЬИ Лонгрид в двух частях о том, что такое наследуемые свойства, зачем я их придумал, и как это помогает в SDUI подходе. Часть 1 и Часть 2 Типографика во ВкусВилл — как я организовал работу с текстом в нашей дизайн-платформе. ▶️ ИНТЕРЕСНЫЕ ПОСТЫ Ответ на важнейший вопрос всего ИТ — сколько стоит перекрасить кнопку Весь мой карьерный путь в дизайне. Кто такой дизайнер дизайн-систем Должен ли дизайнер делать CJM и портреты пользователей? Испытание купоном. Наше задание, которым мы тестировали соискателей в формате witeboard. Серия постов про работу с состояниями компонентов: — Состояние фокус, подходы и варианты реализации Нужно ли отображать все состояния в вариантах?Модели состояний. Как можно упростить работу с состояниями сделать их более консистентными. Пост о тенденции к унификации UI в крупных сервисах, а ещё ВИКТОРИНА: Угадай маркетплейс Почему не нужно продумывать всё детально "на берегу", а просто нужно начать делать. Как выбор имени токена может задержать вас на месяцы. Мои мысли про грейды, и как я выстраиваю грейды и роли в своей команде. Система слоёв при проектировании системы всплывающих окон. Много полезного по дизайн-системам: — Референсная палитра — отдельная группа токенов цвета с перечислением всех уникальных оттенков. — Инструменты генерации палитры — небольшой обзор средств по построению растяжек цветов и мой личный опыт. — Семантическая палитра — слой токенов цвета с семантической привязкой. — Сем. палитра во ВкусВилл — пример семантической палитры текущего мобильного приложения ВВ. — Бывают ли неатомарные ДС — рассуждения на тему "Is atomic design dead" — Атомарность в нашей ДС — почему дизайн-система и платформа у нас это разное, и как выстроена атомарность на уровне ДС. — Что такое SDUI — Краткое описание понятия. — Дизайн-токены — что это, и зачем. — Рецепты компонентов — техника описания основных характеристик групп компонентов. Так всего было много, что всё, кажется не поместится. В прошлом дайджесте за первые пол года можно найти ещё много интересного. 🎄🎄🎄 А я всех поздравляю с наступающим новым годом! 🥳 Всем в новом году взрывного роста, красивого UI, логичного и удобного UX, ну и не забывайте мыслить абстракциями! Ну а я обещаю в новом году попробовать писать посты чаще, чем это получается у меня в этом году... но это не точно😁 - - - - #дизайн #дайджест #итоги2024 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Изображение поста
⚡️АНОНС
Что такое абстракции, и зачем ими мыслить? Как это помогает делать масштабируемые дизайн-системы? Что такое модели состояний и рецепты компонентов? Рассказываю на мини вебинаре в сообществе ❤️ pinkman experience 🗓 Дата: 17 декабря 🔜 Время: 16:00 (мск) 🆓 Участие бесплатное 🔗 РЕГИСТРАЦИЯ ТУТ 🔗 - - - - #вебинар #pinkman #дизайнсистемы #анонс 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru
Изображение поста
Настало время ответить на самый важный вопрос проектирования дизайн-систем — да что там, всего 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
Изображение поста