Статьи

10 принципов дизайна для разработчиков

Я постараюсь объяснить 10 дизайнерских эвристик Якоба Нильсена. Я буду использовать примеры, которые близки вам, как разработчикам, чтобы создаваемый вами продукт получился более практичным.

Почему это должно меня беспокоить?

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

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

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

«Dollars And Sense: The Business Case For Investing In UI Design» В порыве сделать больше функций в электронных устройствах, компании часто теряют из виду ключевой ингредиент... www.fastcodesign.com

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

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

**Как и дизайнерам, программистам нравится применять творческий подход для решения сложных проблем. Я бы предпочел, чтобы о приведенном ниже списке вы думали, как об общем направлении в проектировании, но не как о наборе строгих правил, звучащих как «это лучший способ сделать Х».

Дизайнерские эвристики. Эй, что?

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

Когда у нас есть 3-5 юзабилити-экспертов, которые оценят наш продукт и определят его соответствие «10 принципам дизайна», это, упрощенно, и есть эвристика.

Итак, давайте начнем.

1. Видимость состояния системы

Вы когда-нибудь загружали изображение на веб-страницу? Может быть аватар в социальной сети?

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

Wix медиа-менеджер

2. Соответствие между системой и реальным миром

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

3. Контроль и свобода пользователя

Система должна давать вам возможность исследовать ее содержание и иметь возможность исправить ошибку, если вы ее допустите.

Поддерживайте возможность отмены и повтора.

4. Последовательность и стандарты

У Apple и Microsoft разные представления об очередности следования кнопок «Ok» и «Отмена». Какой же из вариантов лучше?

 

Что лучше?

Может ни один из них? А может оба? Да это и не важно. Что *действительно* важно, так это то, чтобы вы были уверены, что весь процесс взаимодействия с системой будет предсказуем для пользователя.

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

5. Предотвращение ошибок

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

«Когда мы начали производство на нашей фабрике, у нас были люди, отвечающие за QA (quality assurance, обеспечение качества), которые пытались найти недостатки в нашей продукции. Мы же вывели их всех прямо на линию производства, чтобы они объяснили персоналу, как изготавливать продукцию без дефектов. Вы будете удивлены тем, насколько успешнее идет дело, если вы предотвращаете дефекты на стадии производства, а не занимаетесь их поиском впоследствии.» — Mary Poppendieck

6. Распознавание вместо вспоминания

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

CLI (Command Line Interface, интерфейс командной строки) — это прекрасный пример полного пренебрежения этим принципом, и, тем самым, элегантной его демонстрации (все недостатки восполняет «Гибкость и эффективность», см. далее).

7. Гибкость и эффективность использования

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

CLI показывает, насколько мощным может быть такой «скрытый интерфейс» (который мы можем даже расширить).

8. Простота

Изначально этот принцип был назван «Эстетичный и минималистичный дизайн». Он подразумевает улучшение соотношения сигнала и шума.

Каждый бит данных, который вы отдаете вашим пользователям, будет конкурировать в рамках некоторых ограничений, будь то раздутый http-запрос, который занимает пропускную способность, API-интерфейс, наполненный хламом (ненужным контентом) или интерфейс, который имеет слишком много кнопок призыва к действиям.

Постарайтесь получить максимальный выход с минимальными вложениями.

9. Помощь пользователям в распознавании, диагностике и исправлении ошибок

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

Например:

«The 4 H’s of Writing Error Messages» Ерунда случается. Ошибки я имею в виду. Они случаются на наших сайтах и в реальной жизни. Иногда они... uxmas.com

10. Помощь и документация

Я, так же, как и вы, был очень удивлен, увидев это в списке принципов дизайна.

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

Заключение

Я надеюсь, что это было полезно. Если у вас есть какие-либо вопросы или замечания, пожалуйста, свяжитесь с @NirBenita.