Как выйти за пределы прямоугольника и перестать абьюзить людей плохими устройствами самообслуживания

Саша Ревяко из студии Райт написал обстоятельную статью с примерами об особенностях проектирования интерфейсов для устройств самообслуживания (УС)

К УС относятся: кассы самообслуживания в супермаркетах, билетоматы, паркоматы, электронная очередь в банках, поликлиниках и на почте, киоски самообслуживания в кафе и банкоматы

Статья полностью: right.by/blog/article/self-service-device

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

#awd_article #awd_ux

Памятка по ошибкам в UX-тестах и как их избежать

Константин Ефимов и Анастасия Жичкина написали руководство об ошибках, которые совершают исследователи на разных этапах проведения UX-тестов

Авторы пишут, как:
— Правильно подготовить сценарии и задания для участников UX-тестов
— Сформулировать вопросы
— Вести себя исследователю во время UX-тестов, чтобы получить объективные ответы
— Понять, что сценарии UX-тестов понятны и выполнимы для участников UX-тестов

Смотрите наглядную схему с примерами: bit.ly/3zEUwSZ

#awd_article #awd_ux

🇬🇧 Что такое закон Эшби и как применить его в UX-дизайне

Деян Благич написал статью о том, как проектировать любые интерфейсы, чтобы пользователь без труда научился ими управлять

Когда человек хранит информацию об интерфейсе в долговременной памяти, он помнит только его общие характеристики, а не все детали. То есть наш мозг стремится к экономии усилий и упрощению. Поэтому, чтобы людям было легче взаимодействовать с интерфейсом, он должен соответствовать их ментальной модели

Эта мысль раскрывает главную идею закона Эшби в контексте UX-дизайна — «сложность интерфейса должна соответствовать ментальной модели человека»

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

Но есть более сложные инструменты, такие как Github, Blender или Photoshop. Они требуют более высокого уровня когнитивной сложности, но при этом могут испугать и оттолкнуть начинающих пользователей своей сложностью

Чтобы решить эту проблему, дизайнеры могут либо упростить сложный интерфейс, либо обучить пользователей, чтобы помочь им освоить инструмент

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

Читайте статью полностью: uxdesign.cc/what-is-ashbys-law-and-how-does-it-relate-to-ux-design-e5a51cdf803

#awd_article #awd_ux

🇬🇧 Почему бизнесу сложно продолжать поддерживать качество продукта при масштабировании

Джордж Киденбург написал, почему трудно сохранять качество цифровых продуктов, если компания растёт. Небольшие, талантливые команды работают лучше благодаря фокусу на продукте, тщательному отбору сотрудников и общей страсти к тому, что они делают

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

Линейным сотрудникам Джордж рекомендует:
— Вместе с командой сформулируйте общие ценности, на которые можно опираться при обсуждении новых идей
— Создавайте вещи, которые раздвигают границы и напоминают людям, что все возможно
— Инвестируйте в отношения с коллегами: узнавайте, что их волнует, и делитесь с ними тем же

А лидерам он советует:
— Если кажется, что вы больше сосредоточены на росте, чем на выполнении отличной работы, возможно, стоит разработать новое видение будущего
— Оценивайте успех не только количественными метриками, но и качественными. Например, в оценки эффективности можно добавить вопрос вроде «насколько сильно вы помогли другим командам в этом проекте?»
— Уделяйте внимание улучшению существующих функций, а не только созданию новых
— Обеспечьте крепкую связь между основной командой, которая занимается разработкой дизайн-системы, и остальными командами
— Разрешить региональным командам принимать решения в масштабах компании

Читайте статью на английском: gk3fyi.substack.com/p/the-cost-of-craft

#awd_article #awd_ux