Taskee: из набора экранов в дизайн-систему, не останавливая разработку
Taskee вырос из внутреннего инструмента студии Toimi в отдельный SaaS для задач и проектов. Визуальная концепция и UI-kit уже существовали, но экраны держались на группах слоёв, а не на компонентах. Я пересобрала интерфейс в компонентную систему на 5 брейкпоинтах параллельно с живой разработкой.
Роль
UX/UI-дизайнер: дизайн-система, веб- и мобильные интерфейсы, участие в приоритизации фич
20+атрибутов фильтрации на переиспользуемых компонентах
18таск-трекеров в сравнительном анализе
01
Кратко о проекте
Taskee — SaaS для управления задачами и проектами. Он вырос из внутреннего инструмента студии Toimi в отдельный продукт и в марте 2025 года вышел на Product Hunt.
Когда я подключилась, визуальная концепция и UI-kit уже существовали, команда успела наработать узнаваемый стиль. Но под этим слоем не было структуры: экраны собирались из групп слоёв, а не из компонентов, и по сути были копиями друг друга.
Пользователи продукта
Команды, которые ведут задачи и проекты в вебе и с телефона.
Команда продукта
Дизайнеры и разработчики, для которых система стала общим языком: как ведёт себя каждый элемент и в каких состояниях.
02
Задача, ограничения и роль
Задача
Понять, почему визуально готовый продукт создаёт разработчикам столько проблем, и пересобрать его в систему, которая убирает причину расхождений между макетами.
Ограничения
Разработку нельзя было останавливать: продукт параллельно выпускал фичи
Ресурсы студии ограничены, приоритеты менялись
Визуальный стиль уже сложился, менять его не требовалось
Моя роль
Отвечала за дизайн-систему и веб- и мобильные интерфейсы, участвовала в приоритизации фич. Визуальную концепцию и UI-kit до меня создала команда, на мне была структурная пересборка.
03
Исследование и исходные данные
Аудит Figma
Сколько экранов реально дублируют логику, какие компоненты повторяются чаще всего, где состояния задокументированы, а где их додумывают на глаз.
Анализ 18 таск-трекеров
Вместе с командой разобрали ClickUp, Wrike, Asana, Notion, Monday, Jira, Trello и другие, чтобы понять нужный продукту уровень системности.
Обратная связь разработки
Разработчики получали макеты, которые противоречили друг другу. Каждое изменение приходилось вручную вносить в десяти местах.
Что выяснилось
Нет договорённости о поведении элементов
Дизайн и разработка не договорились, как ведёт себя каждый элемент. Без этого любое визуальное решение одноразовое.
«Такой же» компонент вёл себя по-разному
Физически это были разные слои, а не один компонент с вариантами.
Продукт открывают на разных экранах
Макеты существовали в одном брейкпоинте, и на промежуточных размерах вёрстка ломалась.
04
Процесс и ключевые решения
Решение 1
Компонентная архитектура с явными состояниями
Проблема
Один и тот же на вид компонент вёл себя по-разному на разных экранах, и разработчики додумывали поведение по ходу.
Решение
Пересобрала интерфейс в компоненты на автолэйаутах с вариантами. Каждое состояние (hover, disabled, error, loading) прописано явно.
Почему так
Забыть состояние становится невозможно: оно либо есть в компоненте, либо экран не собрать.
Поля ввода: семь состояний от default до disabled, светлая и тёмная тема
Теги: состояния и редактирование для двух размеров и двух тем
Решение 2
Адаптивность на уровне компонентов
Проблема
Продукт открывали с десктопа, планшета и телефона, а макеты были в одном размере.
Решение
Адаптивные макеты на 5 брейкпоинтов (1920, 1536, 1366, 768, 375) сразу на уровне компонентов, а не отдельным слоем поверх готового дизайна.
Почему так
Если адаптив живёт в компоненте, каждый новый экран получает его автоматически.
«Мои задачи» на 1920, 1366, 768 и 375: на мобильном таблица перестраивается в карточки
Решение 3
Система не останавливает разработку
Проблема
Пересборка шла поверх живого продукта, который параллельно выпускал фичи: фильтрацию на 20+ атрибутов, редизайн проектной доски с zoom-режимом, отчёты с тепловой картой загрузки сотрудников.
Решение
Правило: каждая новая фича сразу собирается из компонентов системы.
Итог
Технический долг не переехал из старых экранов в новые. Без этого правила вся пересборка могла обнулиться за один спринт.
Решение 4
Отказ от фичи до кода
Проблема
При редизайне канбан-доски обсуждали группировку по тегам. Она казалась логичным продолжением фильтрации.
Решение
На обсуждении с PM и разработчиком до старта разработки увидели, что задачи с несколькими тегами дублировались бы по колонкам и ломали drag-and-drop. От группировки отказались.
Почему так
Ошибку в логике взаимодействия дешевле поймать на обсуждении, чем в живой системе.
Итог
Группировку оставили по проекту, по приоритету или без группы. По тегам её делать не стали.
Группировка задач в итоге осталась по проекту, по приоритету или без группы
05
Финальное решение
Одна система компонентов обслуживает светлую и тёмную тему, пять размеров экрана и новые разделы, которые появлялись по ходу работы: отчёты, трекинг времени, комментарии.
Страница задачи на десктопе, планшете и телефоне
Страница задачи в тёмной теме: статусы, теги, таймер, чек-лист и файлы
Отчёты по времени сотрудников с индикатором загрузки
06
Результат
Обратная связь и итог
Разработчики перестали получать противоречащие друг другу макеты: компонент ведёт себя предсказуемо на любом экране
Новые экраны собираются из готовой библиотеки, а не вручную каждый раз
Хендофф стал чище: описания на компонентах и экранах, анимированные прототипы сняли часть вопросов заранее
Ограничения оценки
Метрики на уровне дизайн-системы отдельно не отслеживались, поэтому эффект описан качественно
После запуска на Product Hunt в марте 2025 года в продукте зарегистрировалось 600+ компаний. Это контекст роста продукта, а не прямой результат дизайн-системы
07
Выводы
Из Taskee я вынесла, что разговор с разработкой находит больше проблем, чем ещё один раунд дизайн-ревью в одиночку. Когда мы обсуждали системные решения с разработчиками до передачи в работу, как с канбаном, структурные проблемы всплывали раньше, чем становились дорогими.
Что сделала бы иначе. Закладывала бы токены и переменные сразу при первой пересборке компонентов, а не отдельным этапом позже. Тогда масштабирование на 5 брейкпоинтов потребовало бы меньше ручной синхронизации задним числом. Я увидела это только в середине процесса.
Написать в Телеграм