Чат читателей @uxnotes · Редактор: @zGrav
С прошлого анонса в @uxwork кроме вакансий вышли ещё материалы:
— О красных и зелёных флагах во время интервью с кандидатами;
— О разных форматах оплаты при работе с заказчиками (почасовка, фикс, абонемент) и примере пути фрилансера от одного формата к другому;
— О поиске работы в сравнении с поиском спутника жизни в дейтинговом сервисе.
Статья очень плохо написана
Есть ощущение что автор вообще не проводил исследование, а просто написал какую-то х»»ню и отсебятину без экспертизы
Не стоит на это ориентироваться, и точно не стоит рекомендовать к прочтению
Чет хз, у нас табы второго уровня как раз должны выглядеть как табы, чтобы была прозрачная иерархия. Сегментирование переключатели норм живут в модалках настроек и в календаре (день/месяц/год)
Читать полностью…Энтони Ценг написал uxteddy/27AG4BEr9U7">о сегментированных переключателях в формах.
— Сегментированные переключатели нужны в основном для переключения между разделами, как табы;
— Ошибка — использовать их для выбора значений в формах и заменять ими группы радиокнопок;
— Вместо групп радиокнопок, особенно, если мало места по вертикали, можно использовать чипы одиночного выбора;
— В отличие от нажатия на сегментированный переключатель, при нажатии на чип сразу ничего не происходит. Пользователь выбирает значение, которое затем подтверждает нажатием на кнопку;
— Свитч (тоггл) — частный случай такого переключателя, и их тоже неправильно используют вместо чекбоксов.
In English. #chips #toggle #segmented_control
Юрий Герыш написал о работе с Chrome DevTools.
— Открыть их можно через меню (пункт «Инструменты разработчика») или нажав правой кнопкой мыши в любом месте страницы (пункт «Просмотр кода страницы»);
— Экспорт изображений в формате SVG: скопируйте содержимое тега <svg> из кода страницы и вставьте в Фигму;
— Если картинка в формате PNG, можно поискать её SVG-версию на сайте: добавьте к адресу картинки «?svg», например: «https://habr.com/img/habr-logo-ru.png?svg»;
— Меняя код CSS (вкладка Styles), можно быстро прикидывать стилевые правки;
— В Styles можно видеть и менять правила, определяющие внешний вид страницы;
— На вкладке Computed отображаются текущие свойства выбранного элемента, которые получились после применения всех правил. Например, сколько в пикселях составила ширина, которую задали в процентах;
— Меняя HTML, можно править текст, дублировать и удалять элементы;
— Так можно проверить поведение элементов в корнер-кейсах. Например, что будет, если название слишком длинное;
— Просмотр адаптивных состояний: можно задать размер окна браузера. Есть пресеты размеров популярных устройств;
— Чтобы выбирать Инспектором элементы, свёрстанные с помощью Shadow DOM (изолирование стилей элемента), включите в настройках «Show user agent shadow DOM»;
— Просмотр состояний элементов (hover, active): список состояний отображается на вкладке Styles с нажатым «:hov», либо можно выделить элемент через Инспектор и в контекстном меню нажать «Force state».
#review #chrome_devtools
С упоением прочитал ещё на той неделе, почему-то кейсы со всякими банкоматами/КСО/и т.п. очень заходят, буду ждать продолжения!)
Читать полностью…Женя — красавчик
Побольше бы таких интересных кейсов в канале про реальный опыт в нестандартных кейсах
Виктория Друзенко написала о прокачке UI.
— Навыки UI-дизайна могут просесть, если долго работать с дизайн-системой на одном продукте;
— UI Daily может не подойти, так как макеты там оторваны от контекста, и надо тратить время на его додумывание;
— Переделывайте макеты из своих старых проектов. Подойдут даже макеты с предыдущего спринта;
— Так вы увидите свой прогресс, можете пересмотреть решения и улучшить UX, не будет ограничений со стороны заказчиков и разработки, а результат можно положить в портфолио;
— Анализируйте чужой дизайн, выделяя удачные и неудачные решения, предлагайте альтернативы;
— Публикуйте свои наблюдения там, где другие дизайнеры могут их увидеть и обсудить, это даст обратную связь;
— Так вы научитесь давать обратную связь, прокачаете насмотренность;
— Вовлекайте коллег, знакомых дизайнеров, менторов;
— Помимо того, что так веселее, будет больше обратной связи, можно перенять чужой опыт, сложнее слиться с прокачки;
— Перерисовывайте понравившиеся макеты;
— Так ваша база UI-решений будет расти. Вы будете не только знать разные визуальные ходы, но и уметь их воспроизвести;
— Можно попробовать новые инструменты для оптимизации работы. Если надо перерисовать экран, стоит подумать, как сделать это быстрее и качественнее.
#visual #upskilling
Думаете, такое сильно может пошатнуть веру в вас как в эксперта, который всё учёл?
Читать полностью…Про записывать все комменты чуть ли не под роспись заказчика — мастхэв, иначе потом концы не найти + так можно избежать лишней возни в коммуникации и конфликтов
Читать полностью…Очень хорошо, когда ID строки помогает понять контекст. И когда есть скриншоты всего интерфейса.
Читать полностью…Календарная нет, рабочая, я надеюсь, да. Или вы там на 6-дневку перешли
Читать полностью…Упоминанемые в статье чипы — это какая-то ошибка интерфейсостроения. По ним не ясно что это: кнопка или просто текст в рамке. По ним сразу не ясно они дают возможность выбрать один или несколько элементов. Это просто кошмар какой-то. Их лучше никогда не использовать и забыть как страшный сон. Слишком контексто зависимый элемент.
Читать полностью…Карен Ананян написал о подходе Stretch, Scale, Switch при проектировании адаптивных состояний.
— Веб-страницы могут по-разному адаптироваться к разным ширинам устройств или окон браузера;
— Например, а) масштабироваться, способ был единственным, когда мобильному трафику ещё не уделяли столько внимания, б) растягиваться по горизонтали, сохраняя компоновку, в) менять компоновку в заданных точках слома (брейкпоинтах);
— На современных адаптивных сайтах обычно комбинируют последние 2 способа;
— Но их можно дополнить и масштабированием: в определённом диапазоне ширин растягивать интерфейс. При более значительном изменении — пропорционально его масштабировать. И когда компоновка перестаёт быть удобной — менять её;
— Растягиваем → Масштабируем → Переключаем на другую компоновку → Повторяем;
— Достаточно подготовить несколько компоновок и для каждой определить, в каких пределах она будет тянуться и масштабироваться, чтобы на любых экранах был гармоничный интерфейс.
#adaptive
Они ведь могут по сути быть табами второго уровня? Есть примеры удачного использования?
Читать полностью…я видела реакцию нескольких людей, когда сайт показывает скелетоны по всему экрану, причем даже вместо текста, ладно бы вместо картинок, видео...
Обычно через 0,3 - 0,5 сек сайт закрыт.
Антон из X5 Tech написал о скелетонах.
— Это такая загрузка экрана, когда сначала отображаются серые прямоугольники, а потом вместо них появляется контент;
— Их важно анимировать, чтобы всё это не было похоже на баг;
— Прижилась пульсация (мерцание) и волна (единое для всех блоков смещение градиента, background: fixed);
— Плюс скелетона в предварительном представлении структуры экрана и возможности отображать контент по мере его загрузки;
— Каждый прямоугольник скелетона — обёртка для контента и заглушка на время загрузки;
— Но что должно быть внутри обёртки: атом, молекула или организм в терминах атомарного дизайна?
— Отдельными блоками скелетона может быть то, что запрашивается с сервера отдельными запросами;
— Скелетировать можно всю страницу (высоконагруженные проекты, у значимой доли пользователей плохой интернет), её части (тяжёлые блоки с таблицами, статистикой) или отдельные элементы (результат множества запросов, сложного вычисления и так далее);
— Будьте последовательны. Если где-то есть скелетоны, спиннеры в раскрывающихся списках смотрятся странно;
— Заглушки должны соответствовать размеру контента (в первую очередь высоте), чтобы при загрузке ничего не скакало, а также его внешнему виду, чтобы не сильно контрастировать с контентом;
— Если в карточках может быть разный состав контента, ради простоты можно сделать для всех карточек одну усреднённую заглушку;
— Высокая детализация требует затрат, которые не всегда оправданы. Например, вкладки могут быть одним прямоугольником. Обычно это один компонент на странице, его заглушка воспринимается как заголовок, да и показывать заглушки отдельных табов непросто;
— Но иногда повышение детализации имеет смысл и помогает сразу привлечь внимание к определённой части страницы;
— Повторяющиеся элементы вроде ячеек с текстом в таблице можно скелетировать красиво, сделав заглушки разной ширины (90, 75, 85, 80, 65% от ширины ячейки) и сохранив выравнивание.
#loader
Ищем Middle UX-редактора в команду Точки.
Точка Банк — финтех-компания, создаём онлайн-банк и другие сервисы для бизнеса.
📍От 150 000 ₽. Удалёнка или работа в офисе, мы есть в 20 городах по всей стране.
У нас комьюнити UX-редакторов, чётко прописанный TOV, гайды и библиотеки. Мы ждём, что редактор будет бороться за согласованность языка Точки в интерфейсах и всячески помогать в разработке сервисов.
Что делать:
— Писать тексты для продуктов: работать с интерфейсами, рассылками и сервисными сообщениями.
— Искать решения вместе с продактами, дизайнерами и UX-исследователями.
— Вместе с маркетологом создавать баннеры, рассылки, онбординги и другие промо-тексты для активации бизнес-карт.
Ты подойдёшь, если:
— Есть опыт работы UX-редактором от двух лет.
— Есть опыт работы с продуктами для предпринимателей.
— Понимаешь, как создаётся продукт, как решаются задачи продукта с помощью текста, как выстраивается работа с продакт-оунерами и дизайнерами.
— Знаешь, как следовать TOV в коммуникациях.
📝 Узнай больше и откликайся на сайте.
Женя Белодед поделился процессом и находками из исследования касс самообслуживания.
— Для сокращения воровства в «Пятёрочке» касса выводит изображение со своей камеры прямо в интерфейс и так показывает, что за покупателем наблюдают;
— Удобно, когда кнопки «Каталог», «Пакеты» и «Позвать на помощь» доступны всегда. В любой момент можно взять пакет, если не рассчитал вместимость рюкзака, и позвать консультанта, если возникли вопросы;
— С верхней частью экрана взаимодействовать неудобно. Все важные элементы лучше размещать в нижней, а список товаров формировать снизу вверх;
— Длинный список товаров должен прокручиваться автоматически, чтобы последние отсканированные позиции были видны сразу;
— Большой экран устройства скорее усложняет использование, надо искать способы оптимизации «пробега» пальца и глаза;
— Обозначение товаров 18+ и 16+ в списке помогает консультантам быстрее в нём ориентироваться, когда надо подтвердить возраст покупателя;
— Компактнее и удобнее объединять одинаковые товары в одну строку, указывая количество штук;
— Если показывать старую и новую цену для товаров со скидкой и акционных, экономия станет наглядной, снизится стресс от покупки;
— В сложных ситуациях помогают интерфейсные подсказки о действиях пользователя в кассе и вне её;
— Как справляться с косыми взглядами охранников: «Придумал историю, что возрастная мама хотела бы начать пользоваться кассой самообслуживания, но боится, что не разберётся и будет выглядеть глупо. Поэтому попросила сына записать видеоинструкцию, чтобы разобраться дома. С такой легендой охранники были спокойны, а консультанты без проблем всё показывали и комментировали прямо на камеру».
#retail #self_checkout
Отличный совет. Я иногда специально оставляю что-то мелкое недоделанным чтобы заказчик мог на это указать.
Читать полностью…...либо поблагодарить за идею. Так он станет причастным к финальному результату;
Егор Камелев написал, как минимизировать количество правок, подготовиться к оставшимся и работать с ними, чтобы легче сдавать проекты.
— Даже если вам стало предельно ясно, чего хочет заказчик, всё равно дослушайте до конца и выясните как можно больше деталей перед началом работы, чтобы максимально синхронизировать видение решения;
— Договоритесь о терминах. Сложные и неоднозначные понятия бывают и в вашей работе (что такое «прототип»?), и в специфике бизнеса заказчика («комплект» в интернет-магазине?);
— Сразу готовьтесь к правкам: осознанно и единообразно называйте страницы и разделы, повторяющиеся элементы превращайте в компоненты, пока не согласованы основы (например, состояния в статике), не уходите в детали (анимации и переходы);
— Покажите первые результаты как можно раньше, чтобы получить корректирующие комментарии к полуфабрикату и не переделывать потом «утку» в «кролика»;
— Показывайте столько, сколько можно изучить за один подход. Иначе заказчик будет присылать комментарии пачками, что растянет процесс и повысит вероятность противоречивой обратной связи. Такое допустимо в самом конце проекта;
— В этом случае заказчик или кто-то из команды может указать на что-то недоделанное: «Когда форма отправлена, надо показать сообщение об этом». Можно сказать, что вы так и собирались сделать, либо поблагодарить за идею. Так он станет причастным к финальному результату;
— Чтобы реже пересматривать собственные решения, сперва проработайте атомарные разделы, а потом то, что из них состоит. Карточка компании → список компаний (использует данные из карточки) → дашборд или главная;
— Конкретизируйте субъективную обратную связь, чтобы не проделывать напрасную работу. Задавайте уточняющие вопросы, показывайте референсы;
— Сохраняйте варианты, которые заказчик отмёл, чтобы было к чему вернуться, если концепция изменится и он передумает;
— Не бойтесь показывать рабочие варианты, которые вы сами отмели, чтобы заказчик увидел, что вы хорошо поработали. Иногда он может увидеть там что-то, что поможет быстрее прийти к нужному решению;
— Записывайте все комментарии, нумеруйте, показывайте, как каждый комментарий был отработан. Очень плохо, когда забытые комментарии замечает заказчик;
— Вам могут доверять как специалисту, вы можете быть убедительны, приводить цифры и факты, но ответственность за проект несёт заказчик. Хорошо, когда он чувствует, что получил именно то, что нужно.
#client
Ну это до меня дошло как раз когда я прочитал заголовок в 3-й раз))
Читать полностью…3 раза перечитал, подумал что делает Оксимирон в этом паблике
Читать полностью…