Какие существуют стандарты ui

Стандарты пользовательского интерфейса (UI)

Фотография

Существуют ли в природе некие стандарты пользовательского интерфейса для тестирования оного по неким объективным критериям или при UI-тестировании речь идёт, в основном, о каких-то внутренних концепциях и правилах?

#2 barancev

Отправлено 24 июня 2005 — 07:10

Стандартов нет. Есть рекомендации. См, например, список ссылок здесь: http://forums.softwa. showtopic=2514

Еще у нас была небольшая дискуссия о том, как следует относиться к этим рекомендациям: http://forums.softwa. showtopic=2209

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#3 PavelB

Отправлено 24 июня 2005 — 08:10

Спасибо. Я понял, что моё представление об этом недалеко от истины.
Просто задали вопрос: какими объективными критериями Вы будете руководствоваться при тестировании удобства использования (usability)?
Мне он показался несколько странным, и ничего кроме здравого смысла, собственного и исторического опыта (имеются в виду предыдущие версии программ) придумать не смог.

#4 Spy

Отправлено 24 июня 2005 — 08:13

Языки описания пользовательских интерфейсов
Автор: Дмитрий Шейко, 07 апреля 2005

Данная статья обозревает перспективные концепции декларирования пользовательских интерфейсов для веб-приложений. В ней рассматриваются технологии UIML, XUL, XAML, MXML и Web Applications

#5 Spy

Отправлено 24 июня 2005 — 08:19

Эти стандарты, правда не для тестирования UI, а для их описания. Но как я понимаю, прежде чем тестировать надо бы уметь их описывать ;).

#6 Ekaterina

Pip

Members

52 сообщений

ФИО: Екатерина Андреевна
Город: Санкт-Петербург

Отправлено 24 июня 2005 — 08:48

#7 barancev

Отправлено 24 июня 2005 — 09:21

Просмотр сообщения

Спасибо. Я понял, что моё представление об этом недалеко от истины.
Просто задали вопрос: какими объективными критериями Вы будете руководствоваться при тестировании удобства использования (usability)?
Мне он показался несколько странным, и ничего кроме здравого смысла, собственного и исторического опыта (имеются в виду предыдущие версии программ) придумать не смог.

Вообще говоря, стандарт и объективный критерий — это две большие разницы.

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

Поэтому в качестве объективного критерия вполне могут выступать, скажем, рекомендации компании Microsoft, хотя они и не имеют статуса стандарта.

Проблема, однако же, в том, что usability часто не ограничивается тем, что написано в этих рекомендациях — всё сделано так, что требования выполняются, а пользоваться все равно неудобно 🙂

Я бы посоветовал читать труды Якоба Нильсена, начните с его сайта: http://www.useit.com/

10 главных правил UI-дизайна

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

1. Проектируйте для плотности, а не для пикселей

Рекомендуется проектировать интерфейс не для пикселей, а для плотности дисплея устройства. Под плотностью понимается количество пикселей на один дюйм экрана или PPI. Это обеспечивает правильное масштабирование элементов интерфейса для соответствия размерам устройств.

Поскольку некоторые экраны имеют больше пикселей на дюйм, чем другие, активы не отображаются в меньшем размере на экранах с высокой плотностью пикселей, они просто отображаются в 2x, 3x, 4x масштабе от их первоначального размера. Это гарантирует, что все активы сохранят свои размеры на устройствах с различной плотностью дисплея.

2. Используйте шаг 8dp

Причина проста: если устройство имеет разрешение 1,5x, оно не будет правильно отображать нечетное число. Кроме того, подавляющее большинство современных размеров экрана делится на 8, что упрощает надлежащее выравнивание ваших дизайнов на этих устройствах. При проектировании с шагом 8 на сетке 8-pt дизайны будут выглядеть согласованными.

3. Уберите линии и рамки

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

4. Обращайте внимание на контраст

Использование контраста не только привлекает внимание пользователя к соответствующей информации на странице, но и улучшает доступность продукта. Продукт должен быть инклюзивным для всех – в том числе незрячих, дальтоников и слабовидящих пользователей. Правила доступности веб-контента (WCAG) требуют контрастности не менее 4,5:1. Проверить, соответствует ли продукт этому стандарту, поможет интегрированный набор инструментов Stark.

5. Используйте знакомые пользователям стандарты

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

6. Используйте цветовой вес, чтобы установить иерархию

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

7. Старайтесь не использовать больше двух шрифтов

Общепринятой практикой проектирования является ограничение количества шрифтов, используемых в интерфейсе – в большинстве случаев ограничиваются двумя. Без веских причин от этого правила лучше не отступать. В случае необходимости можно использовать семейства шрифтов. При выборе шрифта полезными будут семейства, которые имеют различные веса (light, regular, medium, bold, extra bold). Это даст больше возможностей для изучения различных стилей без добавления дополнительных шрифтов.

8. Узнавать знакомое, а не пытаться вспомнить

Узнавание – это хорошая практика в продуктовом дизайне, потому что позволяет пользователю лишний раз не задумываться о своих действиях. Примеры – страницы оформления заказа, почтовые ящики, история поиска, кнопки «Назад» и т. д..

9. Не замедляйте меня

Для пользователя скорость и эффективность – единственное, что имеет значение. Хорошее эмпирическое правило, касающееся в основном анимаций и микровзаимодействий, заключается в следующем: если что-то добавляет ненужное время, то это не улучшает опыт.

10. Меньше значит больше

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

Тестирование UI (пользовательского интерфейса)

Можно вложить деньги в новый проект, запустить его, но вопреки ожиданиям получить негативные отзывы и спад продаж. Такие ситуации случаются, если разработчик пропускает важный этап ー UI-тестирование.

UI тестирование

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

Тестирование пользовательского интерфейса

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

пользовательский интерфейс

При проведении теста интерфейса мы имитируем действия пользователя приложения. Задача такого тестирования ー убедиться, что все компоненты системы правильно взаимодействуют друг с другом.

UI ー это User Interface, в переводе с английского «пользовательский интерфейс»

Целесообразно проводить UI-тестирование на начальном этапе разработки мобильного приложения, на этапе прототипа. Одновременно с тестированием интерфейса мы проводим и ux-тестирование, то есть определяем, как человек себя чувствует при взаимодействии с системой. Но в этой статье мы расскажем именно о проверке пользовательского интерфейса.

UI-тестирование. Зачем нужно тестирование прототипа

Тестирование прототипов помогает сэкономить время и деньги, а также увеличить надежность приложения. Внести изменения в приложение на этапе прототипирования значительно дешевле, чем тогда, когда продукт отрисован, сверстан и запрограммирован. Особенно если прототип существует пока только на бумаге.

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

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

Тестирование прототипа могут проводить сотрудники компании-разработчика мобильных приложений. Главное, чтобы это были не те люди, которые задействованы в проекте.

Тестировать можно как статичные (бумажные), так и интерактивные прототипы. В каждом случае у UI-тестирования разные задачи.

Тестирование бумажных прототипов

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

тестирование бумажного прототипа

Плюсы работы с бумажными прототипами

Главный плюс ー экономия времени. Нарисовать бумажный прототип можно за пару часов, тогда как на создание интерактивного прототипа уйдет пару дней.
Если во время тестирования разработчик понимает, что что-то работает не так, как надо, все можно быстро исправить с помощью бумаги и ручки.

Пример тестирования пользовательского бумажного интерфейса:

На бумаге создается дизайн мобильного приложения. Один из разработчиков, хорошо знающий макет, выступает в роли компьютера. Он выкладывает листы с макетом возле тестируемого. Как только пользователь кликает по бумажному “экрану”, “компьютер” выводит ему нужную страницу.
“Компьютер” оповещает пользователя, когда закончена операция. В качестве сигнала можно использовать определенный жест или распечатанную иконку.
Человек, который проводит тестирование, не комментирует свои действия и дизайн тестируемому.

пользовательский интерфейс

бумажный интерфейс

Несмотря на то, что тестирование бумажного прототипа проще и дешевле, мы в компании Woxapp в основном тестируем интерактивные прототипы. Это точные прототипы, большинство элементов на которых кликабельны. Использование интерактивных прототипов снижает вероятность ошибок, так как нет необходимости имитировать работу системы, как это приходится делать при тестировании неточных бумажных прототипов. Поэтому мы получаем высокий отклик.

UI специалист

Ui-тестирование интерактивного прототипа

Такие тесты подходят для того, чтобы опробовать простую логику и выявить ожидания пользователей. Но здесь тоже возникают сложности: в 8 случаях из 10 респонденты затрудняются, и им все время приходится напоминать о том, что они работают всего лишь с прототипом.

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

При создании интерфейса стараемся учитываем принципы юзабилити в мобильном приложении.
После создания UI делаем интерактивный прототип основных сценариев в приложении или тех сценариев, которые вызывают сомнение. Для этого используем Marvel или InVision.
В качестве “подопытных” привлекаем сотрудников компании, тех, кто не связан с разработкой приложения: проджект-менеджеров, бухгалтера, разработчиков c других проектов.
Когда тестируем весь прототип, не комментируем действия пользователя. В начале эксперимента мы рассказываем пользователю о продукте, а дальше молча наблюдаем за тем, как человек изучает и «ходит» в приложении.
Когда тестируем часть дизайна или какой-то сценарий, просим пользователя совершить определенное действие. А дальше наблюдаем и записываем, как он это делает.

В итоге получаем результаты действий реальных пользователей. На основе полученных результатов делаем выводы и при необходимости внедряем изменения в дизайн.

тестирование пользовательского интерфейса

Всегда ли необходимо проводить ui- тестирование

Тестирование пользовательского интерфейса имеет смысл лишь для больших приложений. Поэтому прежде чем решить, какие тесты проводить, мы определяемся с размером приложения. Для краткосрочных или небольших программ ограничиваемся Unit-тестом (проверяем, чтобы сервисы и компоненты работали и выполняли свои задачи) и E2E тестом (этот тест похож на UI, но его проводят с реальными сервисами).

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

тестирование пользовательского интерфейса

Заключение

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

Исправить ошибки в уже выпущенном приложении дороже, чем на этапе прототипирования.

В некоторых случаях можно обойтись тестированием бумажных прототипов. Но мы чаще всего тестируем интерактивные прототипы ー так можно получить более точные результаты.

Во время тестирования важно не комментировать действия пользователя. Можно только наблюдать за ходом тестов и записывать. UI-тестирование имеет смысл проводить лишь для больших приложений. Для краткосрочных приложений можно ограничиться ux и E2E тестами. Но выпускать на рынок непротестированные приложения нельзя.

10 золотых правил UI дизайна

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

1. Проектируйте для плотности, а не для пикселей

Значения пикселей в 3 или 4 раза больше значений dp (независимые от плотности экрана пиксели) Если вы не знаете, плотность – это количество пикселей на один дюйм экрана или PPI. Единица измерения «dp» – это сокращение от выражения «независимый от плотности экрана пиксель», иногда можно встретить сокращение «dip». Рекомендуется проектировать интерфейс не для пикселей, а для плотности дисплея устройства. Это обеспечивает правильное масштабирование элементов интерфейса для соответствия размерам устройств. Причина, по которой мы это делаем, заключается в том, что, если мы создадим актив кнопки, например, с разрешением 200 x 50 dp, он будет отображаться 200 x 50 px на экране 160 ppi и 400 x 100 пикселей на экране 320 ppi (в 2 раза больше первоначального размера актива). Поскольку некоторые экраны имеют больше пикселей на дюйм, чем другие, активы не отображаются в меньшем размере на экранах с высокой плотностью пикселей, они просто отображаются в 2x, 3x, 4x масштабе от их первоначального размера. Это гарантирует, что все активы сохранят свои размеры на устройствах с различной плотностью дисплея. Например, размеры экрана iPhone XS Max составляют 414 x 896. Но это не пиксели, а количество точек. В пикселях это 1242 x 2688 px. Учитывая это, при проектировании для iPhone XS Max я бы выбрал размер 414 x 896 точек, а затем масштабировал активы в @ 3x.