Максим Шток написал вводную статью об AR-дизайне со множеством ссылок для дальнейшего изучения.

AR-контент делают:
— Для смартфонов: маски, виртуальная одежда и обувь, навигационные указатели, игры;
— Носимых устройств вроде Hololens и Magic Leap: на текущем этапе развития в основном для узких задач корпоративных клиентов;
— Не носимых устройств: проекции на лобовое стекло автомобиля, вертолёта или корабля.

Различают разные масштабы применения:
— Table scale: объекты на столе, виртуальные рабочие пространства и виджеты;
— Room scale: объекты в комнате, например, Studio Mode в приложении Ikea Place;
— World scale: объекты в окружающей среде вроде уличной навигации и стрит-арта.

Профессия разработчика для AR только зарождается, стандартов UX/UI ещё нет, надо много исследовать: сложность восприятия разной информации, в том числе под разными углами зрения. Быстрее всего адаптируются UX/UI-, моушн-, гейм-дизайнеры и специалисты по 3D-моделированию.

Рынок AR-гарнитур растёт на 73,8% в год.

В проекции на прозрачное стекло не может быть чёрного цвета, так как им нельзя светить. Если вы такое видите в ролике, это графика, а не реальный продукт.

https://designpub.ru/f62056a8108e

Александр Радал написал о способах снизить когнитивную нагрузку пользователей.

— Уменьшайте количество вариантов, из которых надо выбирать. Так не только проще выбрать, но и выбранный вариант будет радовать пользователя больше (он меньше сомневается, что не проглядел вариант получше);
— Не стоит уменьшать количество пунктов меню до ±7 просто ради числа. Большой список лучше, чем поиски нужного пункта во вложенных меню (с неконкретными названиями типа «Прочее»);
— Если пользователь ошибся, дайте простой способ вернуться к предыдущему состоянию или исправить ошибки;
— Управляйте пользовательским вниманием визуальными подсказками вроде стрелок и изображений людей, смотрящих на важные элементы страницы;
— Используйте знакомые шаблоны и условности: единая цветовая палитра во всём продукте, знакомые паттерны взаимодействия (например, хлебные крошки), знакомые иконки и символы (например, корзина для удаления файлов);
— Общайтесь с будущими пользователями продукта;
— Раскрывайте информацию постепенно: сначала важную, затем второстепенную.

#cognitive_load

В «Атвинте» написали о хорошем UX (с примерами).

— Опыт взаимодействия с технологичным продуктом может быть хорошим или плохим, но он зависит не только от дизайна интерфейса;
— Хороший интерфейс может стать преимуществом, но его одного недостаточно, нужны и другие ценности (например, размер каталога в онлайн-кинотеатре);
— Дизайнер отвечает за понятность структуры и навигации, UI, переходы и анимации. За производительность и скорость загрузки сервиса отвечают разработчики. За то, что продукт решает проблему пользователя, и за соответствие его социальному, культурному и демографическому контексту — аналитики. А скорость интернета, производительность устройства и настроение пользователя обычно не зависят от сотрудников сервиса;
— Есть законы восприятия и тому подобное, но нет универсальных законов дизайна, которые работают для любого интерфейса: и для мобильной игры, и для интернет-магазина, и для интранет-портала;
— Пользователю важен не дизайн, а получится ли у него решить задачу с помощью продукта. При его создании надо думать о ценности продукта, пользовательских задачах и том, как их эффективно решить, не раздувая издержки компании.

https://vc.ru/design/251212

Пейдж Лаубхаймер из Nielsen Norman Group написал о левосторонних вертикальных меню на десктопных версиях сайтов.

Преимущества:
— Нет искусственного ограничения на количество пунктов, как в горизонтальном меню. В меню есть место для конкретных и понятно названных категорий, что упрощает навигацию;
— Есть место, чтобы добавлять новые пункты;
— Вертикальное меню проще сканировать (если его пункты выровнены по левому краю), плюс, пользователь, читающий слева направо, начинает с него сканирование страницы;
— Проще перенести в мобильную версию сайта.

Недостатки:
— Занимает больше места, сложно использовать на небольших экранах;
— Не все пункты могут быть видны на первом экране.

Рекомендации Кэпа:
— Размещайте меню слева (для аудитории, читающей слева направо) и делайте заметным;
— Пункты меню должны быть текстовыми (или иконками с подписями). На сайтах, которыми люди пользуются каждый день, можно по желанию пользователя скрывать подписи;
— Наименее важные пункты размещайте в конце списка.

https://www.uprock.ru/articles/levostoronnyaya-vertikalnaya-navigaciya-v-desktopnoy-versii-sayta-masshtabiruemost-otzyvchivost-i-prostota-prosmotra

Дэвид Холл написал об интерфейсном тексте. Например:

«Ваш профиль» или «Мой профиль»:
— Используйте Ваш, когда хотите показать, что система что-то сделала персонально для пользователя. «Ваш отчёт»;
— Используйте Мой, когда хотите подчеркнуть, что в этой части системы пользователь хранит частичку себя: личную информацию, результаты действий, историю. «Мой счёт, мои настройки, мой плейлист»;
— В большинстве случаев можно обойтись без Ваш или Мой, и это будет даже лучше. Используйте их только в тех ситуациях, когда нужно явно отделить личное от общего.

Активный и пассивный залоги:
— Старайтесь использовать активный залог. Он описывает, как человек или объект что-то делает. «Сергей танцует»;
— Используйте его, когда хотите подчеркнуть, кто или что делает какие-то действия. «Такси подъехало»;
— Пассивный залог используйте в тех редких случаях, когда действие или состояние важнее объекта, к которому оно относится. «Корзина переполнена, задача выполнена».

https://vk.com/@sobakapavlovaltd-interfeisnye-teksty-kak-dizaineru-nachat-pisat-gramotnee

Андрей Шапиро рассказал о журнале проектировщика.

— Инструмент помогает структурировать проектирование, не размывать фокус и получить на выходе подробное описание проекта;
— Проектировщик может отвлекаться от цели и забывать важную информацию, переставать следить за проектом в целом и его границами;
— Системы становятся настолько сложными, что их невозможно моделировать в голове. Обычно разработкой занимаются команды специалистов;
— Решение сложной задачи похоже на бесконечный цикл попыток построить и проверить модель, сформировать другую модель, чтобы скомпрометировать предыдущую, а потом заново переосмыслить исходную задачу;
— Надо записывать в единый реестр всё, что появляется в ходе размышления. Но записи не должны быть быть хронологическими;
— Этапы работы с журналом: 1) Запись новых мыслей, 2) Формулировка и категоризация, 3) Проектирование и проверка решений, 4) Перенос знаний в хранилище и чистка журнала;
— Вести журнал можно в программах, позволяющих группировать записи с помощью разнообразных иерархий: раскрывающиеся списки иерархий, дерево страниц или списков. Notion подойдёт;
— О категориях журнала важно договориться в начале проекта. Возможные варианты: 1) Ситуация, сценарий, 2) Проблема, нежелательный эффект, 3) Задача, 4) Идея, 5) Противоречие, 6) Критерий готовности / успешности, 7) Договоренность, 8) Цель.

https://xraizor.medium.com/c785d752b9ec

Евгений Честнов написал о своём опыте дизайна систем диспетчеризации.

Одно дело показать 3д-графикой насосы, клапаны, фильтры и заслонки, другое дело — сложное технологическое оборудование. Найти подходящие картинки ультрафиолетовых ламп и фильтров очистки крайне сложно, не говоря уже о флотаторах, жироловках и обезвоживателях. Поэтому от 3д со временем отказались.

В интерфейсе читаемые и редактируемые переменные визуально не отличались. Чтобы понять, это установка или индикация значения, надо было нажать на неё и посмотреть, выскочит ли экранная клавиатура.

Чтобы показать информацию о теплоснабжении (работа насоса, клапана, температура обратной воды), нужно было рисовать целый узел с трубами, насосом, перемычками и прочим, что занимало много места и несло мало информации. Теперь вся информация находится в карточке «Нагрев». Если появится система с дополнительным увлажнением или ступенью нагрева, можно просто добавить новую карточку с нужной информацией. При этом интерфейс будет выглядеть преемственно на разных устройствах и разрешениях.

https://habr.com/ru/post/560046/

Вадим Мазин поделился рекомендациями для мобильных версий интернет-магазинов.

— Всё чаще навигация, поиск и корзина в мобильных версиях интернет-магазинов перемещаются к нижней границе экрана;
— Если люди редко покупают товары магазина (например, электроинструменты) и обычно изучают характеристики и отзывы, от кнопки «Купить» в каталоге можно отказаться;
— Пользователю легче решиться на покупку, если есть отзывы. Хорошие магазины выстраивают системы получения обратной связи от клиентов;
— Если важен внешний вид товара, отзывы с фото круто увеличивают конверсию;
— Надо объяснять, почему клиент видит конкретную персональную подборку. Если по интересам он относится к группе «Монтажники», то подборку можно назвать «Выбор монтажников».

https://surf.ru/5-pravil-khoroshiegho-mobilnogho-maghazina/

Дмитрий Ваницкий написал о дизайнерском развитии.

— Рост уровня (джун, мидл, синьор, лид) показывает развитие, если он происходит внутри одной компании. Если уровень меняется с переходом в другую компанию, развития здесь может и не быть;
— Уровень значит, что у вас есть определённое количество очков ценности, но они могут распределяться по навыкам в разных комбинациях;
— Изучите компанию мечты, определите её фокус и адаптируйте систему навыков под неё, добавив нужные и убрав ненужные;
— В Epam посмотрели, какие задачи решали дизайнеры за последние полгода. Выяснилось, что навыки Motion Design, 3D Modeling, Space and Time Design использовались редко;
— В итоге выделили 7 кластеров навыков: Discovery, Research, UX Design, Visual Design, Design Ops, Teamwork and Collaboration и Interpersonal. В каждом по 3−4 навыка, внутри которых ещё по 4−5 сабнавыков;
— Уровни навыков: знаю, понимаю (применяю знания на практике, но под присмотром), могу (без присмотра), учу (обладаю передовыми знаниями по теме, могу обучать).

Также Дмитрий поделился таблицей со списком навыков и сабнавыков и пошаговым алгоритмом прокачки.

Советы для шага «Определитесь с фокусом»:
— Не пытайтесь максимизировать один навык за другим. Рост должен быть органичным. Прокачивайте навыки настолько, чтобы закрыть свой текущий уровень и перейти на следующий;
— Если навыков для прокачки несколько, выбирайте тот, который скорее всего пригодится на практике. Его освоение пойдёт быстрее.

https://medium.com/design-spot/cbde24ed2004

Мэтью Стендедж написал о применении неактивных кнопок [English].

Иногда лучше позволить пользователю ошибиться и получить подходящую обратную связь, чем не дать ему ошибиться.

Например, есть форма с обязательными полями и кнопка отправки формы, которая остаётся неактивной, пока пользователь не заполнит форму.

— Неактивная кнопка малозаметна. Размещённый на ней призыв к действию работает хуже;
— Нажатие на неё не приводит к целевому действию и обычно не даёт обратной связи. Непонятно, что делать, если форма вроде как заполнена, а кнопка всё ещё неактивна;
— Пользователи, которые раньше не сталкивались с такими кнопками, будут недоумевать, почему дизайн этой конкретной кнопки отличается;
— Неактивными кнопками в сложном интерфейсе можно закрыть недоступные пользователю функции. Но они всё равно не объяснят, почему функция недоступна.

#form #button

Руни Госвами написала, как в Lyft упорядочили использование сегментированных контролов.

Этот компонент собирались удалить из дизайн-системы из-за невостребованности, но решили сначала разобраться.

В Apple определяют Segmented Control как линейный набор из двух или более сегментов, которые работают как взаимоисключающие кнопки. Часто его используют для переключения различных представлений (например, отображение карты в формате схемы, снимков со спутника или гибридном).

В Material Design для навигации есть табы, а сегментированные Toggle Buttons используют для группировки кнопок и не относят к контролам выбора (среди которых только чекбоксы, радиокнопки и переключатели). Кнопки могут не быть взаимоисключающими.

Аудит выявил 14 разных сегментированных контролов в 10 продуктах Lyft. Они различались стилистически и семантически (для навигации и выбора). Компонент дизайн-системы оказался невостребованным из-за недостаточной гибкости.

— Добавили стилей: текст, иконка, текст с дополнительной информацией, когда работа с компонентом — основное действие;
— Показали, как новый компонент работает на существующих экранах;
— Для фильтрации и навигации решили использовать табы;
— Нарисовали схему принятия решения, когда какой контрол использовать (очень полезно);
— Сегментированный контрол решили использовать, когда вариантов для выбора от 2 до 5, они однородны и состоят из 1−2 слов.

https://ux.pub/kak-my-uluchshili-segmentirovannye-elementy-upravleniya-segmented-control/

Кроме эвристик Якоба Нильсена при создании дизайна можно ориентироваться и на принципы хорошего дизайна Дитера Рамса.

Эрик Дрейк поразмышлял о самом сложном для понимания принципе, о котором Рамс сказал так:

«Хороший дизайн честен. Он не показывает продукт более инновационным, мощным или ценным, чем он есть на самом деле. Он не пытается манипулировать потребителем с помощью обещаний, которые невозможно выполнить».

Честный дизайн:
— Новая штаб-квартира Vitsoe;
— Кассетная дека Braun C301. Сразу понятны её возможности;
— Раздел пользовательских настроек Google Now. Позволяет управлять работой алгоритмов.

Нечестный:
— Манипуляции антивируса McAfee, направляющие пользователя к продлению лицензии;
— Бесполезные уведомления от приложения Restaurant 2, которые нужны только для привлечения внимания.

#heuristic

Роман Шамин написал, что может сделать дизайнер, чтобы обеспечить 80% доступности экранных интерфейсов. Например:

— Почти всегда полезно иметь раздельные текстовые стили: Paragraph — покрупнее, со свободным интерлиньяжем, для набора текста и чтения; UI — помельче, с плотным интерлиньяжем, для интерфейсных элементов;
— Помните, что Contrast Ratio считается относительно фона, и когда вы помещаете текст на цветную плашку, контрастность снижается;
— Чтобы отделить менее важный текст от основного, вместо сильного изменения цвета или размера комбинируйте умеренное изменение цвета и размера. Также можно использовать курсивное или сжатое (Condensed) начертание;
— Дополняйте выделение элементов в ряду подобных чем-то кроме цвета: начертанием шрифта, контрастным графическим элементом, пиктограммой;
— Применяйте принцип «тексту — собственный этаж». Он может в любой момент занять больше места, чем было в макете, потому что пользователь увеличил шрифт в настройках ОС. Или из-за изменения текста и локализации;
— По возможности откажитесь от усечения текста многоточием или фейдом;
— Передавая разработчикам макеты с нетекстовыми контролами, указывайте, какой глагол экранная читалка должна прочитать незрячим людям для каждой пиктограммы.

https://teletype.in/@romanshamin/a11y-for-designers

Анна Кейли из Nielsen Norman Group написала о листбоксах и раскрывающихся списках: из чего состоят, как работают, когда их лучше использовать.

— Листбокс состоит из контейнера, списка вариантов для выбора, текстовой подписи. Пользователь может выбрать один или несколько вариантов, нажимая на них. Если вариантов много и размер листбокса небольшой, в контейнере может быть прокрутка;
— Типы: 1) С выбором одного варианта; 2) С выбором нескольких вариантов через нажатие Control или Command; 3) С чекбоксами; 4) С двумя контейнерами;
— Вариант с чекбоксами часто встречается в фильтрах интернет-магазинов;
— Вариант с двумя контейнерами иногда можно встретить, например, при настройке состава и порядка столбцов в таблице. Пользователи могут переносить элементы списка из одного контейнера в другой и менять их порядок;
— Листбоксы и раскрывающиеся списки используют, когда места мало, а вариантов для выбора больше 5;
— Листбоксы хорошо подходят для отдельных задач (см. выше) и если надо обратить внимание пользователя на основные варианты для выбора;
— С ними проще взаимодействовать, чем с раскрывающимися списками: часть вариантов можно выбрать сразу, остальные — после прокрутки контейнера. При прокрутке длинного и узкого раскрывающегося списка пользователь может случайно сдвинуть курсор в сторону и закрыть список;
— Минусы: они непривычны пользователям и занимают больше места, чем раскрывающиеся списки.

https://school.usabilitylab.ru/ulblog_8_2368/

Игорь Сидоренко побеседовал с Евгением Яровым из Pragmatica.

— Как учился дизайну? По наитию, в то время доступной информации было мало;
— Стал бы заниматься веб-дизайном сейчас? Да, профессия включает разные аспекты: инженерные решения, творчество, коммуникацию с людьми;
— Как учился бы дизайну сейчас? Теоретические и практические курсы, стажировки, менторы. Надо сочетать теорию с практикой, а также разбираться, кто есть на рынке и какие работы делает, чтобы понять, у кого можно учиться;
— Совет новичкам: если хотите быть дизайнерами, не ждите стажировки, сразу начинайте делать работы;
— Евгений не ждёт от работ новичка проработанного UX, учёта технологических и бизнес-требований. Надо просто показать, что вы достаточное количество раз открывали редактор и можете сделать что-то посвежее, посовременнее, попонятнее, чем есть сейчас. Дальнейшие требования будут зависеть от места, где вы хотите работать;
— Каких соискателей не рассматривает? 1) Когда складывается впечатление, что человек пытается обмануть или просто неадекватно оценивает свои скилы и их стоимость. 2) Когда не видно, что человек действительно решил заниматься дизайном (хотя бы год в теме или проходит интенсивы студии);
— Как оценивать свой рост? Фриланс — самая вредная форма существования, без сообщества сложно оценивать себя. В хорошей студии дизайнера выдавливают наверх новички, либо с ним что-то не так. Есть руководитель, который помогает с развитием;
— Менторы — вариант обучения на мидл-уровне. Арт-директор в студии работает на студию, а не персонально на дизайнера;
— Как найти ментора? Не стоит сразу обсуждать менторство, напишите опытному дизайнеру и попросите созвониться, чтобы показать работы и обсудить, заплатите за время.

https://www.youtube.com/watch?v=mWhDax7ivqI

Сергей Петров поделился системным взглядом на проектирование сложных программных продуктов (на примере программ для сотрудников отделений почтовой связи).

«Часто многие требования на самом деле являются не требованиями, а ограничениями. В чём же отличие? Требования — это чёрный ящик, они ничего не говорят про устройство системы внутри. А любые требования, предъявляемые к тому, как система устроена внутри, ограничивают инженерные и конструкторские решения. Это уже не требования к системе, а требования к подсистемам внутри неё. Такие ограничения надо выявлять, отслеживать и обсуждать, а часто — снимать».

«Архитектурное рассмотрение позволило увидеть модули нашей системы (UI софта):
— Контролы — рукоятки, за которые дёргает пользователь, взаимодействуя с надсистемой (софт) через нашу систему (UI);
— Компоновка — варианты размещения контролов для их успешного использования. Зависят от навигации, локаций и контекстов;
— Навигация — принципы перемещения между локациями».

«Результат нашего труда — описание. Даже результат труда разработчиков, которые воплощают описанный нами UI, — это описание того, как будет работать система в жизни. Воплощение софта и его UI происходит только в ходе эксплуатации. Справедливости ради, воплощением можно с натяжкой признать все тестовые запуски».

«Мы не конструируем элементы нашей системы: UI-компоненты, навигацию и компоновки. Это делает кто-то другой, а значит, нам надо держать в фокусе работу смежных команд и много коммуницировать».

https://habr.com/ru/company/posttech/blog/567170/

Тэмми Чжоу написала о степпере для ввода числовых данных.

Степпер — контрол из 2 сегментов, нажатие на которые с определённым шагом увеличивает или уменьшает число. Аналоги степперов есть в голосовых интерфейсах, например, команда «Сделай громче/тише».

Плюсы:
— Число можно изменить без клавиатуры, просто кликнув нужное количество раз на один из сегментов степпера. Хороший вариант, если у устройства нет клавиатуры (терминал) или надо избежать ввода нецифровых значений;
— Контролы интуитивно понятны. Для людей, читающих слева направо, контрол увеличения обычно располагают справа от числа или над ним, а уменьшения — слева или под;
— Незначительно изменить число очень легко;
— Хорошо подходит, если пользователю надо просто увеличить или уменьшить значение, а не установить конкретное число. Например, сделать звук погромче или текст покрупнее.

Минусы:
— Контролы обычно довольно мелкие и располагаются слишком близко друг к другу, что неудобно;
— Плохо подходит, если пользователи часто меняют значение по умолчанию, и оно сильно отличается от пользовательских значений.

Рекомендации:
— Значения по умолчанию должны соответствовать тому, что пользователи вводят чаще всего. Например, стоит установить «2» для количества гостей при заказе столика в ресторане;
— Не используйте степпер, если сложно выбрать подходящий шаг. Например, для ввода цен и расстояний;
— Обозначайте чётко, что значением конкретного поля управляет степпер;
— Используйте большие контролы на мобильных и настольных устройствах. Например, на мобильных область нажатия должна быть не менее 1×1 см;
— На мобильных устройствах лучше использовать горизонтальный степпер, на него проще нажимать пальцем;
— Размещайте символы + и − на горизонтальных степперах и стрелки вверх и вниз (шевроны) на вертикальных;
— При необходимости давайте изменить число с помощью текстового поля, поддерживайте нажатие кнопок вверх, вниз, вправо и влево на клавиатуре, а также долгое нажатие на контролы для быстрого и значительного изменения.

[English] https://www.nngroup.com/articles/input-steppers/

Илона Саркисова написала о тупых и умных компонентах.

Графический интерфейс состоит из компонентов (кнопок, полей, текстовых блоков и так далее, а также их сочетаний), которые существуют в контексте: регистрация на сайте авиакомпании, покупка в интернет-магазине одежды. Чтобы показать решение задачи в определённом контексте, дизайнер использует реалистичный контент.

Проблема в том, что контекстуализированные компоненты может быть сложно переиспользовать. Чтобы этого избежать, компоненты можно разделить:

1. Тупые — универсальные кирпичики, не привязанные к бизнес-логике, с рыбой вместо контента и максимальным количеством состояний и элементов;
2. Умные — примеры их применения, привязанные к бизнес-логике, исполняющие определённую функцию в конкретном месте.

UI-кит из тупых компонентов сокращает их количество и облегчает работу над дизайном.

https://habr.com/ru/company/epam_systems/blog/519856/

Владимир Бугаев написал о метафорах вырезания и перемещения в Windows и macOS.

— В macOS, в отличие от Windows, нельзя вырезать папку или файл: сочетание клавиш Command+X не работает, в меню нет пункта «Вырезать»;
— Чтобы их переместить, надо файл или папку скопировать и вставить командой Command+Option+V;
— В реальном мире (и macOS) можно вырезать часть текста или изображения и куда-нибудь вставить, но в реальном мире файлы из папок или папки с рабочих столов не вырезают, а просто перемещают. В macOS метафоры вырезания и перемещения разделены;
— Плюс такого подхода: в момент вставки файла можно решить, копировать его или переместить. То есть пользователь сначала берёт файл со стола и потом решает, что с ним делать. В Windows решать надо в самом начале;
— Минус: конечное действие (перемещение) не соответствует изначальной команде (скопировать).

https://vc.ru/design/264550

Эрик Кеннеди написал о формах регистрации и входа.

— По умолчанию размещайте фокус на первом поле формы, но проверяйте, что это не портит опыт пользователям со скринридерами;
— Отображайте сообщение о неправильной электронной почте сразу после перемещения фокуса на другое поле;
— Переводите фокус на поле после клика на текстовую подпись к этому полю;
— Если это законно в вашей стране, не требуйте поставить флаг в чекбокс согласия с юридическими документами;
— На английском не пишите очень похожие Sign up и Sign in для регистрации и входа, используйте синонимы Register, Create account и Log in;
— В нижней части формы входа ставьте ссылку на регистрацию и наоборот, чтобы пользователь легко мог переключиться;
— Вместе с сообщением о неправильном пароле показывайте требования к нему в вашем продукте;
— После неуспешной попытки входа не очищайте поля с почтой и паролем, чтобы пользователь мог быстро их исправить;
— В форме восстановления пароля по умолчанию заполняйте поле с почтой, если пользователь её вводил в форме входа.

https://ux.pub/15-sovetov-dlya-uluchsheniya-ux-form-registratsii-i-vhoda-v-sistemu/