224
Чат читателей @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 раза перечитал, подумал что делает Оксимирон в этом паблике
Читать полностью…
