Мої правила гарного інтерфейсу

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

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

Хороший приклад, коли дизайнер дав користувачеві розуміння, що важливо бачити відправника, потім тему, а вже потім вміст або його @нік в системі:
image

Поганий приклад, де дизайнер «стверджує»: найважливіше — аватарки, а з рештою як-небудь розберетеся:
image

Відступи та їх пропорційність
Сучасний дизайн, легкий, простий і «насичений повітрям». Він наповнений диханням. І не останню роль у формуванні цих відчуттів грають відступи. Значні відступи допомагають спростити подачу матеріалу. Але вони повинні бути підпорядковані певній закономірності та пропорційності. Я визначаю для себе N пікселів в якості базисного відступу, коли починаю новий проект. Потім я використовую 2N, 3N і так далі пропорційність для створення візуального балансу, якщо десь потрібно більший відступ.

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

Поганий приклад, коли відступи практично базуються на генераторі випадкових чисел:
image

Текст кнопки завжди первинній іконки
Не забувайте, що саме текст є визначальним фактором того, яку очікування або реакція попередньо сформується у користувача при вигляді кнопки. І лише зображення іконки вторинним чином доповнює зміст. Зображення дзвоника з написом «notifications» дає нам деяке уявлення про призначення цього функциона до того, як ми зробили клік. Аналогічний дзвіночок без підпису в іншому додатку приведе нас до будильника, хоча ми швидше за все будемо очікувати появу екрану з повідомленнями. Я раджу завжди наділяти напис великим «вагою» ніж іконки. Їх я взагалі вважаю обдурюванням. Багато сучасні інтерфейси цілком здатні обходитися і без них. Просто це було б надто нудно!

В цілому добре:
image

Але можна зробити краще:
image

Теж виглядає непогано:
image

І тут є, де поліпшити:
image

Не намагайтеся бути занадто зрозумілими
Не всі проектовані інтерфейси повинні бути інтуїтивно зрозумілими. Існує безліч складних систем, з якими ми навчалися (!) взаємодіяти якийсь час. Можливо зараз вони здаються нам простими, але ми не усвідомлюємо, що були дослідниками-першовідкривачами перші хвилини, години або більше. І якщо ми продовжуємо роботу всередині деякої спочатку складної системи, мабуть нічого не перешкоджало нашому шляху перших досліджень. Швидше за все, дизайнер зробив свою роботу настільки добре, що ми без праці освоїли нову середу. Яскравий приклад з життя: спробуйте на мить уявити, що ви не знаєте значення математичного знака «дорівнює». Погодьтеся, ці дві рисочки — одна над іншою, вони зовсім не здаються інтуїтивно зрозумілими. Просто колись у школі вчитель математики навчив нас цього. Я закликаю не намагатися бути зрозуміліше, ніж це потрібно на мінімально необхідному рівні.

У цьому прикладі дизайнер був надмірно зрозумілий з кнопкою закриття:
image

А в цьому прикладі дизайнер виявився надмірно зрозумілий з можливістю додавання:
image

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

Хороший приклад, коли дизайнер пропонує закрити попап в тій же області, яка викликала його породження:
image

Поганий приклад, коли дизайнер віддаляє функціонал додавання елемента в список від самого списку:
image

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

Поганий приклад з неузгодженнями:
image

Хороший приклад з гармонією і відповідністю:
image

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

Приклад хаосу: (172 votes зеленим означає позитивний стан? якщо, так то 280 visitors помаранчевим — означає негативний за логікою? аж ніяк! дизайнер кольором лише розділив цифри між собою)
image

Приклад створення порядку та обґрунтування кольору (я просто додав графіки поверх чужого творчості)
image

Хороший приклад незлоупотребления квітами:
image

В качетве епілогу…

Висловлюю подяку членам спільноти dribbble, за неформальне згоду надати свої роботи для даного огляду :) Хочу нагадати, що викладені вище принципи є основними для мене. Я завжди тримаю їх у розумі при проектуванні інтерфейсів. Визначтеся на чиєму боці ви… Ви хочете створювати інтерфейси для дизайнерів і працювати на лайки (приклад — 98% робіт з behance) або ви прагнете вирішувати проблеми користувача (dribbble)? До речі, по-моєму відмінний приклад того, як закритість спільноти дозволяє зберігати фокусування на головному призначення інтерфейсів!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.