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

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'" і часто передруковується окремою статтею.

Гебрієл описує підхід так:

Простота : реалізація та інтерфейс мають бути простими. Простота реалізації навіть дещо важливіша за простоту інтерфейсу. Простота – найважливіша вимога при виборі дизайну.
Правильність : дизайн має бути правильним у всіх видимих проявах. Простий дизайн трохи кращий, ніж правильний.
Логічність (послідовність): дизайн не повинен бути надто нелогічним. Іноді можна пожертвувати логічністю заради простоти, але краще відмовитися від тих частин дизайну, які корисні лише в окремих випадках, ніж ускладнити реалізацію або пожертвувати логічністю.
Повнота : дизайн повинен охоплювати якнайбільше важливих ситуацій. Повнотою можна жертвувати на користь інших якостей і обов'язково потрібно жертвувати, якщо вона заважає простоті. Логічністю можна жертвувати на користь повноти, якщо зберігається простота; особливо марна логічність інтерфейсу.

Ментальні моделі.

Ментальною моделлю у психології називають важко формализуемую сукупність емпіричних знань, яка формується у свідомості людини при взаємодії з об'єктом. Простіше кажучи, це те, як ми уявляємо собі певний предмет. У випадку з високотехнологічними пристроями, або інформаційними об'єктами, до яких належать, перш за все, програмне забезпечення, у таке уявлення входить наше розуміння принципів дії системи. Так чи інакше, але працюючи зі складним інтерфейсом, ми мимоволі запам'ятовуємо, що він працює «приблизно так». Не завжди це уявлення відповідає дійсності.

Насправді користувач не знає, як написаний код того чи іншого модуля програми або як влаштована адмінка. Користувачеві потрібно вирішити свої завдання, оскільки він це розуміє. Якщо у нього не вийде, він просто знайде інший інструмент. Якщо ви не знаєте як люди використовують ваш продукт не зможете зрозуміти, що їм потрібно, не зможете його поліпшити.