Серйозне проектування серйозних сайтів. Частина 2. Візуалізація

Це друга частина статті про проектування великих сайтів. У ній ми розповімо про візуальну частину проектування, про інтерфейси. Якщо ви не читали першу частину, то рекомендую це зробити тут: habrahabr.ru/company/SECL_GROUP/blog/318598

Динамічний прототип


Рис. 9. Демонстрація динамічного прототипу для проекту «Маркетплейс».

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

У статті буде багато картинок. Хабр, на жаль, не дозволяє завантажувати великі картинки, тому їх можна подивитися в повній версії статті на нашому сайті: http://seclgroup.ru/article_serious_design_of_the_serious_websites_2.html

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

Робиться це за допомогою програми Axure RP або інший, їх досить багато, у тому числі онлайн-сервіси. Хоча краще Axure ми за довгі роки роботи поки не знайшли. Деякі намагаються проектувати в Photoshop — це в основному дизайнери, а не проектувальники, які методологію проектування використовують лише частково. Photoshop і ряд інших програм не дозволяють робити динамічні прототипи, так і банально довго проектувати в Photoshop. Нам потрібна динаміка, щоб подумати над кожною кнопкою і ссилочку. Відразу скажу, що красиві картинки, не зібрані у динамічний прототип, в тому числі просто дизайн без проектування-це перший цвях у труну проекту. Ми просто не зможемо перевірити роботу на логічні помилки перед тим, як віддати на наступний етап, і будемо змушені переробляти після. А класика розробки, напевно, найвідоміша книга «Досконалий код» нам дуже наочно показує, як на різних стадіях виправлення помилки буде підвищуватися від 1$ до 10000$.

Ми повинні планомірно йти по нашій Mind map і проектувати сторінку за сторінкою. Axure зліва може відображати зміст, там ми називаємо сторінки, робимо вкладеності і нумеруем всі в форматі: «1.0.0», «2.0.0», «2.0.1» і т. д. Це не дасть нам заплутатися, коли у нас буде кілька десятків сторінок. Також важливо намагатися проектувати цілими розділами, а не вибірково кілька сторінок в одній частині проекту, а потім кілька сторінок в інший.

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

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

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

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

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

Після створення всіх сторінок їх потрібно з'єднати їх воєдино. Для цього ми робимо динаміку з допомогою внутрішніх інструментів Axure, поєднуючи всі сторінки посиланнями, роблячи спливаючі вікна, випадаючі списки і т. д. Важливо також забити в реальний прототип контент, щоб максимально наблизити його до живого сайту. Так ми оживляємо прототип, і у нас з'являється можливість перевірити логіку його роботи і навіть показати реальним користувачам для отримання першої зворотного зв'язку. Приклад такого прототипу в динаміці ми показували в статті, в якій описано проектування аналога Alibaba.com — більше 200 унікальних прототипів, і це ще спрощена версія.

Окремо проектується адаптив, щоб на всіх пристроях і дозволи екранів сайт коректно відображався. Сьогодні у світі більше половини всіх користувачів відвідують сайти з мобільних пристроїв, так що адаптив — це давно не мода. По суті, адаптив — це кілька різних варіантів сайту, які відображаються користувачам залежно від його пристрою. Користувач цього не знає, але технічно ми повинні спроектувати декілька окремих версій. Мінімум їх має бути три: 320 px., 768 px. і 1200 px. Рідше робляться ще варіанти під 420 px. і 960 пікселів. Чим менший екран, тим менше функціоналу має бути в прототипі, тобто для маленьких екранів ми робимо спрощені варіанти. Як альтернатива, можна не проектувати адаптив, а залишити його на етап верстки, на розсуд верстальника — це значно дешевше, але і якість постраждає.

Приклади інших великих спроектованих проектів, які ми робили за останні 5 років, щоправда, ми покажемо їх без динаміки:



Загалом, за останні кілька років ми проектували майже все, що тільки можна, тут далеко не повний перелік проектів. Технологія проектування універсальна і досить близька до стандарту ISO 9241-210 «Human-centered design for interactive systems». Іншими словами, це те, чим користуються у всьому світі, і вона відмінно працює!

Для ілюстрації слів ще кілька прототипів різних проектів:

Рис. 10. Прототип соціальної мережі з елементами електронне комерції


Рис. 11. Протопит сервісу Пуш повідомлень


Рис. 12. Прототип освітнього сервіс


Рис. 13. Прототип сервісу дзвінків.


Рис. 14. Прототип автомобільного журналу.


Рис. 15. Прототип маркетплейса.


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

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

Реальний контент

Рис. 16. Демонстрація реального контенту для проекту «Маркетплейс».

Хтось з відомих проектувальників сказав: «Проектування — це багато в чому копірайтинг». Проектуючи з 2007 року, я багато раз в цьому переконувався на власному досвіді. Недостатньо зробити красиву картинку і наповнити її шаблонним текстом «Lorem Ipsum», так у нас на етапі наповнення сайту почнуть блоки плисти, текст не вміщуватися, захочеться ще щось вставити і т. д.

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

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

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

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

Сценарії поведінки і Customer Journey Map
Прототип створено, і він виглядає, як живий сайт. Але яким би досвідченим не був проектувальник, все в голові не втримаєш, і в прототипі будуть помилки, насамперед, неявні, логічні помилки. Для їх знаходження треба розробити сценарії поведінки і Customer Journey Map, а після прогнати наш динамічний прототип з них і знайти основні недоліки.

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


Рис. 17. Use Case для проекту «Маркетплейс».

Customer Journey Map — теж сценарій поведінки, його особливий вид. В цілому це маркетингова технологія, яку дуже зручно застосовувати для проектування. Ми повинні спланувати і потім відстежувати всі кроки клієнта до того, як він потрапив на сайт, і після того, як його покинув. По — справжньому, кожен користувач приходить на сайт з різних місць і з різними очікуваннями. Хтось йде цілеспрямовано купити наш продукт і все про нього знає, а хтось випадково потрапив на сайт з соціальних мереж. Також є й історія життя людини після сайту. Наприклад, коли він скористався нашим продуктом, і він йому сподобався / не сподобався, він може щось далі зробити залежно від свого досвіду. Побудувавши такі Customer Journey Map, ми зможемо підготуватися до будь-яких подій до і після сайту, зможемо зробити користувача лояльним і вбудувати його в мультиканальную комунікацію з проектом. Це ми повинні зробити для реальних клієнтів, тих, хто платить (буде платити нам гроші. В принципі, CJM можна підготувати ще на етапі аналітики і врахувати ідеї до прототипування, а на цьому етапі тільки перевірити себе.


Рис. 18. Customer Journey Map для проекту «Маркетплейс».

Метод важливий не тільки на етапі проектування, але і в живій проекті. На етапі проектування ми можемо тільки здогадуватися, а вже в працюючому проекті є можливість постійно ставити питання покупцям і точно знати їх шаблони поведінки. Також не забуваємо, що при розробці Customer Journey Map слід врахувати воронку продажів, визначити цілі на кожному етапі воронки, виділити точки взаємодії, особливо ті, які стосуються, або можуть стосуватися сайту, і виділити KPI, щоб розуміти, чого нам треба домогтися від наших покупців, а в кінці виділити проблемні місця і поліпшити їх. Це те саме слабка ланка, усунувши яке, вся система запрацює краще. Наприклад, нашою метою може бути збільшення середнього чека покупця шляхом допродаж супутніх йому послуг. Ось він купив телевізор, а його потрібно доставити, встановити, налаштувати і т. д. 10 років тому кожен покупець робив це сам, інтернет-магазин йому не пропонував такий широкий сервіс. Сьогодні багато магазини пропонують безліч додаткових послуг до основного продукту, і люди це купують. Як це було придумано? Відповідь очевидна: хтось почав спостерігати за покупцями і зрозумів, що вони в реальному житті замовляють додаткові послуги на стороні, але це не дуже зручно і можна запропонувати комплект. Так і народилася ця функція збільшення середнього чека, як і багато подібних ідей в сучасних веб-проектах.

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

В кінці цього етапу ми виправимо ряд помилок і доопрацюємо наш прототип.

QA і юзабіліті тести


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

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

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

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

Технічне завдання


Рис. 19. Приклад технічного завдання для проекту «Маркетплейс».

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

Структура ТЗ знову ж буває різна. Крім опису самого інтерфейсу, ми зазвичай включає такі блоки:

  • Архітектура сайту — опрацьовує архітектор
  • Вимоги щодо навантажень — опрацьовує архітектор і тім лід
  • Сервера та інфраструктура — опрацьовує системний адміністратор, архітектор і тім лід
  • Вимоги безпеки опрацьовує фахівець з безпеки і тім лід
  • Вимоги по SEO — опрацьовує SEO-шник і інтернет-маркетолог
  • Вимоги до дизайну — опрацьовує дизайнер
  • Вимоги до верстання — опрацьовує верстальник
  • Микроразметка — опрацьовує верстальник
  • UML діаграми робастності — опрацьовує проектувальник і програміст
  • Розмежування прав доступу опрацьовує проектувальник


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

Якщо не проробляти вимоги, зазначені вище?

  • Архітектура сайту — якщо її не проробити, з високою часткою ймовірності ми закладемо невірну архітектуру, це призведе до проблем масштабування проекту, і його доведеться переписувати.
  • Вимоги щодо навантажень — зазвичай роблять проект, а потім окремо тестують і оптимізують навантаження. Але якщо вимог немає, в архітектурі це не передбачено, то сайт рано чи пізно почне падати при зростанні відвідуваності, і відбудеться це в самий незручний момент.
  • Сервера та інфраструктура — теж саме, непродумана інфраструктура призведе до необхідності перенастроювання і падіння сайту.
  • Вимоги з безпеки — якщо у нас не буде вимог з безпеки, і цим ніхто не буде займатися, це неминуче призведе до зломів, наслідки яких будуть непередбачувані: від крадіжки даних до повного стирання сайту.
  • Вимоги по SEO — як часто ви чули від маркетологів, що сайт потрібно переробляти під вимоги SEO? Якщо у вас був хоча б один сайт, який ви просували, то з імовірністю 90% чули. Все тому, що створювали його без вимог до SEO, які мають закладатися саме на етапі проектування, а не пізніше.
  • Вимоги до дизайну — якщо ми не опрацюємо ці вимоги, то маємо ризик довго переробляти дизайн. Це взагалі саме слизьке, що може бути, так як у всіх різні вподобання, і всі вважають себе дизайнерами. Єдиний варіант знизити кількість переробок дизайну — це закласти вимоги.
  • Вимоги до верстання — сьогодні Google враховує безліч параметрів верстки. Це і адаптивність, і стандарти W3C і швидкість завантаження, і багато інші параметри. Якщо ми не закладемо вимоги до верстки, то сайт у нас буде погано індексуватися і погано відображатися на мобільних пристроях користувачів.
  • Микроразметка — якщо ми не зробимо її, то верстка у нас буде на суб'єктивний розсуд верстальника, а значить, сайт не буде правильно індексуватися.
  • UML діаграми робастності — це більше для програмістів, щоб вони нічого не втратили і знову ж таки не переробляли.
  • Розмежування прав доступу — теж саме, для програмістів, щоб не переробляти.


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


Рис. 20. Таблиця з правами доступу для проекту «Маркетплейс».

ТЗ — це досить об'ємний документ. Для прикладу можна подивитися частину ТЗ, яке ми розробляли, зокрема опис прототипу Маркетплейса. Дві сотні сторінок опису. Опис повинен бути конкретним і зрозумілим. Не можна допускати неточностей і двояких трактувань. Важливо описати неочевидні місця. Наприклад, рейтинг користувачів може виражатися в проектуванні однією цифрою, а насправді приховувати за собою складну формулу для його розрахунку. У документі обов'язково повинні бути посилання на конкретні сторінки прототипу і нарізка частин інтерфейсу.

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

В кінці цього етапу ми отримаємо повне ТЗ проекту, яке має мінімізувати ризики максимально, наскільки це можливо, і з статті ви самі зрозуміли, чому саме.

Маленький бонус

У статті я показав багато прикладів з проекту «Маркетплей», в тому числі прототип картки товару, і дав посилання на повний динамічний прототип. Після проектування будь проект передається на дизайн. І цей проект в дизайні виглядає ось так:

Рис. 21. Дизайн сторінки товару проекту «Маркетплейс».


Що повинно вийти в результаті?

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

Як ви вже здогадалися, це той етап, який робить ціла команда. Як мінімум це BI Analyst для аналітичної частини і UX / UI Designer для графічної. Але в якості консультантів на різних етапах потрібно залучати таких хлопців, як: Digital Marketing Manager — для опрацювання маркетингової складової і роботі над інтерфейсами, System Administrator — для розробки вимог до апаратного забезпечення, QA Engineer — для перевірки логіки прототипу, Software Architect — для розробки архітектури, Web Designer — для консультацій по інтерфейсу, Technical Writer — для розробки технічного опису проекту і ряд інших експертів.

Незважаючи на безліч описаних тут етапів, в цілому проектування — це не дуже довгий і витратний етап, принаймні, для досвідченого проектувальника. А якщо оцінювати його, як добру і майже єдину захист від переробок і помилок, то в результаті проектування економить багато часу і грошей власнику продукту. Я б сказав, що саме проектування має один з найбільших ROI у проекті. Зазвичай проектування застосовується для нових проектів, хоча його також можна застосовувати і для вже готових проектів, щоб значно поліпшити конверсію та інші базові KPI проекту. Правда, для вже працюючих проектів технологія буде інший, і це тема окремої статті. У будь-якому випадку, це ціла складна наука зі своїми правилами і фахівцями. Ми вчилися всією командою майже 10 років, і вчимося досі, набиваючи на шляху безліч шишок.

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

p.s. На днях у нас стартував курс по проектуванню від авторів статті: Проектування серйозних сайтів. Ще можна записатися на курс зі знижкою. Для цього пишіть на [email protected]

P. P. S. Щоб одержувати наші нові статті раніше за інших або просто не пропустити нові публікації — підписуйтесь на фан сторінки SECL Group: Facebook, VK, Twitter.

Автор:
Микита Семенов
CEO
Компанія «SECL Group»

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

0 коментарів

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