Комментарии 42
Раз вы так любите созвоны, то жду от вас голосовую, где объясняете, что это всё не баги, а фичи.
Спасибо за комментарий. Вы отлично иллюстрируете основную мысль статьи: оценивать макеты без контекста задач и ролей пользователей, значит, не видеть половины картины :) Именно поэтому я не отправляю ссылку на Figma без созвона с потенциальным клиентом. В интерфейсах, где участвуют десятки сотрудников с разными правами доступа, интеграциями и сценариями, дизайн не может быть «универсально очевидным» без пояснений.
В продуктах, которые я проектирую, созвоны это способ согласовать видение между бизнесом, разработкой и пользователями. И это рабочий инструмент, а не проявление «любви к разговору».)
Конструктивная критика всегда приветствуется, но в отрыве от сценариев и ограничений это скорее догадки. Вы так старались, поэтому я всё-таки отвечу на некоторые комментарии на скриншотах :)
Для всех фильтров в дизайне места не хватило, зато хватило для этой дыры
Шапка — это универсальный компонент, который используется на всех экранах системы. В зависимости от контекста, она может содержать дополнительные элементы, включая более длинные заголовки и управляющие кнопки. Поэтому фиксировать фильтры в этой области — неустойчивое решение, так как их расположение будет зависеть от длины заголовка экрана и наличия других элементов.
Более того, с точки зрения UX-паттернов, фильтры и поиск являются неразделимыми инструментами управления списком. Разносить их по иерархии это плохая практика, так как это снижает связанность элементов управления и усложняет взаимодействие. Поиск и фильтры должны быть визуально и логически объединены в одной зоне.
Который из них Алексей Владимирович, а который Александр Викторович
В текущем интерфейсе я намеренно показываю инициалы, так как в компании, для которой разрабатывается система, небольшое количество сотрудников. Вероятность повторения ФИО минимальна . Но даже если такое совпадение произойдёт, например, два «Иванова Алексея Владимировича», отображение полного имени проблему не решит. Оно лишь увеличит ширину колонки, что приведёт к перегрузке таблицы.
К тому же ширина колонок настраивается пользователем и если он её сузит, даже полное имя будет обрезано. Именно поэтому предусмотрена система tooltip'ов: при наведении на имя всегда отображаются полные данные, независимо от того, видны они полностью в ячейке или нет.
По каждому кликать, чтобы узнать который из них от 30.11.2024?
Колонка «КП» отображает коммерческие предложения, и их может быть несколько в рамках одной заявки. На практике это обычно 2–3, но в системе нет жёсткого ограничения на количество. В самой ячейке отображается последнее (актуальное) предложение, чтобы не перегружать таблицу.
Задача не стоит в том, чтобы сразу узнать, какое из них от конкретной даты (например, 30.11.2024). В этом нет смысла на уровне списка. Основная задача интерфейса — показать, что в заявке есть несколько КП. Именно для этого рядом с последним КП указывается счётчик («+1», «+2» и т.д.), при клике на который открывается выпадающий список с подробной информацией по всем коммерческим предложениям.
Таким образом, сохраняется компактность таблицы и в то же время обеспечивается доступ к деталям.
так 10 или 1000?
Здесь отображаются два разных показателя, относящихся к разным функциям:
"Всего записей: 1000" — это общее количество строк в таблице до применения фильтров. То есть сколько всего заявок попадает в текущую выборку.
"Кол-во записей: 10" — это настройка пользователя: сколько записей показывать на одной странице (пагинация). Это число может быть, например, 10, 25, 50 и т.д.
Например, если пользователь установил отображение по 10 записей на страницу, а отфильтрованные данные дают всего 3 строки, то он увидит только 3 строки, но настройка останется «10». А общее количество внизу при этом покажет «3».
Эти два поля не противоречат друг другу и не дублируют информацию. Они показывают разные аспекты работы с таблицей.
Ответила на вопросы на одном скриншоте. Так же могу аргументировать и второй, но не вижу смысла )
Поэтому фиксировать фильтры в этой области — неустойчивое решение, так как их расположение будет зависеть от длины заголовка экрана и наличия других элементов.
В эту область стоит перенести кнопку создания заявки и возможно поисковое поле, а фильтры лучше растянуть на всю ширину с переносом на новую строку при нехватке места. И уж точно не центрировать. Даже Эпл отказался уже от этой глупой идеи с центрированием.
я намеренно показываю инициалы, так как в компании, для которой разрабатывается система, небольшое количество сотрудников
А вы клиента уведомили, что с вашим дизайном компания никогда не вырастет и не наймёт новых сотрудников?
предусмотрена система tooltip'ов
А клиент в курсе, что он не может полноценно пользоваться интерфейсом на планшете без его перепроектирования?
отображение полного имени проблему не решит
Вот и подумайте, что эту проблему решит. Вариантов масса: индивидуальные цвета, аватары, фотки. Вам деньги платят не за то, чтобы вы весёлые картинки с Lorem Ipsum рисовали, а за то, чтобы вы подумали обо всех проблемах и решили их.
В самой ячейке отображается последнее (актуальное) предложение, чтобы не перегружать таблицу.
Актуальных КП может быть несколько. Не актуальные в этой таблице скорее всего вообще не надо показывать. Так что их все надо не просто показывать, но и делать семантически различимыми, а не просто идентификатор выводить с датой.
Здесь отображаются два разных показателя, относящихся к разным функциям:
Я знаю что такое пагинация. Если вы не поняли намёк, то у вас тут беда с текстами, которой нет на втором скрине. Впрочем, в современных интерфейсах используют гораздо более простой в использовании виртуальный скроллинг и не напрягают пользователя переходами по страницам.
Цитирование цитирований может длиться бесконечно ) Я ценю ваш системный подход, но обсуждение интерфейса вне контекста задачи это всегда работа с предположениями. В своих проектах я разбираю десятки таких гипотез, когда это действительно нужно. В данном случае у меня нет задачи вести глубокий разбор решений, так как статья о другом.
Я ответила на часть комментариев, чтобы показать контекст. Вы предлагаете решения с уверенностью, и я всегда «за» аргументированную уверенность, когда она возникает в процессе командной работы, где есть заказчик, разработчики, дизайнер, бизнес требования, нюансы.
Спасибо за вовлечённость. Думаю, если бы вы были частью команды, многие вопросы отпали бы сами собой )
А вы клиента уведомили, что с вашим дизайном компания никогда не вырастет и не наймёт новых сотрудников?
Это называется докопаться до столба. Компания же берет только однофамильцев. YAGNI.
Впрочем, в современных интерфейсах используют гораздо более простой в использовании виртуальный скроллинг и не напрягают пользователя переходами по страницам.
Пагинация и виртуальный скроллинг - это 2 разных и не взаимозаменяемых паттерна, которые применяется в разных ситуациях. Кстати, это неплохой вопрос для собеса.
А почему, интересно, вы не докопались до бокового меню, ввода фильтров и поиска нараспашку?
А почему, интересно, вы не докопались до других комментаторов?
Тут не очень широкий выбор комментаторов. И у nihil-pro комментарий философский, а у вас предметный.
Стало любопытно, как получилось, что вы так тщательно подошли к критике, но при этом проигнорировали то, что мне больше всего бросается в глаза.
Все ещё любопытно.
UPD: Ой, вот заметил, что до ввода фильтров таки докопались на второй картинке.
А что не так с боковым меню?
Ну, если очевидный дефицит горизонтального пространства, то странно его тратить на меню.
По первой картинке видно, что меню отъедает место в развёрнутом виде, при этом решение добавляет вариативность вёрстки (при открытом/закрытом) и недружелюбно к малым разрешениям.
Иллюзорная версия со свёрнутым меню из неразличимых иконок работает только на ежедневных пользователях. Остальные для работы с широкой таблицей будут хлопать этим меню туда-сюда.
В Jira/Confluence так же сделано, но они же уже старенькие, зачем тиражировать.
Как будто просто сделать панель сверху. Тем более, что меню уже разбито на группы.
Другой вариант - разводку всю сделать на дашборде, а меню прятать в бургер.
Ну как-то так. Первое, что бросилось в глаза.
Вертикальное пространство более дефицитно. Бургер не решает проблему "схлопывания/расхлопывания".
Спасибо за комментарий. В этом проекте навигация в виде боковой панели это осознанное решение. Во-первых, в системе много разделов, сгруппированных по блокам: «Сбыт», «Производство», «Снабжение» и так далее. Такая структура визуально считывается именно в вертикальном меню.
В горизонтальной навигации сохранить эту группировку сложно без выпадающих подменю, что ухудшает ориентирование и усложняет взаимодействие.
Во-вторых, горизонтальное меню плохо масштабируется. При добавлении новых пунктов оно быстро выходит за пределы экрана и требует скролла или вложенных панелей. Это создаёт дополнительные ограничения при дальнейшем развитии продукта.
В-третьих, вертикальный список воспринимается пользователями быстрее и проще. Горизонтальная строка кнопок хуже читается, особенно если пункты навигации не помещаются в одну линию.
По поводу иконок и свёрнутого состояния: интерфейс создаётся для команды, которая работает в системе каждый день. Свернутое меню — стандартная практика в таких продуктах. Иконки быстро запоминаются, а при узком экране панель сворачивается автоматически, пользователь не управляет этим вручную. Поведение адаптивное и предсказуемое.
Бургер-меню, наоборот, скрывает всю структуру под одной иконкой. Это добавляет клики, снижает обзор и усложняет навигацию. Такой подход был бы оправдан в мобильной версии, но для рабочего десктоп-интерфейса он недостаточно прозрачен.
Что касается предложения «разнести всё по дашборду». Дашборд это не альтернатива навигации. Дашборд в системе есть, но он выполняет другую задачу: стартовую и обзорную. Навигационную структуру он не заменяет.
В этом интерфейсе приоритет в устойчивости, ясности и удобстве для тех, кто работает с системой по несколько часов в день. Выигрыш в ширине не всегда оправдывает потерю понятности и логики переходов.
Такой подход был бы оправдан в мобильной версии
Не был бы. Там точно так же лучше подошло бы боковое меню.
Которое будет открываться через бургер?:)))
Через свайп.
Придется к каждому пользователю приставлять вас вместе с вашими инструкциями :)))
А вы точно дизайнер?
Много много лет назад от этого устаревшего приёма в приложениях отказались. Так бывает, когда, ux-практики меняются в сторону видимых и понятных. А вы точно разработчик? ;)
Возьмите последний айфон и попробуйте найти там хоть один бургер.
Вы не забыли скриншоты чего были в статье? )) Напомню, в статье речь о десктопном приложении. Кислое с зеленым путаете? )
Если у вас столь серьёзные проблемы с памятью - перечитывайте обсуждение перед ответом.
Вы от темы отклоняетесь, сударь) Я посоветовала вам освежить память о том, что обсуждается в статье, так как вы отклонились от темы обсуждения десктопного интерфейса и пытаетесь перейти на личности. Аргументы еще будут по теме статьи или сворачиваетесь?
Ваши детсадовские замашки не красят вас как профессионала, коим вы хотели бы казаться.
Ну а если всё же возвращаться к теме статьи, то если оформление ваших кейсов требуют килотонны словесной эквилибристики в свою защиту, то вы сделали свою работу плохо.
То есть вы не в курсе, что «Плохо» это не объяснение и не аргумент, а попытки перейти на личности, вместо аргументации и ответа на конкретные вопросы явно демонстрирует истинные ваши намерения и желания.
Как научитесь себя вести как взрослый человек и профессионал, продолжим беседу. «А ты а ты» как доказательная база действительно из детского сада, только в нем застряла точно не я. Удачи вам ;)
Жду пример схожего по функционалу приложения на айфоне, где меню открывается только по свайпу
Кстати, по поводу свайпа для вызова бокового меню. Такое я видел у DeepSeek для Андроида. Также его можно вызвать, кликнув иконку бургера.
Свайп для вызова не сказать, что популярный, но интересный и интуитивно понятный способ.
Свайп от левого края после погружения - в большинстве приложений это не "назад" как в браузере, а открытие меню предыдущего уровня. Присмотритесь, это очень распространённый паттерн.
Свайп для вызова не сказать, что популярный, но интересный и интуитивно понятный способ.
Возможно, но в статье идет речь о CRM для десктопной версии. Говорить о свайпах в контексте темы не имеет смысла, даже если была бы мобильная версия. Вне контекста темы - почему бы и нет, если это действительно уместно и упрощает пользователям жизнь
Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma
Потому, что это не поможет. Сложные интерфейсы возникают потому что разработчикам нравится их создавать, а заказчики не знают других способов решения задачи. В результате получаются такие интерфейсы, как на скринах в статье — пульт управления космическим кораблем.
Все эти «сложные интерфейсы» не более чем пародия на эксель, а зачем он пользователю? Дайте ему уже сформированные отчеты/почитанные результаты, а не калькулятор. Тогда выяснится, что интерфейс может быть простой.
Спасибо за комментарий. Если интерфейс похож на «пульт управления космическим кораблём», значит, задачи действительно сложнее стандартного отчёта или формулы в Excel :)
Интерфейс продукта это инструмент для работы с бизнес‑процессами: он учитывает роли пользователей, их задачи, права, интеграции, историю изменений, сценарии взаимодействия между отделами.
Таблица в интерфейсе всего лишь способ наглядно структурировать данные, а не аналог Excel по сути.
В моей практике были запросы, когда компании начинали с Excel, но по мере роста данных, числа одновременных пользователей, требований к правам доступа и необходимости автоматизировать связанные бизнес-процессы таблицы переставали справляться, и возникала потребность в разработке собственного интерфейса.
Если опыт вашего бизнеса или продукты позволяют обходиться без сложных интерфейсов и сценариев это отлично, но в большинстве B2B и корпоративных проектов интерфейс это результат компромисса между сложностью процессов и удобством пользователей.
Если интерфейс похож на «пульт управления космическим кораблём», значит, задачи действительно сложнее стандартного отчёта или формулы в Excel
Вы эти клише заказчикам оставьте.
Если опыт вашего бизнеса...
...но в большинстве B2B и корпоративных проектов
Как изящно вы завуалировали то, что на самом деле хотели сказать. Что-то вроде – «Да ты просто над сложными проектами не работал!».
А такие интерфейсы можно сделать простыми?
Скрытый текст
Возможно, что-то можно упростить, возможно и нет. Любой ответ на подобный вопрос был бы не корректен без 1) понимания что за функционал 2) понимания для кого работает 3) без погружения в процессы взаимодействия. Любой специализированный интерфейс будет казаться непонятным без ответов на эти вопросы )
Да.
А вот там на панелях бортового компьютера проще стало?
Разумеется. Как раз благодаря этому, всяких кнопок/рычагов стало меньше. Нужно также иметь ввиду, что сами самолеты стали гораздо сложнее, вместо условного датчика давления масла, они теперь анализируют чуть ли не химический состав воздушного потока. То есть, при том, что сами самолеты стали сложнее, приборная панель упростилась.
наверное, есть смысл рассматривать было/стало в рамках одной модели, внизу на первой Ту-154, на второй Cessna. Два разных типа и класса самолета
Вот сравнения кабины МС-21, который создавался на смену ТУ 154, взяла как раз фото nihil-pro
Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?