Как оптика новичка помогает исправлять логические ошибки, UX-изломы продукта и как превратить отсутствие контекста в индикатор реальности.

Джунов по умолчанию принято считать своеобразной «точкой просадки» в любой команде. Они создают дополнительную нагрузку на сеньоров, могут «тормозить» общую скорость процессов и требуют дополнительной концентрации от всех остальных.

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

Меня зовут Василиса, я UX-дизайнер в компании KODE. Расскажу, как отсутствие опыта и погружение в контекст ранее незнакомого продукта может дать команде новую оптику.

Когда я пришла в продуктовую команду дизайнером,думала, что первое время буду просто учиться инструментам, адаптироваться и разбираться в процессе. Быстро стало понятно: мой главный вклад на старте заключался в том, что у меня нет контекста (первые шаги джуниор-специалиста в дизайне, начинаются со знакомства с продуктом). Опыт восприятия – это буквально опыт юзера, я вижу продукт точно так же, как обычный пользователь.

В результате, я помогла команде устранить десятки небольших, но критичных UX-неровностей. Опытные члены команды уже не не обращали на них внимания. 

Первый контакт с продуктом — это тоже самое, что и пользовательский опыт

В первые дни я открывала интерфейсы и кликала просто, чтобы понять, как все работает. Уже на начальных этапах взаимодействия с продуктом появились моменты, которые меня сбивали.

Когда ты новичок, ты не пытаешься оправдать интерфейс — ты просто замечаешь логические дыры

Следующий кейс касался панели модерации, с помощью которой проверялись учебные материалы. Сверху две кнопки: «Модерировать» и «Редактировать». Ниже — длинный список критериев с элементами интерфейса для модерации. Эти элементы были доступны даже, когда пользователь еще не вошел в режим правки.

На лицо была логическая ошибка. Команда много месяцев работала с этим экраном и считала, что так и должно быть. Им был знаком этот паттерн, они привыкли к нему и перестали задавать вопросы.

Я пришла с вопросом: «Почему редактирование доступно до начала модерации?». И снова оказалось, что к этому просто привыкли. Мы переписали поведение: чекбоксы блокировались до клика «Модерировать», появилась отзывчивость интерфейса. Проблема исчезла просто потому, что её наконец-то увидели.

Даже «мелкая» проблема может быть самой заметной для юзера

Был и третий кейс — списки содержания учебников. Они представлял собой веб-страницу с содержанием: главы, параграфы, вложенные пункты.
У каждого пункта было два элемента: текст — название параграфа и маленькая иконка-шеврон справа — индикатор, что пункт можно раскрыть. Но кликабельной была только часть этой иконки. Текст пункта не реагировал на клик вообще. 

Получался классический UX-излом: визуально вся строка выглядела как единый интерактивный элемент, но активный элемент – только маленький треугольник справа. 80-90 % всей строки - «мертвая зона». 

Для пользователя ситуация выглядела примерно так: «нажимаю — и ничего не происходит». Юзер делает вывод: «Функция не работает». На самом деле всё работало, но только если попасть в шеврон размером примерно 16×16 px. Те, кто долго работал с продуктом, уже знали, что нужно кликать по шеврону. У них рука автоматически попадала туда. Поэтому проблему никто не фиксировал. Речь же шла о базовом нарушении принципа веб-паттернов: если элемент выглядит как один блок — он должен быть кликабельным целиком. Пользователь не должен прицеливаться, не должен угадывать, где активная зона.

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

Блок переписали так, как должно быть: кликабельной стала вся строка. 

Привычка может стать точкой, где продукт перестает расти

Через пару недель я уже сама начала привыкать к интерфейсу. Отдельные шероховатости переставали бросаться в глаза. Только тогда стало понятно, насколько значимым период, когда был доступен взгляд на проект без контекста.

Если команда долго работает с продуктом, появляется эффект «зашоренности»: теряются логические изломы, UX-шероховатости, а они путают пользователя и усложняют взаимодействие с продуктом. Разработчики знают паттерны, помнят историю решений, автоматически обходят проблемные места. Это нормально. Но это и есть точка, где продукт качественно перестает расти.

Чтобы не потерять взгляд со стороны, необходимо встраивать новые практики в работу команды. 

1. Систематически использовать новичков как тестировщиков реальности

Это не «нагрузка на джуна».Это использование исключительного ресурса, который бывает только раз.

Пока джун не знает контекст:

• он видит интерфейс как пользователь;

• задает неудобные вопросы;

• спотыкается там, где команда перестала спотыкаться;

• вскрывает UX-ошибки, которые годами жили в продукте.

Но со временем этот ресурс будет исчерпан. 

2. Превращать вопросы новичков в гипотезы — а не в объяснения

Частая ошибка — «объяснить логику».
Но если интерфейс нуждается в объяснении, это уже нерабочий интерфейс.

Правильная практика:

• Вопросы от джуна на логику – считать сигналом;

• задавать себе вопрос: «если новичок не понял, почему должен понять пользователь?».

Что сработало у нас

1. Я смотрела на проект как пользователь

Каждый раз фиксировала, где путалась, где ожидала другого поведения интерфейса, где не хватало обратной связи . Заметки превращались в гипотезы или улучшения.

2. Мои вопросы обсуждали как потенциальные UX-дыры

Не «джун не понял», а «возможно, пользователю тоже будет непонятно».
Такой подход сразу меняет тон разговора.

3. Мы начали делать парные ревью макетов

Созвоны с лидом, где мы вместе разбираем сложные экраны, давали эффект, который невозможно получить перепиской. Он объяснял контекст, я объясняла, что вижу в контексте нового взгляда на продукт, какое решение могу предложить как дизайнер. В этом диалоге постоянно находились решения для новых улучшений.

4. Команда фиксировала фидбек онбординга

Каждый вопрос, который я задавала в процессе, попадал в документ. Так мы расширяли понимание того, как продукт видят новички — и что можно улучшить системно.

Не стоит недооценивать вопросы джуна

Парадокс в том, что самые правильные вопросы часто кажутся самыми простыми. Но именно они вскрывают моменты, где продукт уже потерял интуитивность или логичность.

Я несколько раз видела, как мои вопросы запускали обсуждения, важные для всей команды. Иногда это были микроисправления. Иногда — переработки целых флоу..

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