Поиск решений для своих задач

В этой заметке я хочу рассказать, как ищу решения для продуктовых задач. Это не про «вдохновение» и красивые кейсы. Это про понятный и рабочий путь, который помогает не изобретать велосипед.

У меня есть три опоры:

1. Дизайн-системы
2. Личное исследование продуктов
3. Работа с самой задачей и людьми

Дизайн-системы

Дизайн-системы – это не просто набор кнопок и компонентов. Это зафиксированные решения реальных продуктовых проблем. Через них удобно учиться продуктовому дизайну и логике интерфейсов.

Лучше всего они усваиваются не через чтение, а через практику. Берёте любой свой проект и пробуете спроектировать интерфейс, опираясь на конкретную дизайн-систему. Так быстрее понимаешь её сильные и слабые стороны.

Material Design by GoogleОдна из самых популярных дизайн-систем, но при этом мало кто действительно понимает, когда и зачем её использовать.

Лучший способ разобраться – взять реальный проект и начать использовать компоненты и принципы Material Design.

Human Interface Guidelines by AppleApple подаёт информацию очень структурировано и понятно. В гайдах хорошо описаны базовые UX-сценарии: аутентификация, поиск, работа с файлами и системные состояния.

Отдельно ценно, что они объясняют почему принимаются те или иные решения. Например, в разделе про тёмную тему есть не только визуальные правила, но и логика – зачем она нужна пользователю и как правильно её использовать.

Carbon Design System by IBMСильная открытая дизайн-система с большим фокусом на доступность.

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

В системе много практических рекомендаций:

• на что обращать внимание дизайнеру;
• как проектировать доступные интерфейсы;
• гайды по сетке, отступам и компонентам.

Упомяну ещё дизайн-системы: Atlassian, Fluent, Pajamas, Primer. Российская дизайн-система, которая хорошо задокументирована, лично мне она очень нравится, отдельный респект дизайнерам, которые это делали – Контур.Гайды. Они все есть в открытом доступе для изучения документации, так и в Figma (Не уверен, что есть Контур).

Личное исследование продуктов

Второй важный источник решений – это личный опыт использования продуктов.

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

Для поиска новых продуктов часто использую ProductHunt. Там можно:

• зарегистрироваться;
• попасть на бета;
• попробовать демо;
• посмотреть, как реализованы интерфейсы и механики.

В процессе я обращаю внимание на удачные и неудачные решения. Что-то запоминаю, что-то записываю – тут каждый выбирает удобный для себя способ.

Дополнительно помогают дизайнерские Telegram-каналы. Они регулярно делятся новыми сервисами и расширяют насмотренность. Например: Timestripe, MakeSpace, Roam Research, Spline, Linear, OpenPhone.

Если я ищу конкретное решение, исследование может занять больше времени – приходится анализировать продукты точечно.

Короткий кейс

Мне нужно было спроектировать быстрый фильтр из трёх выпадающих списков с множественным выбором чекбоксов.

Сразу возникли вопросы:

• как пользователь сбрасывает весь фильтр ?
• можно ли сбросить только часть?
• как пользователь настраивает несколько фильтров?

Я начал с анализа продуктов, где есть похожие сценарии: ClickUp, Trello, Jira, Notion. Собрав нужные паттерны, спроектировал решение и протестировал его. Я получили положительный фидбек.

Работа с задачей

Третья опора – это работа с самой задачей и людьми, которые в ней участвуют.

Понимание задачи

Если задача большая, я стараюсь начать с встречи: с разработчиками и product owner.Важно проговорить:

• алгоритм работы;
• ограничения (технические, ресурсные, бизнесовые);
• спорные моменты.

Переписка для этого подходит хуже – слишком легко неправильно интерпретировать смысл. Но ключевые тезисы я всегда фиксирую.

Формулировка задачи

Задача должна быть сформулирована так, чтобы сразу было понятно:

• для кого мы проектируем;
• чего хочет пользователь;
• какой результат ожидаем.

Здесь хорошо работает простая структура:

• Я, как…
• Хочу…
• Чтобы…

Пример: Я, как пользователь продукта, Хочу поиск, Чтобы получить нужные данные.

Это помогает убрать лишнее и сфокусироваться на сути.

Поиск решений

Перед началом проектирования я смотрю на решения конкурентов и отвечаю себе на вопросы:

• в чём плюсы этого решения?
• почему они сделали именно так?
• как этот паттерн можно применить в моей задаче?

Собрав референсы, я проектирую очевидный сценарий – без креатива и трендов.Сначала важно решить проблему пользователя проверенными инструментами.

По опыту, лучше быстро показать рабочий сценарий и согласовать его с product owner, чем долго делать «красиво» и не получить «ок».

Проверка и доработка

Дальше я субъективно тестирую решение и ищу:

• где можно упростить;
• что сделать понятнее;
• как сократить количество действий пользователя.

После этого – финальная доработка и исследование на целевой аудитории, где собирается фидбек.