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