Процедурної ми будемо називати людино-машинну систему, доступну людині у вигляді набору функцій (процедур) Наприклад, людино-телевізор - повністю процедурна система: всі завдання, які ставить перед нею людина, описуються в термінах "програма", "гучність", "контраст " і т.п.
Щоб користувач міг хоча б частково планувати і прогнозувати поведінку системи, він повинен знати, як вона влаштована і як працює. А оскільки влаштована система непросто, доводиться винаходити спрощену і не відповідає дійсності її архітектуру, зате описану в зрозумілих користувачеві термінах. Так виникає ще один спосіб взаємодії з процедурної системою: за допомогою легенди. Легенда хороша тим, що створює у користувача відчуття, ніби він чудово розуміє пристрій системи - поки слід приписом. Недолік легенди в тому, що дотримуватися її завжди і в усьому неможливо. Одні і ті ж - за легендою - об'єкти починають вести себе в різних ситуаціях по-різному, тому що відповідають різним типам об'єктів системи. Типовий приклад легенди - поняття іконки (піктограми, icon) в Windows. Іконки в браузері ведуть себе не так, як деякі іконки на робочому столі, і зовсім не так, як іконки в панелі управління.
Користувач процедурної системи часто не знає, як саме він домігся від неї бажаного результату і далеко не завжди може з першого разу відтворити свої дії. Натискав-натискав на кнопки - і вийшло. Як? А хто ж її знає.
Принцип обмеженою обізнаності. Пристрій системи повинно бути приховано від користувача, щоб не забивати його голову "непотрібними" фактами і не давати йому можливості зіпсувати систему. Крім того, майже всю систему годі й документувати або ж зупинитися на стадії технічної документації, продажем якої можна при нагоді і заробити. А найголовніше, що недопущення до таємного знання користувач за всяким виправленням системи прийде до розробника і знову-таки заплатить за upgrade.
Принцип гарантованих навичок. Користувач не зобов'язаний щось особливе вміти для того, щоб почати працювати з процедурної системою. Тому взаємодія з процедурної системою, як правило, засноване на вже наявних у користувача або зовсім нескладних навичках.
Принцип перекриття процедур. Засоби інтеграції (спільного застосування) самих процедур в процедурних системах розвинені слабко. Отже, неминуча ситуація, коли один клас типових користувальницьких завдань вирішується за допомогою однієї групи процедур (важелів управління), інший клас задач - за допомогою іншої групи, але чому завдання менше схожа на типову, тим складніше придумати, які процедури і в якій послідовності застосовувати , щоб її вирішити. Висновок: треба самі процедури організувати так, щоб з їх допомогою або за допомогою їх суперпозиції (послідовного застосування до одного і того ж об'єкту) можна було вирішити будь-яке завдання. Це неможливо, а прагнення охопити наданими можливостями як можна більший простір призводить до двох характерних властивостей системи. По-перше, процедур (кнопочок, важелів, пунктів меню) в ній стає дуже багато. По-друге, багато завдань так і доводиться вирішувати: шляхом послідовного застосування декількох інших рішень, використовуючи при цьому тільки частина їх властивостей. Зазвичай простіше переконати користувача в тому, що готове рішення його влаштує, ніж підшукувати дійсно задовольняє його рішення.
Принцип делегування відповідальності. Оскільки користувач не має уявлення про те, що насправді відбувається, коли він запускає чергову процедуру системи, гарантію якості виконуваних перетворень продукту може дати тільки розробник процедури. Якщо процедури занадто складні, щоб до того ж відстежувати, чи не порушують вони який-небудь стандарт, простіше взагалі про нього забути і придумати власний. Такий, наприклад, формат файлів .doc: структура, правильність якої перевіряється не відповідністю якої б то не було документації, а пропусканням через процедурну систему, що породила їх.
Мало того, користувач процедурної системи в певному сенсі звикає до безвідповідальності. Будь-яке вплив на систему має обставлятися - і обставляється - всілякими попередженнями на кшталт "Ви впевнені, що хочете зробити те-то і те-то? Типова ознака процедурної системи - велика кількість запитів на підтвердження вибраної дії. Іноді підтвердження бувають подвійні: за першим" Ви впевнені ? "слід" Ви дійсно впевнені? ". Відповідальний за систему - розробник - зобов'язаний таким способом відзначати точки управління системою, в яких він перекладає відповідальність на користувача. Виходить, користувачеві Пріоритетна е бути невпевненим - так менше ймовірність, що він що-небудь зіпсує.
Слідство 1. Очевидно, що основним напрямком розвитку процедурних систем буде створення все більш повних і збалансованих наборів рішень для все більшого числа прикладних областей. Не випадково слово "утиліта" (utility) для позначення програми користувача було в таких системах замінено на "додаток" (application). Зазвичай, крім коштів рішення основного класу задач, такі системи мають деякий запас можливостей "на всі випадки життя" (згідно з принципом перекриття процедур). Користуватися таким урізаним запасом особливо незручно. Найчастіше, коли на одному комп'ютері є сусідами кілька процедурних систем, наприклад CorelDraw, PhotoShop, MS Office і т. Д. Під одним Windows, їх частини витісняють один одного (аж до втрати функціональності), марно "з'їдають" ресурси комп'ютера і захаращують простір.
Слідство 2. Діалог машини і користувача в процедурній системі будується на активності машини. Це і всілякі "майстра", і спливаючі підказки, і вінець творіння - скріпка, що б'ється головою об екран і провокує користувача на всілякі дії, про які він без неї і не подумав би. Справа в тому, що процедурна організація людино-машинної системи пригнічує ініціативу. По-перше, відповідно до принципу делегування відповідальності, якщо в приписі сказано, що для отримання потрібних властивостей об'єкта потрібно виконати 18 команд, то їх і слід виконувати, а не ті три, які здаються слушними, але ніде не сказано, що так теж можна. Згадаймо і про невпевненість, в якій слід перебувати користувачеві. По-друге, ніхто, за винятком, можливо, розробників, не знає, що насправді станеться з об'єктом від впливу цих трьох команд. Відповідно до принципу обмеженою обізнаності, користувачеві невідомо нічого, крім легенди, і її варто дотримуватися в будь-якому випадку. По-третє, система, що складається майже суцільно з готових рішень, не припускає, що перед нею будуть ставити невирішені раніше питання.