На фоне серого каркаса нового сервиса уже начинает возникать множество вопросов о поведении пользователей. Публичные материалы, такие как Тинькофф дизайн, предоставляют возможность лучше понять профессиональную среду. Однако процесс работы продуктового дизайнера начинается не с визуальных элементов, а с глубокого анализа задачи и ограничений.
Первым этапом становится не создание макета, а выявление разрыва между текущим сценарием и желаемым результатом. Пользователь может долго искать нужное действие, неправильно интерпретировать подпись или застрять на этапе заполнения формы. Дизайнеру необходимо выяснить, где именно возникают затруднения, кто испытывает эти проблемы и каким образом можно подтвердить улучшения в результате внесённых изменений. Если сразу сосредоточиться на экранах, то красивая композиция может скрыть логические ошибки.
Поэтому перед тем, как обращаться к графическому редактору, важно проанализировать обращения пользователей, исследовать существующие пути взаимодействия и учесть технические рамки продукта. В некоторых случаях данных может быть недостаточно, и тогда гипотеза останется только гипотезой — с явно обозначенными допущениями, а не с убедительными визуальными доказательствами.
Не всегда требуется внедрение нового элемента для решения проблемы. Порой достаточно убрать лишний шаг или заменить двусмысленное описание. Черновой сценарий демонстрирует последовательность действий без визуальных украшений. На белом фоне располагаются простые блоки, курсор перемещается между состояниями, и обсуждение цветовой палитры откладывается. На этом этапе важно проверить, понимает ли пользователь следующий шаг, видит ли результат действия и может ли вернуться назад после ошибки.
Далее дизайнер объединяет отдельные экраны в прототип и проходит путь так, словно видит его впервые. Эта задача оказывается сложнее, чем кажется, так как автор уже знает расположение каждой кнопки и невольно достраивает недостающие объяснения. В ходе короткой проверки другой человек может задержать курсор над незнакомой иконкой, перечитать заголовок и молча вернуться назад. Именно эта причина определяет необходимость следующих правок: увеличенная кнопка не решит проблему, если пользователь испытывает сомнения в последствиях нажатия.
Интерфейс взаимодействует с кодом, содержанием продукта и правилами конкретного процесса. Разработчик может заметить неэффективное или нестабильное поведение элемента, аналитик уточняет измеримые эффекты, редактор выявляет смысловые разрывы в тексте. Это не последовательная передача макета из рук в руки. Обсуждение проходит в процессе работы, пока изменения ещё не требуют разборки уже собранного экрана.
Во время встречи может возникнуть неловкая тишина: дизайнер демонстрирует плавный сценарий, а инженер открывает схему состояний и указывает на редкие исключения. Связь может потеряться после отправки формы, операция может сохраниться частично, пользователь может вернуться через несколько часов — заранее показанный путь может разрушиться. Однако реальный продукт всегда существует с ограничениями. Дизайнеру приходится вводить промежуточное состояние, объяснять задержку или оставлять доступный способ повторить действие.
Портфолио должно отражать процесс решения задач, а не только готовые экраны. Читателю необходим контекст: какая проблема рассматривалась, какие ограничения влияли на работу, почему был отвергнут один из вариантов и что изменилось после проверки. Если проект нельзя полностью раскрыть, дизайнер может описать свою зону ответственности и механизм выбора без раскрытия закрытых данных. Этого достаточно, чтобы отличить осмысленную работу от набора визуальных упражнений.
Частой проблемой многих кейсов является скачок от задачи к финальному макету. Между ними может остаться пустое пространство, в то время как именно там происходили споры, неудачные попытки и сокращение сценария. Один ранний набросок с зачёркнутой веткой может оказаться полезнее пяти почти идентичных экранов, так как он показывает, какое предположение не выдержало проверки. Здесь не требуется изображать безошибочный процесс. Гораздо важнее обозначить условия, после которых решение изменилось, и отделить личный вклад от результата работы всей команды. Если нет подтверждённых итоговых данных, портфолио не должно подменять их выдуманным ростом показателей.
Хороший кейс читается без экскурсовода, однако он не обязан документировать каждый рабочий день. Следующий шаг обычно невелик: выбрать один сценарий, записать его ограничения и пройти путь от первого действия до ошибки. На столе может лежать блокнот с неровными стрелками, рядом мерцает прототип, а нерешённым остаётся лишь один вопрос — что увидит пользователь, если привычный путь внезапно прервётся.
