Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

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

Немного обо мне. Меня зовут Лена Плинер. Я проектирую интерфейсы для сложных продуктов: CRM, ERP, SaaS‑платформ и сервисов, веб‑ и мобильных приложений. Занимаюсь дизайном больше 15-ти лет, с 2009 года работаю как попроектный дизайнер.

В этой небольшой статье я хочу рассказать:

• почему я не отправляю макеты вслепую;

• почему перед созвоном всегда запрашиваю информацию о проекте;

• о чем говорю и что показываю на созвоне знакомства.

— Дайте ссылку на Figma!
— А поговорить?

В портфолио у меня сотни проектов. Сотни макетов, ссылок на Figma, различных тематик, задач, решений. Только визуальная часть редко даёт представление о масштабе проделанной работы.

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

Поэтому, когда ссылку на проект в Figma просят потенциальные клиенты, я предлагаю короткий созвон знакомства, где могу рассказать о похожих кейсах, задать уточняющие вопросы, продемонстрировать свое мышление ^[1].

Легкий, быстрый, комфортный разговор

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

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

Примеры описаний

Система управления проектами (Project Tracker)
«Пишем свой таск-менеджер. Хотим сделать что-то вроде ClickUp, но проще. Надо продумать UX, роли, доступы. Какие у нас будут сценарии: создание задачи, настройка этапов, трекер времени, уведомления, отчёты. Есть собственное API, будет интеграция с мессенджерами. Команда 6 человек, сроки жёсткие.

Кабинет поставщика для маркетплейса
«Поставщики загружают товары, следят за заказами, статистикой, остатками. Нужно проработать кабинет и адаптивку. У поставщика должен быть доступ к личной аналитике, скидкам, акциям, массовой загрузке. Часто работают с мобильного, поэтому важен UX на смартфонах»

Этого минимума мне достаточно, чтобы подготовить релевантные запросы. Спецификации, ТЗ, тонны документации на данной стадии мне не нужны.

Что происходит на созвоне?

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

Примеры интерфейсов с заявками из разных продуктов
Показываю их, если в запросе есть похожий сценарий

На рассказ о том, что было важно в этом проекте, уходит не более 7 минут. Самое главное — знать, о чём рассказать. Именно для этого мне нужны вводные о проекте, над которым предстоит работать. 

Начинаю с формулировки задачи: «Правильно ли я понимаю, что вам нужно…», и прошу подтвердить. После этого показываю кейс и поясняю:

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

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

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

• какие ограничения возникали и как мы находили рабочие решения;

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

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

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

В конце обсуждаем открытые вопросы.

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

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

Почему я решила написать эту статью?

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

Речь не о том, чтобы просто посмотреть на стилистику, для этого есть портфолио. И не о порядке в Figma, это можно продемонстрировать на другой стадии переговоров.

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

Если вам понравилась моя статья, приглашаю подписаться на мой телеграм-канал: Дизайнер на всю голову ^[2], где я пишу я рассказываю о своих проектах, подходе к работе и о том, что мне интересно