Pull to refresh

Качественный интерфейс по Майкрософтовски

Reading time 6 min
Views 966
Original author: MSDN
Вот, перевёл, адаптировал и дополнил для наших разработчиков и тестировщиков статью из MSDN, про дизайн качественных интерфейсов. Может оказаться полезным для всех тех, кто занимается разработкой чего-угодно, т.к. в статье перечислены основные руководящие принципы, применимые для любых систем.

Насколько программа хороша, по мнению пользователей? Насколько она полезна, удовлетворяет ли она нужды и чаяния пользователей? Самый простой способ узнать это — спросить. Но что делать, когда программа ещё не готова, а уверенности в том, что она будет соответствовать ожиданиям пользователей уже нет? Ответ очень прост: нужно спросить у тех, кто уже делал что-то подобное, ошибался, исправлял свои ошибки и учился на них. В нашем случае — это компания Microsoft. Ниже изложены основные руководящие принципы создания программного обеспечения, которое будет отвечать требованиям самых взыскательных пользователей.

Базовые сценарии.

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

Взаимодействие, а не функции.

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

Выделяться!

Подумайте о том, что настоящие пользователи — не сотрудники отдела маркетинга или продаж — сказали бы о вашей программе. Как бы они её описали? Вы должны знать, для кого вы делаете программу. И должны быть уверены в том, что они могут сказать: «Люблю эту софтину! Она очень круто делает и то, и это, и ещё вот это». Если пользователи не могут этого сказать, тогда зачем вообще всё? Сегодня «нормально» — уже не нормально, а плохо. Вы сами должны любить свой софт.

Не нужно делать всё для всех.

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

Принимать ответственные решения

Нам действительно нужна эта функция, или команда, или настройка? Если нужна — делаем. Если нет — режем, без сомнений и жалости. Нельзя откладывать сложные решения делая всё «настраиваемым».

Взаимодействие, как беседа.

Представьте себе, что интерфейс программы — это беседа между вами и вашими пользователями. Представьте, что вы заглядываете пользователю через плечо, а он спрашивает: «Что я тут делаю?». Что вы ему ответите? Действия, их порядок, слова, которые вы используете, и то, как вы будете объяснять. Подумайте о том, чего бы вы не сказали. Таким должен быть интерфейс — беседой друзей. Лучше так, чем говорить загадками, которые пользователь должен разгадать.

Делать правильно.

Скорее всего в программе найдётся порядком настроек, которые позволят пользователям что-то изменить. Но зачем? Выберите самые надёжные, безопасные и удобные значения в качестве изначальных. А первое взаимодействие должно полностью удовлетворять основную аудиторию. И не думайте, что, в случае неудачных изначальных настроек, они перенастроят всё под себя. Они не будут.

Пусть она просто работает.

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

Поосторожнее с вопросами.

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

Хорошо работать.

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

Хорошо выглядеть.

Используйте стандартный вид программ для Windows. Стандартные окна, шрифты, цвета и элементы управления. Модификации элементов интерфейса должны быть минимальными. Используйте стандартные пиктограммы, графику и анимацию, когда это возможно (и законно!). Всё это — проверенный, надёжный вариант.

Отзывчивость.

Отзывчивость, то есть способность реагировать — ключевая сущность взаимодействия, в принципе. Если программа слишком медленная или неотзывчивая, пользователи посчитают её непригодной.

Простота.

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

Неудачное взаимодействие.

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

Распространённые проблемы.

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

Назойливость.

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

Напряжение, эрудиция, мыслительный процесс.

Ничего этого нельзя постоянно требовать от пользователей программы.
  • Прозрачность, а не намёк — То, что необходимо пользователю, должно быть на экране. Поэтому так важно тщательно составлять инструкции для пользователей, в окнах и на страницах. Чтобы чётко донести суть и назначение интерфейса.
  • Автоматически, а не вручную — Старайтесь помогать пользователям автоматизируя процессы, которые могли бы быть автоматизируемы, и которые пользователь хотел-бы автоматизировать. Простой тест: Закройте программу, а затем снова откройте и выполните в ней самую базовую задачу. Сколько ручных действий вы могли бы убрать?
  • Кратко, а не многословно — Пишите ёмко. Формулируйте точно. Текст оформляйте для считывания, а не для внимательного чтения. Для полезной, важной, но не основной информации используйте ссылки на Справочные разделы.
  • Специально, а не случайно — Лучший элемент управления — который вынуждает вводить правильные значения.
  • Включено, а не выключено — Выключенные элементы управления смущают. Использование их допустимо только в тех случаях, когда пользователю не составит труда догадаться, почему они выключены. В противном случае убирайте их или оставляйте включенными, но с каким-нибудь адекватным откликом.
  • Запомненное, а не забытое — За исключением ситуаций, когда речь идёт о безопасности или персональных данных, лучше запоминать предыдущие действия пользователей и ранее введённые значения полей форм, и помогать им повторять некоторые операции, нежели раз за разом заставлять их начинать с начала.
  • Отклик, а не игнорирование — Однозначно показывайте, когда задача выполнена, и когда нет. Не заставляйте пользователей гадать.


Нормативы Windows

Следуйте нормативам! Чтобы хотя-бы отчасти соответствовать стандартам качества, принятым для программ под Windows; чтобы внедрить общепринятые методы и практики; чтобы упростить принятие решений и вообще, чтобы сделать вашу работу легче. Сфокусируйте вашу творческую энергию на действительно важных вещах, а не на рутине. (Вне зависимости от того, что за программу вы делаете) Не создавайте безумных программ, которые никто не может заставить работать. Следуйте нормативам, чтобы сделать вашу программу стандартной в использовании, но выдающейся в работе.

Исследования

Исследуйте интерфейс. Вы не узнаете о том, насколько всё пошло хорошо, до тех пор, пока не увидите, как ваши настоящие пользователи работают с программой. Вероятнее всего полученные результаты вас (неприятно) удивят. Однако воспринимайте критику с радостью — она поможет достичь лучших результатов. Также непременно собирайте отзывы о программе после того, как она увидит свет.
Tags:
Hubs:
-9
Comments 24
Comments Comments 24

Articles