Меню

+380979398298

Принципы проектирования

  • 23
  • 08
  • 2011

Для проектирования интерфейсов используются не только исследования пользователей, но и принципы проектирования. Я решил собрать несколько принципов в одну статью. Уверен, некоторые из принципов вы уже давно используете.

Бритва Оккама

«Бритва О́ккама» или «лезвие Оккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама. В упрощенном виде он гласит: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без самой крайней на то необходимости»).

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

Принцип KISS

KISS (англ. keep it simple, stupid — «не усложняй, тупица» или англ. keep it short and simple — «не усложняй») — процесс и принцип проектирования, при котором простота системы декларируется в качестве основной цели и/или ценности. Также часто используется более вежливая расшифровка — keep it short and simple («делай короче и проще»).

Чем проще, тем лучше!


Утиный тест

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

Привычные вещи нужно называть привычными именами!


Принцип «YAGNI»

Принцип «YAGNI» (англ. You Ain’t Gonna Need It — «Вам это не понадобится») — процесс и принцип проектирования, при котором в качестве основной цели и/или ценности декларируется отказ от добавления функциональности, в которой нет непосредственной нужды.

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

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

Таким образом, если вы создаете новый продукт, подумайте, действительно ли нужны все функции.


Чем хуже тем лучше!

Чем хуже, тем лучше — подход к разработке программного обеспечения, объявляющий простоту реализации и простоту интерфейса более важными, чем любые другие свойства системы. Этот стиль описан Ричардом П. Гэбриелом (Richard P. Gabriel) в работе «Lisp: Good News, Bad News, How to Win Big» в разделе «The Rise of ‘Worse is Better’» и часто перепечатывается отдельной статьей.

Гэбриел описывает подход так:

  1. Простота: реализация и интерфейс должны быть простыми. Простота реализации даже несколько важнее простоты интерфейса. Простота — самое важное требование при выборе дизайна.
  2. Правильность: дизайн должен быть правильным во всех видимых проявлениях. Простой дизайн немного лучше, чем правильный.
  3. Логичность (последовательность): дизайн не должен быть слишком нелогичным. Иногда можно пожертвовать логичностью ради простоты, но лучше отказаться от тех частей дизайна, которые полезны лишь в редких обстоятельствах, чем усложнить реализацию или пожертвовать логичностью.
  4. Полнота: дизайн должен охватывать как можно больше важных ситуаций. Полнотой можно жертвовать в пользу остальных качеств и обязательно нужно жертвовать, если она мешает простоте. Логичностью можно жертвовать в пользу полноты, если сохраняется простота; особенно бесполезна логичность интерфейса.

Ментальные модели.

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

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

Не могу создать директорию /home/www/usabilist/public_html/wp-content/uploads/2011/08. Проверьте, доступна ли родительская директория для записи (Права доступа должны быть 755, 775 либо 777 в зависимости от настроек вашего сервера).
Виталий

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

Павел

«YAGNI» — улыбнул ) в жизни постоянно с подобным сталкиваюсь

Оставьте комментарий

Ваш e-mail не будет опубликован.