Деяким із нас просто важко вдається з більш м'якими аспектами дизайну інтерфейсу ( особливо я ). Чи "бек-ендери" приречені лише на розробку бізнес-логіки та шарів даних? Чи є щось, що ми можемо зробити, щоб перевчити свій мозок, щоб бути ефективнішим у розробці приємних та корисних шарів презентації?

Колеги порекомендували мені декілька книг, серед яких «Дизайн сайтів» , « Не змушуйте мене думати» та « Чому програмне забезпечення відсмоктує» , але мені цікаво, що зробили інші, щоб усунути свої недоліки в цій галузі?

Дозвольте сказати прямо:

Поліпшення цього питання не починається з настанов. Це починається з переосмислення того, як ви думаєте про програмне забезпечення.

Більшість розробників хардкорних мають практично нульовий співпереживання з користувачами їх програмного забезпечення. Вони не мають поняття, як думають користувачі, як користувачі будують моделі програмного забезпечення, якими вони користуються, і як вони використовують комп'ютер взагалі.

Це типова проблема, коли експерт стикається з мирянами: як на землі може нормальна людина бути такою німою, щоб не зрозуміти, що розумів експерт 10 років тому?

Один з перших фактів, який слід визнати, що неможливо зрозуміти майже всі досвідчені розробники:

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

Тепер це неймовірно суворо для розробника. Він пишається виробництвом програмного забезпечення. Він любить кожну особливість. Він може точно сказати вам, як працює код за ним. Можливо, він навіть винайшов неймовірний розумний алгоритм, який змусив його працювати на 50% швидше, ніж раніше.

І користувачеві все одно.

Який ідіот.

Багато розробників не витримують роботи зі звичайними користувачами. Вони пригнічені своїми неіснуючими знаннями про технологію. І тому більшість розробників ухиляються і вважають, що користувачі повинні бути ідіотами.

Вони не.

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

Багато розробників програмного забезпечення люблять фільми. Добре зроблені фільми, які розпалюють їх уяву. Але вони не є фахівцями у виробництві фільмів, у створенні візуальних ефектів чи написанні хороших сценаріїв з фільму. Більшість дуренів дуже, дуже, дуже погано діють, тому що це все про прояв складних емоцій і мало про аналітику. Якщо розробник дивиться поганий фільм, він просто помічає, що це погано в цілому. Нерди навіть створили IMDB для збору інформації про хороші та погані фільми, щоб вони знали, які з них дивитись, а яких уникати. Але вони не є експертами у створенні фільмів. Якщо фільм поганий, вони не будуть відвідувати його (або не завантажувати його з BitTorrent;)

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

Що ви можете зробити, щоб виправити це? Чим більш хардкор ви, як програміст, тим менше будете відкриті для нормального мислення користувача. Це буде для вас чужим і незрозумілим. Ви подумаєте: я не можу уявити, як люди могли коли-небудь користуватися комп’ютером з таким нестачею знань. Але вони можуть. Для кожного елемента інтерфейсу подумайте: чи це потрібно? Чи відповідає це концепції мого інструменту, яку має користувач? Як я можу змусити його зрозуміти? Будь ласка, прочитайте про зручність для цього, є багато хороших книг. Це також ціла область науки.

Ах, і перш ніж це сказати, так, я фанат Apple;)

Дизайн користувальницького інтерфейсу є жорстким

До питання:

Чому дизайн інтерфейсу настільки важкий для більшості розробників?

Спробуйте задати зворотне запитання:

Чому програмування так важко для більшості дизайнерів інтерфейсу ?

Кодування інтерфейсу та проектування інтерфейсу вимагають різних навичок та різного мислення. Дизайн інтерфейсу є важким для більшості розробників, а не для деяких розробників, так само як написання коду важко для більшості дизайнерів, а не для деяких дизайнерів.

Кодування важко. Дизайн теж важкий. Мало хто робить і те, і інше добре. Хороші дизайнери інтерфейсу рідко пишуть код. Вони навіть не вміють, але все-таки хороші дизайнери. То чому ж хороші розробники відчувають відповідальність за дизайн інтерфейсу?

Знання більше про дизайн інтерфейсу зробить вас кращим розробником, але це не означає, що ви повинні відповідати за дизайн інтерфейсу. Зрозуміло, що стосується дизайнерів: знання написання коду зробить їх кращими дизайнерами, але це не означає, що вони повинні відповідати за кодування інтерфейсу користувача.

Як краще в дизайні інтерфейсу

Для розробників, які хочуть покращити дизайн інтерфейсу, я маю 3 основні поради:

1. Визнайте дизайн як окремий навик . Кодування та дизайн окремі, але пов'язані між собою. Дизайн інтерфейсу не є підмножиною кодування. Це вимагає іншого мислення, бази знань та групи навичок. Там є люди, які зосереджуються на дизайні інтерфейсу.
2. Дізнайтеся про дизайн . Хоча б трохи. Спробуйте вивчити декілька концепцій та прийомів дизайну з довгого списку нижче. Якщо ви більш амбітні, прочитайте кілька книг, відвідайте конференцію, пройдіть заняття, отримайте ступінь. Є багато способів дізнатися про дизайн. Книга Джоеля Сполкі про дизайн інтерфейсу - це хороший ґрунтовник для розробників, але в ньому є набагато більше, і саме тут дизайнери вступають у світ.
3. Робота з дизайнерами . Гарні дизайнери, якщо можете. Люди, які роблять цю роботу, ходять за різними назвами. Сьогодні найпоширеніші заголовки - це конструктор досвіду користувачів (UXD), архітектор інформації (IA), конструктор взаємодії (ID) та інженер користувальницької роботи. Вони думають про дизайн стільки, скільки ви думаєте про код. Ви можете багато чому навчитися від них, а вони - від вас. Працювати з ними все одно ви можете. Знайдіть людей з цими навичками у вашій компанії. Можливо, вам потрібно когось найняти. Або сходити на якісь конференції, відвідувати вебінари та проводити час у світі UXD / IA / ID.

Ось деякі конкретні речі, які ви можете дізнатися. Не намагайтеся все вивчити . Якщо ви знаєте все, що нижче, ви можете назвати себе дизайнером взаємодії або інформаційним архітектором. Почніть з речей у верхній частині списку . Зосередьтеся на конкретних поняттях та навичках. Потім рухайтеся вниз і розгалужуйтеся. Якщо вам дуже подобається цей матеріал, розглядайте це як шлях до кар’єри. Багато розробників переходять до менеджменту, але UX-дизайн - це інший варіант.

• Вивчіть фундаментальні концепції дизайну . Вам слід знати про доступність, видимість, зворотній зв'язок, відображення, закон Фітта, пока-яки тощо. Я рекомендую прочитати «Дизайн речей повсякденного життя» (Дон Норман) та « Універсальні принципи дизайну» (Лідвелл, Холден та Батлер)
• Дізнайтеся про досвід користувачів . Це стає загальним терміном для орієнтованого на людину дизайну веб-сайтів, додатків та будь-якого іншого цифрового артефакту. Класичний ґрунтовник тут - Елементи досвіду користувачів (Джессі Джеймс Гаррет). Ви можете отримати огляд та перші кілька розділів з сайту автора .
• Навчіться малювати конструкції . Ескіз - це швидкий спосіб вивчити варіанти дизайну та знайти правильний дизайн, тоді як тестування зручності використання - це правильність дизайну. Формулювання паперу швидко, дешево та ефективно на ранніх етапах проектування. Набагато швидше, ніж кодування цифрового прототипу. Основний текст тут - « Нарисування досвіду користувачів»: Правильний дизайн та правильний дизайн ( Білл Бакстон ). Ескіз - це особливо корисна навичка при роботі з дизайнерами IA / ID / UX. Ваша співпраця буде більш ефективною. Щоб дізнатися, як і чому ескізують дизайнери, дивіться презентацію Як бути командою UX одного з Лії Бюлі з саміту IA 2008 .
• Дізнайтеся про прототипування паперу . Найшвидший спосіб ітераційного тестування інтерфейсу, перш ніж писати код. Відмінна від ескізу та тестування на зручність. Остаточна книга тут - " Прототипізація паперу" (Carolyn Snyder). Ви можете отримати хороший DVD про це від Nielsen Norman Group .
• Вивчіть тестування на зручність . Тестування знижок - це просто і ефективно. Але для багатьох інтерфейсів користування важко зробити добре. Ви можете швидко засвоїти основи, але хороша зручність у користуванні є неоціненною. Якщо ви хочете отримати книгу, класикою є «Довідник з тестування на користування» (Джефрі Рубін). Він старший, але пропонує ретельне висвітлення лабораторних тестувань. Знаменита книга для початківців - « Не змушуй мене думати» (2-е видання) (Стів Круг). Я застерігаю людей щодо цього: Круг робить це звуком простіше, ніж є. Але це хороший вихідний пункт. Книги досліджень користувачів, перелічені в наступному пункті, також висвітлюють цю тему. І ви можете знайти купи про це в Інтернеті.
• Дізнайтеся про архітектуру інформації . Основна книга тут - Інформаційна архітектура для всесвітньої павутини (третя) (Луї Розенфельд та Пітер Морвіль). Хороша стартова книга - Інформаційна архітектура: креслення для Інтернету (Крістіна Водтке). Для отримання додаткової інформації відвідайте Інститут архітектури інформації або відвідайте щорічний саміт інформаційної архітектури .
• Дізнайтеся про дизайн взаємодії . Основна книга тут - Основи дизайну взаємодії (3-е місце) (Алан Купер та ін. ). Хороша стартова книга - Проектування для взаємодії (Ден Саффер). Для отримання додаткової інформації відвідайте асоціацію дизайну взаємодій (IxDA) або відвідайте щорічну конференцію дизайну взаємодії .
• Вивчіть основи графічного дизайну . Графічний дизайн - це не дизайн інтерфейсу, але концепції з графічного дизайну можуть покращити інтерфейс. Графічний дизайн вводить принципи дизайну для візуального представлення інформації, наприклад, близькості, вирівнювання та невеликих кратних елементів. Рекомендую ознайомитись із дизайнерською книгою недизайнера (Робін Вільямс) та інформацією про уявлення (Едвард Туфте)
• Навчіться робити дослідження користувачів . Там, де юзабіліті перевіряють інтерфейс, дослідження користувачів намагаються моделювати користувачів та їх завдання за допомогою персоналій, сценаріїв, подорожей користувачів та інших документів. Йдеться про розуміння користувачів та те, що вони роблять, а потім використовувати це для інформування дизайну, а не здогадуватися. Деякі методи - це інтерв'ю, опитування, щоденникові дослідження та сортування кошиків. Хороші книги з цього питання - це спостереження за досвідом користувачів (Майк Кунявський) та розуміння своїх користувачів (сміливість та бакстер)
• Навчіться робити польові дослідження . Спостереження за людьми в лабораторії в штучних умовах допомагає (тобто: зручність використання), але немає нічого іншого, як спостерігати за тим, як люди використовують ваш код у контексті: їхній дім, офіс чи де б вони не використовували його. Діється під різними іменами, включаючи етнографію, польові дослідження та контекстне запитання. Ось хороший буквар з польових досліджень . Дві найвідоміші книги тут - швидкий контекстний дизайн (Karen Holtzblatt et al ) та аналіз користувачів та завдань для дизайну інтерфейсів (Hackos & Redish).
• Читайте веб-сайти дизайну UX . Деякі з найбільших - Boxes & Arrows , UX Mag , UX Matters та Digital Web magazine .
• Використовуйте бібліотеки шаблонів інтерфейсу . Існують шаблони для інтерфейсів. Для веб-сайтів я рекомендую «Дизайн сайтів», 2-е видання (Van Duyne, et al. ) Та зручність використання домашньої сторінки: 50 веб-сайтів, деконструйовані (Jakob Nielsen & Marie Tahir). Для настільних програм я рекомендую Розробити інтерфейси (Jennifer Tidwell), а для веб-додатків я рекомендую Розробити веб-інтерфейси: принципи та шаблони для взаємодії з багатими (Білл Скотт та Тереза ​​Ніл). В Інтернеті слід перевірити бібліотеку шаблонів Welie , шаблони інтерфейсу та веб-інтерфейси .
• Відвідайте дизайнерські конференції UX . Хорошими щорічними конференціями є: саміт інформаційної архітектури , взаємодія '09 (IxDA) , інтерфейс користувача та тиждень UX .
• Відвідайте семінар або вебінар . Ви можете пройти семінари, вебінари та онлайн-курси. Це далеко НЕ повний список, але ви можете спробувати віртуальні семінари UIE , Adaptive Path віртуальних семінарів і UX вебінари від Розенфельд ЗМІ .
• Отримайте ступінь . Ступінь вищої кваліфікації з ІСІ є одним із підходів, але ці програми в основному стосуються написання кодування. Якщо ви хочете дізнатися про дизайн цифрових артефактів та пристроїв, то ви хочете, щоб програма для випускників, яка не є в CS. Деякі варіанти включають дизайн взаємодії в Карнегі Меллон , d-School в Стенфорді , програма ITP в Нью-Йорку та інформаційна архітектура та управління знаннямив штаті Кент (розголошення: я на викладачах у Кенті; ми бачимо, що все більше людей із ступенями CS переходять на UX-дизайн замість менеджменту, що цікаво, адже управління - це традиційний шлях для розробників, які хочуть відійти від написання коду під час перебування у своєму полі). Є ще багато програм. Кожен має свою перспективу, сфери акцентів та технічні очікування. Деякі виходять з мистецтва та візуального дизайну, інші - з бібліотеки та інформатики, а інші - з CS. Більшість - це гібриди, але кожен гібрид має більш глибоке коріння в одному або декількох полях. Якщо це вас цікавить, огляньтесь і спробуйте зрозуміти відмінності між цими програмами. Деякі пропонують онлайн-курси та сертифікаційні програми на додаток до повноцінних ступенів.

Чому дизайн інтерфейсу важкий

Хороший дизайн інтерфейсу важкий, оскільки він включає 2 надзвичайно різні навички:

• Глибоке розуміння машини . Люди в цій групі хвилюються за кодом по-перше, люди по-друге. Вони мають глибокі технологічні знання та вміння. Ми їх називаємо розробниками, програмістами, інженерами тощо.
• Глибоке розуміння людей та дизайну : люди в цій групі хвилюються за людей по-перше, кодують друге. Вони глибоко знають, як люди взаємодіють з інформацією, комп'ютерами та навколишнім світом. Ми називаємо їх дизайнерами з користувальницького досвіду, інформаційними архітекторами, дизайнерами взаємодії, інженерами з юзабіліті тощо.

Це суттєва різниця між цими двома групами - між розробниками та дизайнерами:

• Розробники змушують це працювати . Вони реалізують функціонал на вашому TiVo, вашому iPhone, улюбленому веб-сайті тощо. Вони впевнені, що він насправді робить те, що повинен робити. Найвищий їх пріоритет - це працювати.
• Дизайнери змушують людей це любити . Вони з'ясовують, як з нею взаємодіяти, як вона повинна виглядати і як вона повинна відчувати себе. Вони проектують досвід використання програми, веб-сайту, пристрою. Їх найбільший пріоритет - змусити вас закохатись у те, що роблять розробники. Це те, що означає досвід користувача, і це не те саме, що досвід бренду.

Більше того, програмування та дизайн вимагають різного мислення , а не просто різних знань та різних навичок. Гарний дизайн інтерфейсу вимагає обох настроїв, обох баз знань, обох груп навичок. І потрібні роки, щоб освоїти будь-який.

Розробники повинні розраховувати на те, що важко знайти дизайн інтерфейсу користувача, так само як і дизайнери інтерфейсу повинні розраховувати важко знайти код написання.

Що дійсно допомагає мені вдосконалити дизайн - це захопити колегу-розробника, хлопців із якості, прем'єр-міністра чи когось, хто трапляється ходити та перепробовувати певний віджет чи екран.

Дивовижне те, що ти зрозумієш, коли спостерігатимеш, як хтось інший вперше використовує ваше програмне забезпечення

Зрештою, справа справді про співпереживання - чи можете ви поставити себе у взутті свого користувача?

Одне, що допомагає, звичайно, - це "їсти власну собачу їжу" - самостійно використовувати свої додатки як реального користувача та бачити, що дратує.

Ще одна гарна ідея - знайти спосіб спостереження за реальним користувачем за допомогою програми, який може бути таким же складним, як лабораторія зручності використання з односторонніми дзеркалами, захопленням екранного відео, відеокамерами для користувачів тощо, або може бути таким же простим. як паперові прототипи, використовуючи наступну людину, яка трапляється ходити по залі.

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

Якщо ви багато читаєте про дизайн, ви можете легко повісити на скинуті тіні та закруглені кути тощо. Це не найважливіші речі. Простота та відкритість - важливі речі.

На відміну від популярного міфу, в дизайні інтерфейсу користувача буквально немає м'яких аспектів, принаймні не більше, ніж потрібно для створення хорошого заднього кінця.

Розглянемо наступне; хороший дизайн заднього кінця базується на досить твердих принципах та елементах, з якими знайомий хороший розробник:

• низька муфта

• висока згуртованість

• архітектурні зразки

• кращі практики в галузі

• тощо

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

Гарний дизайн інтерфейсу базується на здорових принципах:

• видимість

• недоторканність

• відгуки

• толерантність

• простота

• послідовність

• будова

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

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

Рекомендую пройти курс з взаємодії з комп'ютером людини, ознайомтеся з веб-сайтом MIT та Yale, наприклад, на матеріали онлайн:

• Курс проектування та впровадження користувальницького інтерфейсу MIT

Структурна та функціональна модель у розумінні та використанні

Чудовий попередній пост Thorsten79 піднімає тему експертів з розробки програмного забезпечення проти користувачів та як їх розуміння програмного забезпечення відрізняється. Експерти з навчання людини розрізняють функціональну та структурну ментальні моделі. Пошук шляху до будинку вашого друга може бути відмінним прикладом різниці між двома:

• Перший підхід включає в себе набір детальних інструкцій: зробіть перший вихід з автомагістралі, потім через 100 ярдів поверніть ліворуч тощо. Це приклад функціональної моделі: перелік конкретних кроків, необхідних для досягнення певної мети. Функціональні моделі прості у використанні, вони не вимагають багато роздумів, просто прямого виконання. Очевидно, що за простоту існує штраф: це може бути не найефективнішим маршрутом, і будь-яка виняткова ситуація (наприклад, перенаправлення трафіку) може легко призвести до повного збою.

• Інший спосіб впоратися із завданням - побудувати структурну ментальну модель. У нашому прикладі це була б карта, яка передає багато інформації про внутрішню структуру "об'єкта завдання". Зрозумівши карту та відносні місця розташування нашого та другого будинку, ми можемо вивести функціональну модель (маршрут). Очевидно, що це вимагає більше зусиль, але набагато надійніший спосіб виконання завдання, незважаючи на можливі відхилення.

Вибір між передачею функціональної чи структурної моделі через інтерфейс користувача (наприклад, майстер проти розширеного режиму) не такий прямолінійний, як може здатися з поста Thorsten79. Просунуті та часті користувачі цілком можуть віддати перевагу структурній моделі, тоді як випадкові або менш досвідчені користувачі - функціональні.

Карти Google є прекрасним прикладом: вони включають як функціональну, так і структурну модель, так що багато інших насичених навичок.

Інший аспект проблеми полягає в тому, що структурна модель, представлена ​​через інтерфейс користувача, не повинна відображати структуру програмного забезпечення, а, природно, відображати структуру заданого користувача або об'єкта завдання, який займається.

Складність полягає в тому, що багато розробників матимуть хорошу структурну модель внутрішнього програмного забезпечення, але лише функціональну модель завдання користувача, у якому програмне забезпечення спрямоване на допомогу. Щоб створити хороший інтерфейс користувача, необхідно зрозуміти структуру об'єкта завдання / завдання та нанести на нього карту.

У будь-якому разі, я все ще не можу рекомендувати пройти офіційний курс ІСС досить сильно. Існує багато предметів, таких як евристика , принципи, похідні від гештальт-психології , способи навчання людей тощо.

Я пропоную вам почати робити весь свій інтерфейс користувача так само, як ви робите зараз, не орієнтуючись на зручність використання та інше.

alt text http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

Тепер подумайте про це:

Дизайнер знає, що він досяг досконалості не тоді, коли не залишається нічого додати, а коли не залишається нічого, щоб забрати. - Сент-Екзюпері

І застосуйте це у своєму дизайні.

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

Ще одна хороша книга - «Дизайн речей щоденного» Дональда Нормана.

Існує величезна різниця між дизайном та естетикою, і їх часто плутають.

Для прекрасного інтерфейсу потрібні художні чи принаймні естетичні навички, які багато хто, в тому числі і я, нездатний створити. На жаль, цього недостатньо і не робить користувальницький інтерфейс корисним, як ми бачимо у багатьох важких форматах Flash-інтерфейсів.

Підготовка зручних інтерфейсів вимагає розуміння того, як люди взаємодіють з комп'ютерами, деяких питань психології (наприклад, закону Фітта, закону Хіка) та інших тем. Для цього готується дуже мало програм CS. Дуже мало розробників, яких я знаю, виберуть книгу для тестування користувача над книгою JUnit тощо.

Багато хто з нас є також «основними програмістами», як правило, сприймають інтерфейси користувача як фасад, а не як фактор, який може зробити або порушити успіх нашого проекту.

Крім того, більшість досвіду розробки інтерфейсу користуються надзвичайно розчаруванням. Ми можемо використовувати іграшкових графічних інтерфейсів, таких як старий VB, і мати справу з некрасивим кодом клею, або ми використовуємо API, які нас зривають без кінця, як, наприклад, намагаючись розібрати макети в Swing.

Перейдіть до Slashdot і прочитайте коментарі до будь-якої статті, що стосується Apple. Ви знайдете велику кількість людей, які говорять про те, як продукти Apple не є нічого особливого, і приписуючи успіх iPod та iPhone людям, які намагаються бути модними або хіп. Вони, як правило, проходять через списки функцій і вказують, що раніше вони нічого не робили, MP3-плеєри чи смартфони не робили.

Потім є люди, яким подобається iPod та iPhone, тому що вони роблять те, що користувачі хочуть просто і легко, без посилання на посібники. Інтерфейси настільки ж інтуїтивні, як інтерфейси отримують, запам'ятовуються та відкриваються. Мені не так подобається інтерфейс користувача MacOSX, як я був у попередніх версіях, я думаю, що вони відмовилися від користі на користь блиску, але iPod та iPhone - приклади чудового дизайну.

Якщо ви перебуваєте в першому таборі, ви не думаєте так, як це робить звичайний чоловік, і тому ви, ймовірно, будете робити погані користувацькі інтерфейси, тому що не можете їх сказати з хороших. Це не означає, що ви безнадійні, а скоріше, що вам доведеться чітко вивчити хороші принципи дизайну інтерфейсу та як розпізнати хороший інтерфейс користувача (стільки, як комусь із Аспергера може знадобитися явне вивчення соціальних навичок). Очевидно, що почуття хорошого інтерфейсу не означає, що ти можеш створити його; Наприклад, моя вдячність за літературу, здається, не поширюється на здатність (наразі) писати опубліковані історії.

Отже, спробуйте розвинути почуття до гарного дизайну інтерфейсу. Це поширюється на більше, ніж просто програмне забезпечення. "Дизайн повсякденних речей" Дон Нормана - класика, там є й інші книги. Отримайте приклади успішних дизайнів інтерфейсу та пограйте з ними достатньо, щоб відчути різницю. Визнайте, що вам, можливо, доведеться вивчити новий спосіб мислення про речі, і насолоджуйтесь цим.

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

Я думаю, що це, безумовно, можна бути як хорошим розробником бек-енду, так і хорошим дизайнером інтерфейсу, просто потрібно попрацювати над цим, зробити читання та дослідження теми (все, що стосується Міллера №7, до архівів Нільсена), і зробити Ви впевнені, що розумієте, чому дизайн інтерфейсу має надзвичайно важливе значення.

Я не думаю, що це справа, коли потрібно бути творчим, але, як, наприклад, бек-енд, це дуже методична та дуже структурована річ, яку потрібно вивчити. Люди, які стають «творчими» з інтерфейсами, створюють найбільші монстроти щодо зручності користування ... Я маю на увазі, для початку подивіться на 100% веб-сайти Flash ...

Редагувати : Книга Круга справді гарна ... прочитайте її, особливо якщо ви збираєтеся розробляти Інтернет.

Причин для цього багато.

(1) Розробник не бачить речей з точки зору користувача. Це звичайний підозрюваний: відсутність співпереживання. Але це, як правило, не так, оскільки розробники не такі чужі, як люди змушують їх бути.

(2) Ще однією, більш поширеною причиною є те, що розробник, який знаходиться настільки близько до власних речей, пробувши так довго свої речі, не усвідомлює, що його речі можуть бути не такі звичні (термін кращий, ніж інтуїтивно зрозумілий) іншим людям .

(3) Ще однією причиною є те, що розробник не має техніки.

МОЕ ВЕЛИКОГО ЗАЯВКИ: читайте будь-який інтерфейс користувача, дизайн взаємодії між людьми, книгу по прототипуванню. наприклад, Проектування очевидного: підхід звичайного сенсу до дизайну веб-додатків, не змушуйте мене думати: підхід здорового глузду до зручності використання веб-сторінок, проектування моменту, що завгодно.

Як вони обговорюють потоки завдань? Як вони описують точки прийняття рішень? Тобто, у будь-якому випадку використання існує як мінімум 3 шляхи: успіх, невдача / виняток, альтернативний.

Таким чином, з точки A можна перейти до A.1, A.2, A.3. З точки A.1 ви можете дістатися до A.1.1, A.1.2, A.1.3 тощо.

Як вони показують такий потік завдань? Вони ні. Вони просто замовчують це.

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

Мені доводиться використовувати для цього власні ручні прийоми.

Я намагаюся підтримувати зв’язок із веб-сайтами та текстами, що стосуються дизайну. У цих дослідженнях я також виявив дуже цікавою книгу Робіна Вільямса «Книга дизайнерів недизайнера» .

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

Кожен може бути дизайнером раз у раз, як і кожен може бути програмістом.

Підходячи до дизайну інтерфейсу, ось кілька речей, які я пам’ятаю протягом усього часу (далеко не повний список):

• Спілкування моделі . Користувацький інтерфейс - це розповідь, що пояснює користувачеві ментальну модель. Ця модель може бути бізнес-об’єктом, набором відносин, що у вас є. Візуальна відомість, просторове розміщення та упорядкування робочих процесів відіграють важливу роль у передачі цієї моделі користувачеві. Наприклад, певний вид списку проти іншого передбачає різні речі, а також співвідношення того, що в списку, до решти моделі. Взагалі мені найкраще переконатися, що одночасно передається лише одна модель. Програмісти часто намагаються зв’язати більше однієї моделі або декількох частин в одному просторі інтерфейсу.

• Послідовність . Повторне використання популярних метафорів інтерфейсу багато допомагає. Внутрішня узгодженість також дуже важлива.

• Групування завдань . Користувачі не повинні рухати мишкою по всьому екрану, щоб перевірити або виконати пов'язану послідовність команд. Модальні діалоги та меню вильоту можуть бути особливо поганими в цій області.

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

Прочитайте керівництво Apple щодо людського інтерфейсу .

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

Ми послідовно застосовуємо такий підхід у всіх проектах. Завжди захоплююче спостерігати за тим, як Користувач має справу з програмним забезпеченням у спосіб, який ви ніколи не розглядали.

Чому дизайн інтерфейсу настільки важкий? Ну взагалі тому, що розробник та користувач ніколи не зустрічаються.

duffymo просто нагадав мені чому: Багато програмістів думають "* Дизайн" == "Мистецтво".

Хороший дизайн інтерфейсу абсолютно не художній. Це дотримується твердих принципів, які можна підкріпити даними, якщо у вас є час на дослідження.

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

Що я зробив для покращення дизайну інтерфейсу?
Зверніть на це увагу!

Це як колись ви бачите графік новин або електронний знак автобуса, і вам цікаво: "Як вони отримали ці дані? Вони робили це з raw sql або вони використовують LINQ? ' (або вставте сюди свою власну загальну цікавість).

Почати це потрібно, але з візуальними елементами різного роду.

Але так само, як вивчати нову мову, якщо ви насправді не кинетесь на неї, ви ніколи не навчитесь її.

З іншого відповіді я написав:

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

Однак ви це робите (і є кілька чудових моментів вище), мені це дійсно допомогло, як тільки я зрозумів, що НЕ ТАКОГО НЕ ЧОГО ЯК ІНТУЙТИВНО ...

Я чую, як аргументи гуркотять на обрії ... тож дозвольте мені трохи пояснити.

Інтуїтивне: використання того, що відчуваєш себе правильним чи правдивим на основі несвідомого методу чи почуття.

Якщо (як постулював Карл Саган) ви погоджуєтесь, що не можете зрозуміти речі, абсолютно не схожі ні на що, з чим ви коли-небудь стикалися, то як ви могли "знати", як щось використовувати, якщо ви ніколи не використовували щось віддалено, як це?

Подумайте над цим: діти намагаються відкрити двері не тому, що вони "знають", як працює дверна ручка, а тому, що вони бачили, як це робить хтось інший ... часто вони повертають ручку в неправильному напрямку або тягнуть занадто рано. Вони повинні Вчитись, як працює дверна ручка. Потім ці знання застосовуються в різних, але схожих випадках: відкрити вікно, відкрити шухляду, відкрити майже все велике з великою ручкою на вигляд ручки.

Навіть прості речі, які здаються нам інтуїтивними, зовсім не будуть інтуїтивними для людей з інших культур. Якщо хтось простягнув руку перед собою і відмовився від руки вгору-вниз за зап'ястя, зберігаючи руку все-таки .... чи відмовляються від вас? Можливо, якщо ви не перебуваєте в Японії. Там цей сигнал руки може означати "приходьте сюди". То хто прав? Обидва, звичайно, у власному контексті. Але якщо ви подорожуєте в обох, вам потрібно знати обоє ... дизайн інтерфейсу.

Я намагаюся знайти речі, які вже «знайомі» потенційним користувачам мого проекту, а потім будувати навколо них інтерфейс користувача: орієнтований на користувача дизайн.

Погляньте на iPhone Apple. Навіть якщо ти ненавидиш це, ти повинен поважати міркування, яке зайшло в нього. Це ідеально? Звичайно, ні. З часом сприйнята об'єктом "інтуїтивність" може зростати або навіть повністю згасати.

Наприклад. Більшість всіх знає, що смужка чорного кольору з двома рядами отворів по верху та знизу схожа на смужку плівки ... чи вони?

Запитайте середнього віку 9 або 10 років, що вони думають. Ви можете бути здивовані, скільки дітей зараз буде важко ідентифікувати його як кінострічку, навіть якщо це все ще використовується для представлення Голлівуду чи будь-якого фільму (фільму). Більшість фільмів за останні 20 років були зняті цифровим шляхом. І коли востаннє хтось із нас проводив фільм будь-якого роду, фотографії чи фільм?

Отже, для мене все це зводиться: знайте свою аудиторію та постійно досліджуйте, щоб не відставати від тенденцій та змін у речах, які є "інтуїтивно зрозумілими", націлюйте на своїх основних користувачів та намагайтеся не робити речей, які карають недосвідчених на користь досвідчені користувачі або сповільнюють просунутих користувачів, щоб утримувати новачків.

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

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

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

Я знаю, що Microsoft доволі не відповідає їх власним рекомендаціям, але я виявив, що читання їхніх керівних принципів щодо дизайну Windows дуже допомогло мені. У мене є копія на моєму веб-сайті тут , просто прокрутіть трохи вниз посібнику Vista UX. Це допомогло мені в таких речах, як кольори, інтервал, макет тощо.

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

Тоді як користувач, як правило, починає абсолютно нічого не знати про програму, і ніколи не повинен дізнаватися нічого про її внутрішню роботу.

Дуже важко, майже неможливо, не використовувати наявні у вас знання - і саме тому інтерфейс користувача не повинен розробляти хтось, хто розробляє додаток за ним.

"Проектування з обох сторін екрана" представляє дуже просту, але глибоку причину того, чому програмістам важко розробити дизайн інтерфейсу: програмісти навчаються думати в кращих випадках, тоді як дизайнери інтерфейсу навчаються думати в умовах звичайних випадків або використання.

Тож переходити з одного світу в інший, безумовно, важко, якщо навчання за замовчуванням в будь-якому випадку є прямо протилежним іншому.

Сказати, що програми, які смокчуть дизайн інтерфейсу, - це пропустити суть. Суть проблеми полягає в тому, що формальне навчання, яке отримує більшість розробників, не входить в технологію. Взаємодія людини - комп'ютера - це не проста тема. Це не те, що я можу "налаштовувати на розум", надаючи простий однорядковий вислів, який дає зрозуміти, "о, користувачі будуть використовувати цей додаток ефективніше, якщо я роблю x замість y".

Це тому, що у вас є одна частина дизайну інтерфейсу, яка вам не вистачає. Мозок людини. Щоб зрозуміти, як сконструювати інтерфейс користувача, ви повинні зрозуміти, як людський розум взаємодіє з машинами. В університеті Міннесоти я пройшов відмінний курс на цю тему, який викладав професор психології. Він названий "Взаємодія людини - машини". Це описує багато причин, чому дизайн інтерфейсу настільки складний.

Оскільки психологія базується на кореляціях, а не на причинності, ви ніколи не зможете довести, що метод дизайну інтерфейсу завжди працюватиме в будь-якій ситуації. Ви можете співвіднести, що багато користувачів вважають певний дизайн інтерфейсу привабливим або ефективним, але ви не можете довести, що він завжди узагальнюватиметься.

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

Існує кілька хороших книг на цю тему та курс, який слід взяти (як, наприклад, « Ескіз досвіду користувачів Білла Бакстона» та « Пізнання в дикій природі » Едвіна Хатчинса). У багатьох університетах є програми випускників з питань взаємодії людини та комп'ютера.

Загальна відповідь на це питання хоч і полягає у тому, як людей навчають інформатиці. Це все на основі математики, на логіці та не на основі досвіду користувача. Щоб досягти цього, вам потрібно більше, ніж загальний 4-річний ступінь інформатики (якщо тільки 4-річний ступінь інформатики не був неповнолітнім з психології та наголошувався на взаємодії людини та комп'ютера).

Давайте перетворимо ваше запитання -

Чи "дизайнери інтерфейсу" приречені лише на дизайн архітектури та шари презентацій? Чи є щось, що вони можуть зробити, щоб перевчити свій мозок, щоб бути ефективнішим у розробці приємних та ефективних системних шарів?

Схоже, їм "дизайнерам інтерфейсу" доведеться по-іншому сприймати - вони повинні виглядати зсередини коробки назовні; замість того, щоб зазирнути ззовні.

Думка Алана Купера "Ув'язнені бежать на притулок" полягає в тому, що ми не можемо успішно використовувати обидві точки зору - ми можемо навчитися добре носити одну шапку, але ми не можемо просто перемикати шапки.

Я думаю, що це тому, що хороший інтерфейс не є логічним. Хороший інтерфейс інтуїтивно зрозумілий.

Зазвичай розробники програмного забезпечення роблять поганий "інтуїтивний"

Корисна рамка - це активно розглядати те, що ви робите, як розробляти процес спілкування. По-справжньому, ваш інтерфейс - це мова, яку користувач повинен використовувати, щоб сказати комп'ютеру, що робити. Це призводить до розгляду низки пунктів:

1. Користувач вже розмовляє цією мовою? Використовувати високо ідіосинкратичний інтерфейс - це як спілкуватися мовою, про яку ви ніколи не говорили. Тож якщо ваш інтерфейс взагалі повинен бути ідіосинкратичним, він найкраще познайомиться з найпростішими термінами та кількома відволіканнями. З іншого боку, якщо ваш інтерфейс використовує ідіоми, до яких користувач звик, вони з самого початку набудуть впевненості.
2. Ворог спілкування - шум. Слуховий шум заважає розмовному спілкуванню; зоровий шум заважає візуальному спілкуванню. Чим більше шуму ви можете вирізати з інтерфейсу, тим легше буде спілкуватися з ним.
3. Як і в людській розмові, часто це не те, що ви говорите, це те, як ви це говорите. Те, як більшість програмного забезпечення спілкується, є грубим до такої міри, що змусило б його ударити в обличчя, якби це людина. Як ви почуваєтесь, якби ви комусь задали запитання, і вони сиділи там і дивилися на вас кілька хвилин, відмовляючись відповідати будь-яким іншим способом, перш ніж відповісти? Багато елементів інтерфейсу, такі як смуги прогресу та автоматичний вибір фокуса, виконують основні функції ввічливості. Запитайте себе, як можна зробити день користувача трохи приємнішим.

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

Уже багато хороших коментарів, тож я не впевнений, що можна багато чого додати. Але все ж...

• Чому розробник розраховував створити хороший інтерфейс користувача?
• Скільки навчань він провів у цій галузі?
• Скільки книг він прочитав?
• Скільки речей він сконструював за скільки років?
• Чи мав він можливість бачити реакцію її користувачів?

Ми не сподіваємось, що випадковий "Джо сантехнік" зможе написати хороший код. То чому б ми очікували, що випадковий "Джо програміст" створить хороший інтерфейс користувача?

Емпатія допомагає. Відокремлення дизайну інтерфейсу та програмування допомагає. Тестування юзабіліті допомагає.

Але дизайн інтерфейсу - це ремесло, якому треба навчитися та практикувати, як і будь-яке інше.

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

Більшість розробників (включаючи мене) почали "розробляти" інтерфейси користувача, оскільки це було необхідною частиною написання програмного забезпечення. До тих пір, поки розробник не докладе зусиль, щоб отримати хороший результат, він / його не буде.

Для покращення просто огляньте наявні сайти. Окрім вже запропонованих книг, ви можете поглянути на чудову книгу Робіна Вільямса "Книга дизайнерів, що не розробляються" ( санітоване посилання Amazon )

Погляньте на те, що можливо у візуальному дизайні, ознайомившись з різними матеріалами, представленими в The Zen Garden .

Дизайн інтерфейсу, безумовно, є мистецтвом, хоча, як і вказівники на С, деякі отримують його, а деякі - ні.

Але принаймні ми можемо посміхнутися з їхніх спроб . BTW Дякую ОК / Скасувати за кумедний комікс і дякую Джоелю за те, що він помістив його у вашій книзі "Найкраще написання програмного забезпечення я" ( санітоване посилання Amazon ).

Користувацький інтерфейс - це не те, що можна застосувати після факту, як тонкий шар фарби. Це щось, що повинно бути там на початку, і базуватися на реальних дослідженнях. Зрозуміло, є багато дослідницьких можливостей. Це потрібно не просто бути там на початку, воно має сформувати серцевину тієї самої причини, що ви робите це програмне забезпечення в першу чергу: у світі є якийсь розрив, якась проблема, і це потрібно зробити більш корисні та ефективніші.

Програмне забезпечення там не заради себе. Причина існування програмного забезпечення - НАРОД. Абсолютно смішно навіть намагатися придумати ідею для нового програмного забезпечення, не розуміючи, чому це комусь потрібно. Але все це відбувається постійно.

Перш ніж записати єдиний рядок коду, вам слід пройти паперові версії інтерфейсу та протестувати його на реальних людях. Це щось дивно і нерозумно, він найкраще працює з дітьми, а хтось розважає, як "комп'ютер".

Інтерфейс повинен використовувати переваги наших природних пізнавальних засобів. Як печерний користувач використовував би вашу програму? Наприклад, ми еволюціонували, щоб насправді добре відстежувати рухомі об’єкти. Ось чому інтерфейси, які використовують фізичне моделювання, як iphone, працюють краще, ніж інтерфейси, де зміни відбуваються миттєво.

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

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

Трюк із символами полягає в тому, що між символом має бути чіткий взаємозв'язок і те, що він представляє. Реч, яку вона представляє, повинна бути іменником, і в цьому випадку символ повинен виглядати ДУЖЕ ТАКОЖ, як річ, яку він представляє. Якщо символ являє собою більш абстрактне поняття, це повинно бути пояснено НАДІЙСНО. Перегляньте непереборні іконки без контенту на панелі інструментів msword або на фотошопі та абстрактні поняття, які вони представляють. Слід ВЧИТИ, що значок інструмента для обрізання у фотошопі означає CROP TOOL. треба розуміти, що навіть означає CROP. Це необхідні умови правильного використання цього програмного забезпечення. Що означає важливий момент, остерігайтеся ВИМОГАНИХ знань.

Ми лише здобуваємо здатність розуміти карти близько 4 років. Я думаю, що десь читав, що шимпанзе отримують здатність розуміти карти приблизно у віці від 6 до 7 років.

Причина того, що Guis почали настільки успішно, полягає в тому, що вони змінили пейзаж переважно текстових інтерфейсів для комп'ютерів, на те, що відображало комп'ютерні концепції на щось, що нагадувало фізичне місце. Там, де Guis не вдається з точки зору зручності використання, це те, де вони перестають нагадувати щось, що ви побачили в реальному житті. Є непомітні, непередбачувані, незрозумілі речі, що трапляються на комп’ютері, які не мають подібності ні до чого, що ти коли-небудь бачив у фізичному світі. Дещо з цього потрібно, оскільки не було б сенсу просто робити тренажер реальності. Ідея полягає в тому, щоб заощадити роботу, тому має бути трохи магії. Але ця магія повинна мати сенс і ґрунтуватися на абстракції, яку люди добре пристосували до розуміння. Це коли наші абстракції починають поглиблюватися і шаруватися, і не відповідала завданню, що руйнується. Іншими словами, інтерфейс не працює як хороша карта для базового програмного забезпечення.

Є багато книг. Два, яких я читав, і тому можу рекомендувати, - це "Дизайн речей щоденного" Дональда Нормана та "Людський інтерфейс" Джефа Раскіна.

Я також рекомендую курс психології. "Дизайн речей кожного дня" про це трохи говорить. Дуже багато інтерфейсів виходять з ладу через "народне розуміння" розробника психології. Це схоже на "народну фізику". Об’єкт, що перебуває в русі, не має сенсу для більшості людей. "Ви повинні продовжувати натискати, щоб тримати його в русі!" вважає послушник фізики. Тестування користувачів не має сенсу для більшості розробників. "Ви можете просто запитати користувачів, чого вони хочуть, і це повинно бути досить добре!" вважає початківця психології.

Я рекомендую виявити Психологію - документальну серію PBS, влаштовану Філіпом Зімбардо. Якщо цього не зробити, спробуйте знайти хороший підручник з фізики. Дорогий вид. Не те, що ти знайдеш у кордонах, а не товста література, яку ти можеш знайти, лише в університетській бібліотеці. Це необхідний фундамент. Ви можете зробити гарний дизайн без цього, але ви будете мати лише інтуїтивне розуміння того, що відбувається. Читання хороших книг дасть вам хорошу перспективу.

Якщо ви читали книгу "Чому програмне забезпечення смокче", ви побачили б відповідь Платта, яка є простою:

1. Розробники краще контролювати зручність використання
2. Середні люди віддають перевагу зручності користування над контролем

Але ще однією відповіддю на ваше запитання було б "чому стоматологія настільки складна для деяких розробників?" - Дизайн інтерфейсу найкраще робити дизайнером інтерфейсу.

http://dotmad.net/blog/2007/11/david-platt-on-why-software-sucks/