UX Notes

Анастасия Брыкова написала о культурных особенностях в дизайне интерфейсов.

— Недостаточно перевести текст на разные языки. Пользователи хотят, чтобы продукт учитывал их культурные особенности и методы ведения бизнеса;
— В разных культурах могут меняться значения цветов;
— Одно сообщение на разных языках может быть разной длины и отличаться направлением письма (справа налево и даже сверху вниз);
— Иероглифических шрифтов намного меньше, что сокращает возможности по оформлению текста с иероглифами;
— Отличаются единицы измерения, валюты, форматы отображения дат, чисел и цен;
— Может отличаться восприятие отдельных символов: знак «Окей» во Франции и Турции, «Палец вниз» в Японии;
— В японских интерфейсах обычно избыточно яркая цветовая гамма и много иллюстраций. Китай схож с Японией, но медленно перенимает европейский минимализм. В Южной Америке используют декоративные шрифты и сочетания ярких цветов.

Ещё о локализации недавно писали в GTE Localize.

Люси Скотт написала, как упростить интерфейс для людей в стрессе.

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

Кейт Доулер поразмышляла, когда усложнение взаимодействия улучшает пользовательский опыт.

— Препятствие помогает замедлить пользователя, чтобы он успел включить голову. Пример: необходимость подтвердить действие;
— Также оно помогает изменить поведение. Пример: долгое ожидание лифта побуждает людей пользоваться лестницей. Но от таких манипуляций один шаг до тёмных паттернов;
— Вкладывая больше сил, люди больше ценят результат (эффект Ikea). Пример: разнашивание новых Dr. Martens (приносящее боль) включено в руководство пользователя;
— В определённых ситуациях человек может получать удовольствие от совмещения позитивных и негативных ощущений. Примеры: просмотр фильма ужасов; поедание острой пищи и знание, что жжение рано или поздно закончится;
— Попробуйте в рамках обратного мозгового штурма спроектировать плохое решение и посмотреть, какие идеи появятся.

Николай Романов написал, как выстроить лендинг, чтобы его прокручивали до конца.

— Не обманывайте ожиданий: не лейте воду и не меняйте тему;
— Анимацию перехода от одной информации к другой синхронизируйте с прокруткой страницы. Так пользователь будет чувствовать контроль;
— Меняйте ритм повествования. Например, блоком с крупным текстом можно разбавить блоки с заголовками, текстом и картинками;
— Кроме прокрутки предлагайте другие способы взаимодействия: нажать или навести курсор, чтобы узнать детали. Но важно не переборщить: не больше 2–3 механик для лендинга до 20 экранов;
— Иногда лучше немного анимировать статичные картинки, чтобы они привлекали внимание.

Наталья Стурза написала о чек-листе проектирования, который помогает не упускать детали, создавая сложные продукты.

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

Александр Ревенок написал о таком методе исследования как Fake door.

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

Эдвард Чечик написал о панелях свойств (боковых панелях), которые часто можно встретить в профессиональных продуктах.

— Вкладки в верхней части панели позволяют разделить её на отдельные секции;
— Панели часто делятся на блоки — группы свойств, которые пользователь может скрывать и раскрывать;
— Обычно редактируемый объект меняется сразу после изменения его свойств на панели, но если изменение требует времени — после нажатия на кнопку подтверждения;
— Также отдельные кнопки обычно используют для загрузки файлов и экспорта;
— Часто ползунки сопровождаются числовыми полями;
— Некоторые числовые поля позволяют менять единицы измерения;
— Многие особенности панели свойств обусловлены необходимостью экономить место: частое использование раскрывающихся списков (вместо групп радиокнопок), модальные окна с дополнительными возможностями, расположение подписей к полям сбоку (расположение сверху увеличивает скорость заполнения всей формы, но на панели свойств этого не требуется), частое использование сегментированного переключателя (segmented control) с иконками;
— Иногда подписи располагаются под полями, состоят из одной буквы или иконки;
— При неправильном заполнении поля приложение не отображает сообщение об ошибке и может удалить некорректный ввод. Ожидается, что пользователь профессионального продукта знает, какие значения вводить;
— Визуализируйте редактируемые свойства. Пример: блок Constraints в Фигме;
— Дайте скрыть и показать панель свойств, если пользователю потребуется больше места на экране.

In English.

В «Собаке Павловой» написали о подготовке макетов профессиональных интерфейсов к тестированию.

— Их пользователи чаще сталкиваются с ситуациями, для которых нет чёткого сценария;
— Такие интерфейсы могут включать векторы взаимодействия: 1) Педагогический (новичок ищет подсказки в интерфейсе); 2) Непосредственный (опытный пользователь работает без подсказок, знает популярные идиомы); 3) Невидимый (эксперт использует шорткаты);
— Они ориентированы на специалистов, знакомых с терминами и неочевидными идиомами, проходящих обучение;
— На макетах проблематично тестировать 3-й вектор взаимодействия, но он есть не во всех профессиональных продуктах;
— Если респондент не справился с задачей, это не всегда ошибка проектирования. Заказчик интерфейса может планировать изменение текущего процесса и рассчитывать на дальнейшее обучение;
— Соберите макеты в прототипы, в которых можно протестировать отдельные сценарии и ситуации. Вместить все ситуации в один прототип не получится;
— Одно задание — один рабочий процесс или ситуация;
— Все элементы, относящиеся к сценарию, должны быть интерактивны. Если пользователь нажал на неактивный элемент, можно обсудить, почему он это сделал;
— В прототипе можно выделить несколько основных процессов, но охватить всё многообразие возможностей не получится. Отчасти помогут Framer, Axure и Anima, но тестирование профессиональных продуктов на этапе макетов всегда немного условно.

Александра Савельева написала об уровнях развития цифрового продукта (о них писал также Аарон Уолтер в книге «Эмоциональный веб-дизайн»).

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

Егор Камелев и Эдвард Чечик написали (отдельно друг от друга) о проектировании тултипов. О всплывающих подсказках недавно было, так что эта заметка дополнит и на какое-то время закроет тему.

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

Сэм Айронс написал о дизайн-долге — дизайнерском аналоге технического долга: как классифицировать, измерить и погасить.

— Это накопленные проблемы с дизайном, решение которых отложили на потом;
— Варианты разумного дизайн-долга: а) Преднамеренный: команда понимает, что дизайн не очень, но решает его реализовать и планирует доработки на следующие итерации; б) Непреднамеренный: команда реализует хороший дизайн, но со временем он перестаёт быть таковым, так как меняются обстоятельства;
— Безрассудный преднамеренный дизайн-долг отличается от разумного тем, что команда делает «быстро и грязно», не оценивая трудозатраты на доработки и не планируя их (хакатоны, инновационные спринты);
— Безрассудный непреднамеренный дизайн-долг появляется из-за некомпетентности и отсутствия опыта;
— Кто создаёт продукт, тот и должен его обслуживать, в том числе устранять дизайн-долг;
— Время на обслуживание надо закладывать в план. В Atlassian на это уходит четверть рабочего времени;
— Можно выявлять отдельные баги в UI (неправильный отступ, опечатка) или UX (проблема с сообщением об ошибке, стандартное пустое состояние);
— Можно искать способы: а) Снизить сложность сценария, уменьшив количество ответвлений или пользовательских действий, необходимых для его прохождения; б) Уменьшить количество отдельных сценариев, которые надо последовательно пройти в продукте для достижения цели; в) Упростить концептуальную модель, сократив количество сущностей и связей между ними;
— Появление дизайн-долга можно предотвращать, внедряя лучшие практики вроде проведения исследований, поиска нескольких решений, вовлечения клиентов в процесс, сквозного тестирования существующих продуктов, анализа клиентских отзывов и так далее;
— Возвращайтесь к компромиссным решениям и планируйте их доработки. Принимая такие решения, старайтесь сразу включать доработки в план;
— Сделайте дизайн-долг прозрачным: ведите бэклог, измеряйте его размер;
— Зафиксируйте обязательства по регулярному погашению долга;
— Стандартизируйте процедуры выявления и погашения долга (Брейден Ковиц упоминал день исправления UI-багов).

#design_debt

Владимир Белов написал о тултипах (всплывающих подсказках).

— Тултипы помогают обучать пользователей и объяснять интерфейс;
— Тултип отображается при наведении курсора на элемент интерфейса. Если рядом находятся несколько элементов с тултипами, отображайте его, когда пользователь задерживает курсор на одном из элементов;
— Их стоит использовать с кнопками без текста, так как метафоры иконок могут быть непонятными;
— В них можно показывать сочетания клавиш для взаимодействия с элементами интерфейса, требования к вводимому паролю, дополнительную информацию (но только если она не занимает половину экрана);
— Также — полный текст, который в интерфейсе отображается сокращённым (например, слишком длинное слово в узкой ячейке таблицы);
— С их помощью можно объяснять, почему кнопка у пользователя заблокирована;
— Чтобы появление тултипа было приятным, достаточно стандартного transition 0.3s;
— Чтобы добавить подсказку к тексту, на который пользователи редко наводят курсор, можно рядом разместить иконку (i) или (?) с тултипом. Например, так можно пояснить подпись к полю, включающую незнакомый термин.

Ещё о тултипах писал Викалп Кошик.

Гонсалу Диас написал, почему надо отказаться от бесконечного скрола.

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

Bang Bang Education опубликовали киноальманах «Лепота» на Ютубе — бесплатно и без регистрации.

3:00 Fuckyou Digital
5:27 CLAN
8:30 Алексей Ивановский
11:05 Оля Панькова, Владимир Шипилов
13:40 Дима Корниенко, Ваня Корниенко
16:50 Макси Шилов
19:40 Алена Лебедева
21:35 Регина Турбина
23:30 Ждан Филиппов
25:45 Владислав Деревянных и «Восход»
28:50 Вова Аюев
32:00 Денис Башев
34:25 Роман Ерохнович
37:00 Mishka Luganski
39:20 Олег Пащенко
41:50 Сергей Гуров
45:35 Electric Red
48:15 Holystick
51:00 Саша Ермоленко
54:00 Александр Загорский
56:50 Антон Горбунов
59:35 Дима Родионов
1:02:00 Sila Sveta
1:04:35 Just Be Nice
1:07:15 Александр Сметанка
1:09:10 Кирилл Глущенко
1:13:00 Жи-Ши
1:15:45 Татьяна Егошина
1:17:50 Сергей Серов, Катерина Терехова
1:20:10 White Russian Studio
1:23:15 ONY
1:25:30 Андрей Зубрилов
1:28:10 Анатолий Беликов
1:32:45 MAGIC CAMP
1:35:20 Антон Шнайдер
1:37:40 Александр Васин и группа «Ижица» (есть отдельное видео)

Станислав Хрусталёв собрал чеклист, как использовать QR-коды для создания позитивного клиентского опыта. Вот часть рекомендаций:

— Если это возможно и уместно, QR-коды использовать стоит, значительная часть людей к технологии готова;
— Сопровождайте код пояснением: что клиент должен сделать и что получит взамен. Также можно уточнить, что для считывания кода надо навести на него камеру телефона (или использовать специальное приложение, как в Ашане);
— Размещайте в QR-кодах лого компании, с брендированием они выглядят профессиональнее;
— Если код будет на офлайновом носителе, при выборе размера учитывайте дистанцию, с которой его будут считывать;
— Размещайте коды на поверхностях, с которыми клиенты не контактируют. Поверхность может начать стираться, и код перестанет работать;
— Убедитесь, что в месте его размещения хороший мобильный интернет или есть вайфай, иначе полезность такого кода устремится к нулю;
— QR-код на десктопной версии сайта может вести на мобильное приложение компании, чтобы пользователь мог легко зайти в магазин приложений со своего телефона (используйте deep linking). Такой же код на мобильной версии сайта вызывает вопросы;
— Чтобы у клиента не рябило в глазах, не размещайте рядом несколько разных кодов для разных целевых действий. Сделайте один код, за которым будет страница с меню из нескольких действий;
— Проверяйте, что целевая страница оптимизирована для просмотра на телефонах.

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

— Иногда о создании дизайн-системы задумываются просто из-за моды;
— Сначала соберите в один документ компоненты и стили, которые давно используются в вашем продукте и доказали свою нужность и универсальность. Может оказаться, что это всего несколько кнопок, иконок, стилей текста и один попап;
— Детально проработайте их поведение (с длинным текстом, в тёмном режиме, на маленьком экране). Вместе с разработчиками внедрите везде их эталонную реализацию;
— Если после этого перекрашивание кнопок и замена шрифта во всём продукте занимает больше минуты, к следующему шагу переходить рано;
— Развивайте библиотеку, постепенно переводя продукт с несистемных компонентов на системные. В одном месте есть кнопка с иконкой — добавьте иконки в библиотечные кнопки, тестируйте, внедряйте;
— Заниматься развитием библиотеки самой по себе неэффективно. Развивайте её вместе с продуктом, когда строите в нём что-то новое;
— Может оказаться, что до каких‑то частей продукта систематизация не дойдёт ещё несколько лет. Значит вы просто их не трогаете, потому что они не важные.

Александра Савельева написала для начинающих статью о метриках.

— Метрики дают фактические знания, помогают более осознанно развивать продукт и трезво оценивать эффективность работы дизайнера. Цифры — отличный аргумент в споре;
— Считать их нет смысла, если продуктом пользуется 100 человек, так как каждый такой пользователь сильно влияет на показатели;
— Большое количество «Пользователей в день» или «Заказов в день» не всегда означает успех. Поток новых пользователей может быть вызван рекламой;
— Метрики можно разделить на а) метрики бизнеса (количество пользователей и заказов в день, выручка), которые зависят от сезона, инфляции, мировых трендов и рекламы, б) метрики продукта, которые обычно измеряются в процентах и не зависят от количества пользователей;
— Пример типичной продуктовой метрики — конверсия с одной страницы на другую. Важно знать её для всех магистральных сценариев;
— Важная продуктовая метрика — retention — показывает, какой процент пользователей возвращается в течение выбранного периода времени;
— Выбор периода зависит от продукта. В приложении для знакомств важен ретеншн в короткие периоды, в сервисе для путешествий — от месяца до года, так как большинство путешествует не каждую неделю;
— Дизайнеру лучше ориентироваться на метрики продукта. Выручка и количество пользователей зависят не только от его работы.

Татьяна Чернявская написала о взаимной супервизии.

— Она позволяет развиваться, когда не помогают обычные практики вроде общения с более опытными коллегами, чтения книг и статей, посещения конференций. Обычно с этим сталкиваются синьоры и лиды, но практика может пригодиться и мидлам;
— Подходит специалистам в разных областях. Например, Татьяна занимается UX-исследованиями;
— Суть взаимной супервизии в том, что два профессионала изучают проекты друг друга и обмениваются обратной связью. От супервизии, практикуемой в психотерапии, отличается тем, что процесс двусторонний;
— Не используется для оценки профессионального уровня участников;
— Помогает получить свежий взгляд на свою работу и найти в чужой практике приёмы, которые захочется взять на вооружение, увидеть знакомые процессы в новом свете, прокачать профессиональную насмотренность, лучше понять применяемые в компании методологии, а также сплотиться с коллегами;
— Проще всего проводить внутри компании (из-за NDA);
— Специалисты должны быть примерно одного уровня, это не наставничество;
— Им должно быть комфортно общаться друг с другом;
— Чтобы получить больше инсайтов, для супервизии лучше выбрать самый сложный, а не лучший из реализованных проектов (задачу);
— Стоит учитывать, что полный цикл супервизии может занять 4–5 часов;
— Оптимально проводить её не чаще раза в квартал, желательно выбирать разные проекты и менять напарников;
— В самом начале супервизии надо выбрать проекты и обговорить, почему выбраны именно они, на что смотреть в ходе супервизии и в каком формате давать обратную связь, чтобы всем было комфортно;
— Изучая проект напарника, стоит отметить его сильные стороны, что получилось хорошо, какие были допущены ошибки, а также приёмы, которые хотелось бы взять на вооружение;
— Затем надо провести встречу и обменяться обратной связью. По предварительной договорённости инсайтами и полученными знаниями (или их частью) можно поделиться с командой;
— Татьяна проводит личную ретроспективу, но благодаря взаимной супервизии увидела недостатки, которые не замечала за собой и которым не придавала значения.

Джаскаран Сингх написал о расположении кнопок «Ок» и «Отмена» в диалоговом окне.

— Плюсы «Ок — Отмена»: логический порядок расположения вариантов (сначала основное, затем дополнительное) совпадает с порядком чтения, если человек читает слева направо; с помощью клавиатуры можно быстрее перейти к кнопке «Ок», которая нужна пользователям чаще;
— Плюсы «Отмена — Ок»: основная кнопка находится там же, где заканчивается движение пользовательского взгляда; «Отмена» возвращает пользователя назад, а «Ок» перемещает дальше, поэтому такое расположение кнопок соответствует логике отображения прошлого слева, а будущего справа;
— Несмотря на плюсы разных вариантов, надо придерживаться стандартов платформы: в Windows «Ок — Отмена», в интерфейсах Apple «Отмена — Ок»;
— Если у вас веб-приложение, узнайте или (если статистики нет) предположите, какая платформа у большинства ваших пользователей;
— Придерживайтесь выбранного порядка расположения кнопок во всех интерфейсах своего продукта.

#layout #button #popup