Когда маленькая задача оказалась вовсе не маленькой
Есть такой вид задач в работе дизайнера, которые сложно назвать сложными по хардам, но вот по софтам они забирают огромное количество сил.
Например, нам нужно заменить логотип на тестовой сборке для демо. Казалось бы, что сложного: разработчику просто нужно взять и заменить логотип на корректный. Но вот здесь всплывает особенность крупных компаний.
Нельзя просто взять логотип “не из коробки” и вставить в макет. Потому что этот логотип не заведён в дизайн-систему в коде. И вот тут начинаются танцы с бубном: как это сделать быстро и правильно?
Логотип не живёт где-то отдельно, он живёт в библиотеке компонентов, и просто любому человеку туда залезть не получится, чтобы быстренько добавить что-то своё. Значит, нужно идти через команду дизайн-системы, чтобы они загрузили нужный мне ассет, обновили библиотеку, и только тогда разработчик сможет вставить его к себе в код.
И вот простая задачка на 2 минуты внезапно превращается в маленький маршрут через процессы, зависимости и соседние команды. И это происходит не из-за того, что кто-то вредничает или не хочет работать. Вы спросите: а почему нельзя сделать такую штуку в обход, всё равно никто же не увидит? Но тут я с вами поспорю.
Если все команды начнут добавлять такие “маленькие штучки” в обход дизайн-системы, сама библиотека компонентов разрастётся до таких нереальных размеров, что дизайнеры начнут в ней путаться. А так есть единая точка правды, которая согласована со всеми. Это помогает не только дизайнерам, но и разработчикам, которые потом эти макеты верстают.
Мне кажется, такие задачи — одни из самых недооценённых в работе дизайнера. Ведь размер задачи не равен количеству работы вокруг неё. И в таких задачах отлично прокачиваются софты: умение договориться, обозначить сроки и обсудить всё со всеми командами. А в работе дизайнера софты так же важны, как и харды.
Не просто красиво ← канал про дизайн, путешествия и рост в компании
Комментарии
Войдите, чтобы оставить комментарий.