Дизайн vs. Верстка?

На Хабрахабре вже не раз порушувалося питання про те, що популярні на сьогоднішній день життєві цикли розробки веб-інтерфейсів, прямо кажучи, застаріли. Останній раз його обговорювали в публікації «Дизайн в браузері» (http://habrahabr.ru/post/238485/), але так і не прийшли до єдиної думки.

Настав час нарешті знайти відповіді на два головних питання: «Хто винен?» і «Що робити?» у вічній боротьбі дизайну і верстки…





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

Етап перший: Створення формальних вимог на розроблювальний інтерфейс. Кінцевий результат цього етапу — бриф або технічне завдання, де описано, що повинно бути на макеті, і як це буде реалізовано. Займаються цим люди з проектними ролями: бізнес-аналітик, технічний письменник;

Етап другий: Розробка графічного дизайн-макету по брифу або ТЗ. Цю роботу виконує дизайнер (веб-дизайнер, дизайнер GUI);

Етап третій: Верстка інтерфейсу (створення html\css\JS коду) по графічному дизайн-макету. Над версткою працює верстальник (фронтенд розробник, веб-розробник).

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

Прикладами проблем і виникаючих з їхньої вини підетапів можуть бути:
  • Відсутність загального бачення або нерозуміння предметної області — обмежитися текстовим описом у брифі або ТЗ не вийде. Необхідно буде створити кілька прототипів, провести додаткові дослідження.
  • Приємно виглядає інтерфейс може виявитися незручним у використанні. Щоб уникнути цього, доводиться залучати до роботи юзабіліті-спеціаліста та проводити додаткову експертизу на предмет зручності використання і т. д.




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

Проблема формальної оцінки дизайну
Під розробкою дизайну веб-інтерфейсів передбачають роботу з проектування взаємодії і оформлення зовнішнього вигляду веб-сторінок. Зовнішній вигляд зручно передати в графічному дизайн-макет. Тобто робота над дизайном зводиться до створення макета.

Оцінка макету, за великим рахунком, суб'єктивна. Часто будується на таких епітетів, як красиво, подобається, приємний, акуратний, та їх варіантами з приставкою «не»… Якість макета оцінюється за особистим уподобанням. Постає питання: а чи можна взагалі формально оцінити макет за суб'єктивними критеріями? Можна. І найдієвіший спосіб — тестування на фокус-групі: набирається група людей із цільової аудиторії, для якої розробляється макет, проводиться його демонстрація, після чого учасники дослідження заповнюють анкети-опитувальники, виставляючи оцінки виходячи зі свого особистого думки за цим суб'єктивним параметрами. Середньостатистичне значення — адекватна оцінка якості макета.

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

Інший підхід до формальної оцінки макета заснований на принципах взаємодії з користувачами, які іноді називають «Принципами Стіва Джобса»:
Розробники не вважаються з думкою користувачів, самі визначаючи те, що потрібно користувачеві, т. к. розробники — це експерти і професіонали, що бачать ситуацію в цілому і адекватно, а кінцеві користувачі у більшості випадків самі не знають, чого хочуть, і здатні лише насолоджуватися результатом, який задовольняє їх потреби, про які вони раніше і не підозрювали.
За цим принципам на початку епохи домашніх комп'ютерів створювалися рішення від Apple, які перетворили на витвір дизайнерського мистецтва ці самі ПК, на противагу «квадратно-практичному» зовнішнього вигляду продуктів конкурентів. Споживачі самі не здогадувалися, що їм сподобається той факт, що така утилітарна річ, як комп'ютер, може бути стильним дизайнерським рішенням. Але побачивши реалізацію, створену дизайнерами, не считавшимися з думкою споживача, все ж позитивно оцінили її. Втім, це інша історія, повернемося до розробки зовнішнього вигляду веб-сторінок…

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

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

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



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

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

Сюди ж йде і ще одна біда як дизайнерів, так і верстальників — відсутність контенту. Деколи в брифі написано: «тут на сторінці текст, а тут — картинка». А що це за текст, якого він розміру, скільки абзаців і заголовків в ньому; що там за картинка, в якій вона колірній гамі, які у неї пропорції — не зазначено. Тоді доводиться в дизайн-макет використовувати «рибу» (заглушки) — сторонні тексти, картинки. Іноді їх доводиться застосовувати і при верстці. А після, коли на сторінці розміщується вже кінцевий, робочий контент, жахатися кінцевого результату,

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

Як можна було б уникнути всіх цих проблем при розробці веб-інтерфейсів
Що ми маємо в підсумку? Озлоблених дизайнерів, малюють ' шу версію макета і правомірно заявляють: «потрібно більше формально ставити вимоги до макету». Не менш роздратованих верстальників, переверстывающих сторінку в El ий раз. Доповнюють цю картину розтягнулися терміни, провалені дедлайни, перевищені бюджетів та одвічні питання «Хто винен?» і «Що робити?»



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

Етап перший: Підготовка контенту;

Етап другий: Створення короткого брифу з описом функціональності і формальних вимог до розроблюваного інтерфейсу;

Етап третій: Швидка розробка інтерфейсу в тих умовах, де він буде використовуватися (прямо в браузері), відразу верстаючи його як готову веб-сторінку, з безперервною експертної та юзабіліті оцінкою.

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

Про це йшлося в статті, посилання на яку ми дали на початку посту (http://habrahabr.ru/post/238485/), але продублюю ще раз сюди:
  • На пітерському WSD велика частина доповідей була присвячена цій темі — http://webstandardsdays.ua/2014/06/28/;
  • Про це йшлося у доповіді Антона Виноградова з Альфа-лаб на BEMup (https://tech.yandex.ua/events/bemup/6-september-2014/talks/2189/), де він розглядав тему на прикладі програми верстки Яндекс.Таксі;
  • Доповідь Іллі Пухальського на Rest in PS (https://vimeo.com/85995812) також наочно роз'яснив аналогічну проблему.
В тексті статті і в коментарях до неї було висловлено, а головне — спростовано тезу, як реалізувати даний підхід: «Необхідно, щоб дизайнер був і верстальником, і розробляв інтерфейс відразу як готову верстку».

Там же, в коментарях були озвучені й інші приклади, які свідчать за актуальність описаного підходу — це з'явилися в недавньому часі спеціалізовані продукти. По-перше, це рішення для швидкого створення прототипів веб-сторінок, такі як: www.axure.com, http://froont.com. По-друге, це програми і сервіси нового покоління, де при візуальної розробки макета, відразу генерується готова верстка (і на відміну від схожих продуктів «старого покоління», ці рішення генерує чистий і лаконічний код, ніби його писав висококласний верстальник): http://macaw.co, https://webflow.com.

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

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

Якщо вас зацікавила проблематика, описана в статті, і її рішення, в якості бонусу пропонуємо подивитися ось це коротке відео — http://www.youtube.com/watch?v=nIOVU9_KRKA

Кирило,
керівник проекту Ahoba.co
У співавторстві з нашим дизайнером Сергієм Sevenvampire і веб-розробником Антоном skrutty.

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

0 коментарів

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