или почему опасно знать свой продукт слишком хорошо

Недавно в разговоре с коллегами стало как-то грустно. Многие работают над одними и теми же продуктами по два-три года. Уверенно обсуждают итерации, паттерны, приоритеты, знают систему до болтика. Но в этой уверенности — странная тишина. Как будто внутри всё давно разложено по полочкам, и новые решения больше не требуют усилий.

Параллельно вспоминаю свои собеседования год назад.
Если вакансия была из e-commerce, спрашивали, есть ли у меня опыт в e-commerce. Если из B2B — интересовались, работала ли я с B2B-интерфейсами. Если это CRM — уточняли, сталкивалась ли я с CRM-системами.
Каждый раз — этот логичный вопрос, ибо чем ближе предыдущий опыт, тем быстрее адаптация и выше шанс дать результат.
Но внутри эти вопросы вызывали удивление. Не потому, что мне нечего было ответить. А потому что в них слышался намёк: «ты — дизайнер чего-то». Дизайнер дашбордов. Дизайнер маркетплейсов. Дизайнер финтеха.

Почему это стало цеплять

В самом начале продуктовой карьеры (7 лет назад) гибкость воспринималась как норма — умение адаптироваться, схватывать суть, подстроиться под продукт, которого ты до этого не касался.
Насмотренность, абстрактное мышление, логика — всё развивалось ради одного: не застрять в контексте.
Хотеть мочь всё — было не амбицией, а условием профессиональной устойчивости.

Сейчас это ощущение стало редкостью. Всё чаще в дизайне фиксируются на специализации: по отрасли, по интерфейсу, по модели.
И каждый раз, когда кто-то работает в одном продукте слишком долго, — вижу, как медленно уходит самое важное.
Гибкость — способность не быть заложником одного способа думать.

Что происходит, когда гибкость теряется

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

Как это проявляется:

• Новые паттерны кажутся «чужими» просто потому, что они не из локального UI-кита.

• Архитектура становится непреложной истиной, а не точкой обсужденияс разрабами.

• Пользовательские сценарии интерпретируются исключительно через текущую "работающую" механику.

• Исчезает привычка перепроверять решения — даже те, что давно стали частью системы.

Почему это опасно

Продуктовый дизайнер — не тот, кто хорошо рисует экраны. Это тот, кто умеет видеть.
Замкнутая среда отучает смотреть широко, отучает сомневаться, а без сомнения нет и роста. Остаётся только уверенность в собственных паттернах и растущая неспособность адаптироваться.

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

Как сохранить гибкость — практичные подходы

1. Менять продукты и команды не «потому что надоело», а как профилактику

Я редко работаю в одной команде больше 1.5–2 лет. Не из-за нетерпения — а чтобы не застревать в собственных решениях.
Через два года начинает тошнить от фирменного цвета, от идеального грид-системного выравнивания, от того, что знаешь ответы быстрее, чем кто-либо успевает задать вопрос.
Смена продукта — способ выйти из сценария, в котором ты стал слишком эффективным.

2. Тренировать мышление вне контекста

Гибкость — это не про разнообразие интерфейсов, это про способность не думать одинаково.
Для этого полезны упражнения, которые не привязаны к задачам. Например:

• сделать макет для несуществующего сервиса;

• спроектировать опыт не для пользователя, а, скажем, для техподдержки или AI-системы;

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

Не для дриббла, не для портфолио. А чтобы вспомнить, как выглядит мышление без привычного каркаса.

3. Менять угол зрения внутри задачи

Даже если нет возможности уйти из продукта, можно разворачивать задачи.
Например:

• посмотреть на свой интерфейс глазами юриста, который его согласует;

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

• собрать ту же механику, но без визуальных паттернов, к которым привыкли.

Чтобы дизайн снова потребовал усилий.

4. Добавлять шум в систему

Любая зрелая команда неизбежно выстраивает устойчивые сценарии. Это делает её предсказуемой и одновременно ригидной.
Полезно намеренно нарушать ровность:

• предложить абсурдный, но честный вариант решения;

• пересобрать знакомый сценарий, игнорируя текущую архитектуру;

• взять проблему, которую никто не решал, и довести её до абстрактного прототипа.

Даже если результат не пойдёт в продакшн — это встряхивает мозг и команду.

5. Работать с чужими задачами, не забирая их

Иногда гибкость развивается не через решение, а через слушание.
Войти в обсуждение, где дизайнер вообще не нужен — но попробовать понять структуру.
Послушать, как аналитик объясняет ограничения. Задать уточняющие вопросы юристу. Сопоставить pain-поинты клиента и KPI партнёрского отдела.

Это не про эмпатию. Это про повторную сборку картины мира.

6. Осознанно обновлять логическую насмотренность

Смотреть не на UI — а на подход.
Как в медицине упрощают ввод данных под стрессом? Как в играх проектируют onboarding? Как в государственных сервисах строят маршруты для людей с минимальной цифровой грамотностью?
В каждой сфере есть логика. Если её перенести в свой продукт, не копируя форму, — можно найти неочевидное решение.

Финал

Гибкость — это не soft skill и не роскошь. Это база.
Когда дизайнер утрачивает гибкость, он перестаёт быть дизайнером. Он становится техподдержкой собственных решений.

И чем больше внутри устойчивости, тем чаще стоит проверять: не исчезло ли ощущение сопротивления.
Если работа перестала требовать усилия — возможно, усилие теперь требуется не задаче, а самому взгляду.