UX Notes

описание

В соцсетях: vk.com/ux_notes и fb.com/uxnotes Чат читателей: @uxnoteschat О карьере в UX-дизайне и вакансии: @uxwork Рекламодателям: uxnotes.ru/ads · В перечне РКН: gosuslugi.ru/snet/67a9a56970de7b4d761a81ae Est. 2016 · Автор: @zGrav

← к каналу @uxnotes

23 877

подписчиков

Охват к подписчикам

10,8%

ERR

Реакции к просмотрам

0,50%

976 на 50 постов

Пересылки к просмотрам

1,22%

2 392

Постов в день

0,4

всего 88

Где отзываются чаще

доля реакций к просмотрам

30 июн.Евгения Шамрай написала, что профессия дизайнера интерфейсов в привычном нам виде скоро исчезнет. — Экраны в Фигме — удобные, приятные визуально, с адаптивными состояниями, собирающиеся в сценарий — раньше сами по себе представляли ценность; — Клиенты приходили за ними к дизайнерам, потому что других вариантов особо не было. Сейчас альтернативы предлагает ИИ; — За последние 1,5 года клиенты не покупают дизайн интерфейса; — Приходят за аудитом, аналитикой, исследованием, пониманием пользователей, поиском проблем в продукте, разбором сценариев, редизайном бизнес-процессов, стратегией развития продукта; — Интерфейс появляется где-то в конце такой работы и не является основной её ценностью; — Основная ценность — в ответах на вопросы вроде: «Почему пользователи не доходят до целевого действия?», «Почему сотрудники обходят систему с помощью Экселя?», «Почему заявки есть, а продажи не растут?», «Почему люди не доверяют продукту?», «Почему новые пользователи не понимают, что делать дальше?»; — Главное — понять, какой интерфейс вообще нужен. Может оказаться, что проблему вообще не решить новым дизайном; — Будет падать спрос на дизайнеров интерфейсов и расти спрос на тех, кто умеет понимать клиентский опыт целиком; — UX, UI, исследования, аналитика и AI сольются в одну роль. #definition1,41%
3 февр.Анна Труфанова поделилась рекомендациями по дизайну интерфейсов для цеха. — Тёмная тема — стандарт безопасности, так как не слепит оператора; — Начертания Light и Regular на цеховых мониторах рассыпаются. Только Medium и Bold; — Для цифр используйте моноширинный шрифт; — Интерфейс в цеху — набор датчиков. Оператор должен считывать их за доли секунды, видеть критические показатели периферическим зрением. Для этого контраст делайте не 4,5:1, а 10:1 (ГОСТ Р ИСО 9241-303); — Чтобы не перегружать пользователя и не приучать его игнорировать сигналы, интерфейс не должен начинать мигать красным при малейшем отклонении параметров. Не все отклонения одинаково критичны (ANSI/ISA-18.2); — Дублируйте цветовое кодирование формой (ISO 9241), так как у 8% мужчин встречается дальтонизм. Красный треугольник — критическая авария, немедленная остановка. Жёлтый ромб — предупреждение, требуется внимание; — Важна мышечная память. Не меняйте положения кнопок, особенно если их нажимают в аварийных ситуациях; — Улучшайте эффективность через сокращение шагов: сохраните кнопку в привычном месте, но превратите 3 клика в 1; — Всё для оперативного управления размещайте на расстоянии клика; — Если датчик показывает проблему, интерфейс должен сам подтянуть кнопку действия в зону видимости; — Располагайте ключевые индикаторы так, чтобы они попадали в естественную траекторию взгляда, а не в слепые зоны экрана. #industrial1,15%
26 маябез подписи1,08%
29 июн.Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался. В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали! Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее. Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла. Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерминированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает. Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет. А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерминированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности. И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана). Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерминированный. Но выглядит как детерминированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе. А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать. Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый. А обещаниями своими в веб-интерфейсах друг друга кормите.1,03%
1 июл. 2025 г.без подписи0,93%
24 июн.Антон Черногоров написал о будущем интерфейсов b2b-продуктов. — Раньше они отражали внутреннее устройство систем, состоявших из ролей, прав, справочников, статусов и прочего, что нужно для выполнения задач; — Экраны получались функциональными, но не помогали выполнять задачи или принимать решения; — Считалось, что с таким интерфейсом не будет работать случайный человек и непонятность можно компенсировать обучением; — В итоге люди запоминали, где что лежит, учились обходить неудобные сценарии, заводили рядом эксельку, писали себе инструкции; — Что изменилось: привыкнув пользоваться классными b2c-продуктами, сотрудники ещё сильнее страдают, SaaS стал доступнее и выросла конкуренция, бизнес стал внимательнее считать деньги (а плохой интерфейс снижает эффективность работы сотрудников); — Хороший b2b-интерфейс даёт чувство контроля: эксперту даёт скорость, а новичка не бросает без опор, объясняет, зачем нужны именно эти данные, о последствиях предупреждает до действия, помогает исправить ошибку, подсвечивает важное, говорит по-человечески там, где техническая точность бесполезна; — Чего ждать в будущих b2b-продуктах: таблицы станут функциональнее, формы из набора полей превратятся в сценарии, пустые, ошибочные и промежуточные состояния перестанут быть техническими заглушками, навигация будет строиться вокруг рабочих контуров, а не базы данных; — ИИ будет активно помогать. Например, выводить на дашборд не все данные, а только то, что требует внимания, объясняет причинно-следственные связи и помогает принять решение; — Метрики: Cognitive load, Error rate, Time to task, eLTV, eNPS, CSAT, Cost per hire; — Для этого надо разбираться в механике продукта: кто принимает решение и какие данные нужны, где возникает риск и какие ошибки стоят денег, где пользователь теряет контекст, какие операции повторяются ежедневно, какие роли видят систему по-разному, где пользователя надо ускорить и где затормозить. #b2b0,91%
17 июн.Илья Бирман рассказал об адаптивных сайтах без брейкпоинтов. — Кирпичная вёрстка — когда сайт свёрстан под определённую ширину и не реагирует на изменение ширины окна браузера; — Благодаря резиновой вёрстке сайт выглядел хорошо на популярных размерах экранов, но потом появились очень большие ширины (2560px) и очень маленькие (320px); — На большие экраны всем было плевать. Пользователей у них было мало, да и зачем открывать браузер на весь экран на таком экране; — Появилось много инструментов, например, медиазапросы позволяют узнать, что у пользователя тач-устройство и адаптировать дизайн; — Проблема адаптивного дизайна с брейкпоинтами: надо делать несколько версий дизайна, как когда-то делали отдельные мобайл-версии; — Дизайн, адаптированный под определённый диапазон ширины, часто выглядит не очень ближе к границам этого диапазона; — Илья предлагает прорабатывать адаптивные состояния для разной ширины отдельных элементов, из которых состоит страница; — За любым этажом можно закрепить поведение: перенос строк, изменение числа колонок, прокрутка, масштабирование; — Высший пилотаж, когда переключение между состояниями элементов происходит из-за контента, а не произвольных чисел ширины; — Может потребоваться отдельный мобильный дизайн кусочка как исключение (предусмотреть тач), когда остальные части сайта не меняются драматически; — Не будет такого момента, когда сайт при какой-то ширине ломается; — Адаптивность должна быть частью дизайн-системы, а не шагом по разработке конкретных экранов; — Минус подхода Mobile-first: упрощать десктопный дизайн до мобильного проще, чем обогащать выхолощенный мобильный, плюс дизайнеры теряют навыки вёрстки. Копия в ВК Видео. #adaptive0,84%
14 авг.Тимур Репин написал о разных видах интерфейса, по каким параметрам их можно сравнить и заменит ли их всех умная строка (нет). — Человеко-компьютерный интерфейс — все элементы, через которые человек взаимодействует с компьютером. Голос может быть таким же элементом; — Интерфейс — бутылочное горлышко на пути от быстрого человеческого мозга до ещё более быстрого компьютера. Его расширение повышает эффективность решения задач с помощью компьютера; — Пропускная способность — сколько информации (как на ввод, так и на вывод) передаётся в единицу времени; — Скорость решения задачи — параметр, который зависит от количества действий, которые человек должен совершить (нажать кнопок, найти элементов на экране, вспомнить команд), и вероятности ошибиться; — Оперативность доступа — сколько времени и усилий требуется, чтобы начать взаимодействие с системой. Она повысилась с переходом от мейнфреймов к персональным компьютерам и мобильным телефонам (достаточно просто протянуть руку); — Переход от командной строки (CLI) к графическому интерфейсу (GUI) повысил скорость решения задач (не надо помнить названия команд и писать их, меньше ошибок) и пропускную способность (нажатие на кнопку вместо написания команды, вместо строк текста — полный графики экран); — Кстати, был ещё TUI (text user interface), когда интерфейс, похожий на графический, создавался текстовыми символами. Пример: Norton Commander (1984); — У носимых устройств выше оперативность доступа (они уже на голове или руке) и скорость решения отдельных задач. AR-очки видят то же, что и пользователь, и могут помочь в контексте: подсветить гайку, которую надо закрутить; — CLI и умная строка удобнее для поиска чего-то конкретного (например, приложения в телефоне по названию), ответа на вопрос в виде небольшого структурированного текста, получения конкретного нужного пользователю результата; — GUI удобнее для поиска и выбора, когда ещё нет точного запроса, когда не знаешь всех возможностей системы, когда нужно что-то подправить (проще указать, чем описывать) или видеть всё сразу (дашборд); — Там, где человеку нужно сформулировать цель, делегировать сложное действие или быстро получить ответ, умная строка будет удобнее кнопок. Там, где нужно сравнить варианты, увидеть состояние системы, управлять сложным процессом или точно указать на объект, GUI останется сильнее. #command_line #ai0,84%
19 июл.В «Работягах» написали, чем заменить сложные таблицы в b2b-интерфейсах. — Таблица с фильтрами, сортировкой, быстрыми действиями — привычный паттерн для работы с любым массивом данных; — Она удобна и понятна команде разработки. Они могут решить использовать её без каких-либо исследований; — Как универсальное решение она плохо помогает выполнять конкретные задачи и часто просто отображает данные; — Когда стоит задуматься о замене: слишком много колонок; горизонтальный скрол; чтобы понять суть, приходится открывать каждую строку или использовать правильные комбинации фильтров; пользователи только выгружают данные, чтобы обработать их в Экселе; — Не трогайте таблицы, если пользователь думает ими. В этом случае попробуйте их улучшить закреплением колонок, инлайн-редактированием и так далее; — Таблицы хороши для сравнения однотипных сущностей по одинаковым параметрам, быстрого сканирования большого массива и поиска расхождений, массовой обработки данных; — Если у сущностей есть жизненный цикл (лиды идут по воронке), таблицу можно заменить на канбан-доску: сразу видно, где затор, легко управлять потоком; — Если пользователь обрабатывает поток сущностей, подойдёт очередь. Важно выбрать параметры для отображения, которые помогают приоритизировать сущности; — Если важны даты начала и окончания и связь сущностей друг с другом, удобнее будет календарь, таймлайн или диаграмма Ганта. Важно дать возможность управления данными при просмотре в этом режиме; — Дашборд заменяет таблицу с метриками, в которой надо самостоятельно искать отклонения, держа в голове норму; — Карточки объектов удобнее, если нужна возможность рассмотреть каждую сущность целиком. В таблице картинки, теги, длинные названия, статусы и действия раздувают строки, и важные признаки теряются; — Ещё вариант: AI-слой, который будет анализировать данные таблицы (отвечают на вопрос «Что у нас есть») и, руководствуясь продуктовой логикой, подсказывать, «Что делать»: саммаризировать, выявлять отклонения, предлагать кнопки действий по каждому пункту; — Чтобы выбрать подходящий паттерн, надо понять, кто работает с интерфейсом и ради чего, какие вообще свойства бывают у объекта, какие из них нужны разным ролям и какие нужны для выполнения конкретных действий; — Не стоит избавляться от таблиц полностью: в b2b почти всегда нужен режим «Все записи» для массового редактирования, экспорта, сверки, аудита продвинутыми пользователями. #table #b2b0,82%
8 мар.без подписи0,82%
10 авг.Лёха Макаренко рассказал, что делать дизайнеру дизайн-системы, если продуктовому дизайнеру понадобился элемент, которого нет в ДС. — Этот элемент может отличаться от готовых компонентов ДС визуалом или логикой. Например, нужен инпут с маской под номер банковской карты и определением платёжной системы; — Не стоит решать за дизайнера. Лучше предложить 3 варианта; — 1. Использовать существующий компонент, выполняющий базовую функцию, но менее удобный и не такой эстетичный. Например, обычный инпут; — 2. Провести необходимые исследования и прийти к команде ДС с обоснованием, что такой компонент необходим. В идеале он должен переиспользоваться другими командами. Этот путь может занять время; — 3. Сделать кастомный элемент таким, как хочется. Надо будет проработать все нужные состояния, предусмотреть его работу в тёмной теме и так далее; — Такой подход позволяет прозрачно планировать развитие продукта и управлять дизайн-долгом; — Выбрав один из вариантов, со временем можно от него отказаться. Например, сделать кастом и потом затащить его в ДС либо заменить его на базовое решение. Или попробовать простой вариант, а потом кастомный. #design_system0,79%
23 июл.Отношения между сценарием и навигацией в интерфейсе При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации. Что будет, если просто положить сценарии в основу навигации? Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»: https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/ Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему: https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/ Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например: Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение. Ну и что, как построить навигационную модель вокруг этого сценария? Да никак. Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль. Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда. Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми. Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.0,64%