В принципе, в меме всё честно. Но я всё же решила объяснить, почему не кидаю ссылку на Figma по первому запросу.
Немного обо мне. Меня зовут Лена Плинер. Я проектирую интерфейсы для сложных продуктов: CRM, ERP, SaaS‑платформ и сервисов, веб‑ и мобильных приложений. Занимаюсь дизайном больше 15-ти лет, с 2009 года работаю как попроектный дизайнер.
В этой небольшой статье я хочу рассказать:
почему я не отправляю макеты вслепую;
почему перед созвоном всегда запрашиваю информацию о проекте;
о чем говорю и что показываю на созвоне знакомства.
— Дайте ссылку на Figma!
— А поговорить?
В портфолио у меня сотни проектов. Сотни макетов, ссылок на Figma, различных тематик, задач, решений. Только визуальная часть редко даёт представление о масштабе проделанной работы.
Чтобы понять, как и какие принимались решения, почему сценарии выстроены именно так и какие задачи стояли за интерфейсом, нужно погрузить клиента в контекст. Без погружения в контекст сложно оценить подход к проектированию и опыту дизайнера.
Поэтому, когда ссылку на проект в Figma просят потенциальные клиенты, я предлагаю короткий созвон знакомства, где могу рассказать о похожих кейсах, задать уточняющие вопросы, продемонстрировать свое мышление.
Легкий, быстрый, комфортный разговор
Чтобы разговор был осмысленным, перед встречей я всегда прошу описать проект, обозначить цели и задачи для дизайна. Это обязательно условие созвона.
Если этих вводных нет, а запрос звучит как «покажите что-нибудь в фигме», я отказываюсь. Провести предметный разговор о проекте не получится: я не смогу подобрать релевантные кейсы, задать точные вопросы, показать как мой опыт соотносится с задачей.
Примеры описаний
Система управления проектами (Project Tracker)
«Пишем свой таск-менеджер. Хотим сделать что-то вроде ClickUp, но проще. Надо продумать UX, роли, доступы. Какие у нас будут сценарии: создание задачи, настройка этапов, трекер времени, уведомления, отчёты. Есть собственное API, будет интеграция с мессенджерами. Команда 6 человек, сроки жёсткие.
Кабинет поставщика для маркетплейса
«Поставщики загружают товары, следят за заказами, статистикой, остатками. Нужно проработать кабинет и адаптивку. У поставщика должен быть доступ к личной аналитике, скидкам, акциям, массовой загрузке. Часто работают с мобильного, поэтому важен UX на смартфонах»
Этого минимума мне достаточно, чтобы подготовить релевантные запросы. Спецификации, ТЗ, тонны документации на данной стадии мне не нужны.
Что происходит на созвоне?
Когда есть понимание запроса, я подбираю соответствующие проекты. Обычно показываю 2 кейса, релевантных задаче собеседника. С учетом сложности проектов этого более чем достаточно.
Примеры интерфейсов с заявками из разных продуктов
Показываю их, если в запросе есть похожий сценарий
На рассказ о том, что было важно в этом проекте, уходит не более 7 минут. Самое главное — знать, о чём рассказать. Именно для этого мне нужны вводные о проекте, над которым предстоит работать.
Начинаю с формулировки задачи: «Правильно ли я понимаю, что вам нужно…», и прошу подтвердить. После этого показываю кейс и поясняю:
в каком контексте возник проект, чтобы показать связь интерфейса и бизнес-задач;
какие функции и сценарии были ключевыми, чтобы обозначить масштаб и глубину решения;
как выстраивался процесс, чтобы дать представление о формате взаимодействия;
какие ограничения возникали и как мы находили рабочие решения;
какие выводы и неожиданные находки появились в процессе, то, что не видно в макетах, но влияет на результат.
Это не монолог. Мне важно вовлечь потенциального заказчика в диалог, чтобы узнать больше конкретных деталей о проекте. Через вопросы я показываю, что проект мне интересен и что у меня уже есть опыт со схожими задачами.
Я внимательно слежу за тем, как человек отвечает, насколько подробно он готов делиться информацией. Это даёт мне понимание, как может выстроиться сотрудничество, насколько мы совпадаем в стиле общения, как лучше взаимодействовать в процессе работы и на каком языке говорить в прямом и в профессиональном смысле.
В конце обсуждаем открытые вопросы.
Такой формат помогает мне не только показать релевантный опыт, но и быстрее определить, какие решения можно применить, а какие не подойдут в текущем контексте. Клиенты после такого разговора лучше формулируют запрос.
Для меня переговоры это способ понять, можем ли мы быть полезны друг другу и насколько наши подходы совпадают, насколько мои решения были привязаны к задачам бизнеса.
Почему я решила написать эту статью?
Тема может показаться простой, но запросы на ссылки без описания проекта повторяются регулярно. Это говорит о том, что значение предварительного контекста всё ещё недооценивается.
Речь не о том, чтобы просто посмотреть на стилистику, для этого есть портфолио. И не о порядке в Figma, это можно продемонстрировать на другой стадии переговоров.
Скорее, дело в том, что описание задачи и даже короткий созвон воспринимаются как нечто трудоёмкое. Хотя на практике это один из самых простых и эффективных шагов, ускоряющих понимание задачи и выбор исполнителя.
Если вам понравилась моя статья, приглашаю подписаться на мой телеграм-канал: Дизайнер на всю голову, где я пишу я рассказываю о своих проектах, подходе к работе и о том, что мне интересно
Комментарии (25)
nihil-pro
03.08.2025 10:20Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma
Потому, что это не поможет. Сложные интерфейсы возникают потому что разработчикам нравится их создавать, а заказчики не знают других способов решения задачи. В результате получаются такие интерфейсы, как на скринах в статье — пульт управления космическим кораблем.
Все эти «сложные интерфейсы» не более чем пародия на эксель, а зачем он пользователю? Дайте ему уже сформированные отчеты/почитанные результаты, а не калькулятор. Тогда выяснится, что интерфейс может быть простой.
epliner Автор
03.08.2025 10:20Спасибо за комментарий. Если интерфейс похож на «пульт управления космическим кораблём», значит, задачи действительно сложнее стандартного отчёта или формулы в Excel :)
Интерфейс продукта это инструмент для работы с бизнес‑процессами: он учитывает роли пользователей, их задачи, права, интеграции, историю изменений, сценарии взаимодействия между отделами.
Таблица в интерфейсе всего лишь способ наглядно структурировать данные, а не аналог Excel по сути.В моей практике были запросы, когда компании начинали с Excel, но по мере роста данных, числа одновременных пользователей, требований к правам доступа и необходимости автоматизировать связанные бизнес-процессы таблицы переставали справляться, и возникала потребность в разработке собственного интерфейса.
Если опыт вашего бизнеса или продукты позволяют обходиться без сложных интерфейсов и сценариев это отлично, но в большинстве B2B и корпоративных проектов интерфейс это результат компромисса между сложностью процессов и удобством пользователей.
nihil-pro
03.08.2025 10:20Если интерфейс похож на «пульт управления космическим кораблём», значит, задачи действительно сложнее стандартного отчёта или формулы в Excel
Вы эти клише заказчикам оставьте.
Если опыт вашего бизнеса...
...но в большинстве B2B и корпоративных проектовКак изящно вы завуалировали то, что на самом деле хотели сказать. Что-то вроде – «Да ты просто над сложными проектами не работал!».
epliner Автор
03.08.2025 10:20Если вдруг доведётся работать вместе над каким-нибудь сложным проектом, то появится еще одна возможность оценить изящество моих мыслей и опыта :)
epliner Автор
03.08.2025 10:20К слову, у меня не было задачи вас обидеть или каким-либо образом попытаться принизить ваш опыт. Надеюсь, вы это понимаете )
artptr86
03.08.2025 10:20А такие интерфейсы можно сделать простыми?
Скрытый текст
epliner Автор
03.08.2025 10:20Возможно, что-то можно упростить, возможно и нет. Любой ответ на подобный вопрос был бы не корректен без 1) понимания что за функционал 2) понимания для кого работает 3) без погружения в процессы взаимодействия. Любой специализированный интерфейс будет казаться непонятным без ответов на эти вопросы )
nihil-pro
03.08.2025 10:20Да.
Было 
Стало artptr86
03.08.2025 10:20А вот там на панелях бортового компьютера проще стало?
nihil-pro
03.08.2025 10:20Разумеется. Как раз благодаря этому, всяких кнопок/рычагов стало меньше. Нужно также иметь ввиду, что сами самолеты стали гораздо сложнее, вместо условного датчика давления масла, они теперь анализируют чуть ли не химический состав воздушного потока. То есть, при том, что сами самолеты стали сложнее, приборная панель упростилась.
nin-jin
Раз вы так любите созвоны, то жду от вас голосовую, где объясняете, что это всё не баги, а фичи.
epliner Автор
Спасибо за комментарий. Вы отлично иллюстрируете основную мысль статьи: оценивать макеты без контекста задач и ролей пользователей, значит, не видеть половины картины :) Именно поэтому я не отправляю ссылку на Figma без созвона с потенциальным клиентом. В интерфейсах, где участвуют десятки сотрудников с разными правами доступа, интеграциями и сценариями, дизайн не может быть «универсально очевидным» без пояснений.
В продуктах, которые я проектирую, созвоны это способ согласовать видение между бизнесом, разработкой и пользователями. И это рабочий инструмент, а не проявление «любви к разговору».)
Конструктивная критика всегда приветствуется, но в отрыве от сценариев и ограничений это скорее догадки. Вы так старались, поэтому я всё-таки отвечу на некоторые комментарии на скриншотах :)
Шапка — это универсальный компонент, который используется на всех экранах системы. В зависимости от контекста, она может содержать дополнительные элементы, включая более длинные заголовки и управляющие кнопки. Поэтому фиксировать фильтры в этой области — неустойчивое решение, так как их расположение будет зависеть от длины заголовка экрана и наличия других элементов.
Более того, с точки зрения UX-паттернов, фильтры и поиск являются неразделимыми инструментами управления списком. Разносить их по иерархии это плохая практика, так как это снижает связанность элементов управления и усложняет взаимодействие. Поиск и фильтры должны быть визуально и логически объединены в одной зоне.
В текущем интерфейсе я намеренно показываю инициалы, так как в компании, для которой разрабатывается система, небольшое количество сотрудников. Вероятность повторения ФИО минимальна . Но даже если такое совпадение произойдёт, например, два «Иванова Алексея Владимировича», отображение полного имени проблему не решит. Оно лишь увеличит ширину колонки, что приведёт к перегрузке таблицы.
К тому же ширина колонок настраивается пользователем и если он её сузит, даже полное имя будет обрезано. Именно поэтому предусмотрена система tooltip'ов: при наведении на имя всегда отображаются полные данные, независимо от того, видны они полностью в ячейке или нет.
Колонка «КП» отображает коммерческие предложения, и их может быть несколько в рамках одной заявки. На практике это обычно 2–3, но в системе нет жёсткого ограничения на количество. В самой ячейке отображается последнее (актуальное) предложение, чтобы не перегружать таблицу.
Задача не стоит в том, чтобы сразу узнать, какое из них от конкретной даты (например, 30.11.2024). В этом нет смысла на уровне списка. Основная задача интерфейса — показать, что в заявке есть несколько КП. Именно для этого рядом с последним КП указывается счётчик («+1», «+2» и т.д.), при клике на который открывается выпадающий список с подробной информацией по всем коммерческим предложениям.
Таким образом, сохраняется компактность таблицы и в то же время обеспечивается доступ к деталям.
Здесь отображаются два разных показателя, относящихся к разным функциям:
"Всего записей: 1000" — это общее количество строк в таблице до применения фильтров. То есть сколько всего заявок попадает в текущую выборку.
"Кол-во записей: 10" — это настройка пользователя: сколько записей показывать на одной странице (пагинация). Это число может быть, например, 10, 25, 50 и т.д.
Например, если пользователь установил отображение по 10 записей на страницу, а отфильтрованные данные дают всего 3 строки, то он увидит только 3 строки, но настройка останется «10». А общее количество внизу при этом покажет «3».
Эти два поля не противоречат друг другу и не дублируют информацию. Они показывают разные аспекты работы с таблицей.
Ответила на вопросы на одном скриншоте. Так же могу аргументировать и второй, но не вижу смысла )
nin-jin
В эту область стоит перенести кнопку создания заявки и возможно поисковое поле, а фильтры лучше растянуть на всю ширину с переносом на новую строку при нехватке места. И уж точно не центрировать. Даже Эпл отказался уже от этой глупой идеи с центрированием.
А вы клиента уведомили, что с вашим дизайном компания никогда не вырастет и не наймёт новых сотрудников?
А клиент в курсе, что он не может полноценно пользоваться интерфейсом на планшете без его перепроектирования?
Вот и подумайте, что эту проблему решит. Вариантов масса: индивидуальные цвета, аватары, фотки. Вам деньги платят не за то, чтобы вы весёлые картинки с Lorem Ipsum рисовали, а за то, чтобы вы подумали обо всех проблемах и решили их.
Актуальных КП может быть несколько. Не актуальные в этой таблице скорее всего вообще не надо показывать. Так что их все надо не просто показывать, но и делать семантически различимыми, а не просто идентификатор выводить с датой.
Я знаю что такое пагинация. Если вы не поняли намёк, то у вас тут беда с текстами, которой нет на втором скрине. Впрочем, в современных интерфейсах используют гораздо более простой в использовании виртуальный скроллинг и не напрягают пользователя переходами по страницам.
epliner Автор
Цитирование цитирований может длиться бесконечно ) Я ценю ваш системный подход, но обсуждение интерфейса вне контекста задачи это всегда работа с предположениями. В своих проектах я разбираю десятки таких гипотез, когда это действительно нужно. В данном случае у меня нет задачи вести глубокий разбор решений, так как статья о другом.
Я ответила на часть комментариев, чтобы показать контекст. Вы предлагаете решения с уверенностью, и я всегда «за» аргументированную уверенность, когда она возникает в процессе командной работы, где есть заказчик, разработчики, дизайнер, бизнес требования, нюансы.
Спасибо за вовлечённость. Думаю, если бы вы были частью команды, многие вопросы отпали бы сами собой )
dom1n1k
Это называется докопаться до столба. Компания же берет только однофамильцев. YAGNI.
Пагинация и виртуальный скроллинг - это 2 разных и не взаимозаменяемых паттерна, которые применяется в разных ситуациях. Кстати, это неплохой вопрос для собеса.
nin-jin
- Вы идеально нам подходите, но мы не можем предложить вам оффер, так как у нас уже был работник с вашей фамилией в прошлом году.
Пагинация - устаревший способ оптимизации длинных списков. Тут и без собеса понятно, что вирт скролл вы готовить не умеете.
Kassab
А почему, интересно, вы не докопались до бокового меню, ввода фильтров и поиска нараспашку?
nin-jin
А почему, интересно, вы не докопались до других комментаторов?
Kassab
Тут не очень широкий выбор комментаторов. И у nihil-pro комментарий философский, а у вас предметный.
Стало любопытно, как получилось, что вы так тщательно подошли к критике, но при этом проигнорировали то, что мне больше всего бросается в глаза.
Все ещё любопытно.
UPD: Ой, вот заметил, что до ввода фильтров таки докопались на второй картинке.
nin-jin
А что не так с боковым меню?
Kassab
Ну, если очевидный дефицит горизонтального пространства, то странно его тратить на меню.
По первой картинке видно, что меню отъедает место в развёрнутом виде, при этом решение добавляет вариативность вёрстки (при открытом/закрытом) и недружелюбно к малым разрешениям.
Иллюзорная версия со свёрнутым меню из неразличимых иконок работает только на ежедневных пользователях. Остальные для работы с широкой таблицей будут хлопать этим меню туда-сюда.
В Jira/Confluence так же сделано, но они же уже старенькие, зачем тиражировать.
Как будто просто сделать панель сверху. Тем более, что меню уже разбито на группы.
Другой вариант - разводку всю сделать на дашборде, а меню прятать в бургер.
Ну как-то так. Первое, что бросилось в глаза.
nin-jin
Вертикальное пространство более дефицитно. Бургер не решает проблему "схлопывания/расхлопывания".