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