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

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

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

Основні варіанти прототипування

Прототипування має безліч різних варіантів. Проте всі методи якоюсь мірою засновані на двох основних типах.

Швидке прототипування

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

Еволюційне прототипування

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

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

Переваги та ризики прототипування

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

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

  1. Ризик недостатнього аналізу. Концентрація зусиль на обмеженому прототипі може відвертати увагу розробників від належного аналізу вимог до повної системи.
  2. Ризик змішування прототипу та готової системи в уявленнях користувачів. Користувачі можуть подумати, що прототип, який насправді передбачено «викинути», і є основою майбутньої системи. Це може призвести до двох протилежних негативних ефектів. По-перше, користувачі можуть очікувати від прототипу більш точної поведінки, а не виявивши її, — розчаруватися в можливостях розробників. По-друге, наявність швидко розробленого прототипу може створити враження, що «майже вся робота вже зроблена», і цим стимулювати спроби невиправдано скоротити час та/або бюджет розробки.
  3. Ризик втрати часу на створення прототипу. Ключова властивість прототипу — те, що він створюється швидко. Якщо розробники витрачають час на створення надто складного та функціонального прототипу, вони втрачають переваги від застосування прототипування взагалі.

5 рівнів прототипування

Модель прототипування, яка допомагає розробляти ефективні системи та зрозумілий дизайн, була створена на початку 2000-х Джессі Гарреттом і має назву «5 рівнів UX». Проста для розуміння і максимально наочна, вона чудово ілюструє процес розробки будь-якої системи й допомагає визначитися з тим, що саме потрібно вашим користувачам. Базою для моделі стала діаграма, за допомогою якої Гарретт зумів показати зв'язок між різними підходами до дизайну в рамках проєктування користувацького досвіду.

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

Рівень стратегії (Strategy)

Найбільш абстрактний і концептуальний рівень. Тут описуємо причини й цілі створення продукту, вивчаємо аудиторію, робимо припущення. На основі цілей створення продукту окреслюємо типові user stories, передбачені у його використанні (як буде використовуватися продукт, в яких умовах).

З'ясовуємо, наскільки корисним буде продукт і які завдання користувачі зможуть вирішувати завдяки йому. Відповідаємо на такі запитання:

  • Для чого ми створюємо продукт?
  • Які цілі ми перед собою ставимо?
  • Хто наші користувачі? Для кого ми робимо продукт?
  • Які завдання ми допоможемо вирішити користувачам?
  • Чому вони користуватимуться саме нашим рішенням (визначаємо killer features продукту на підставі аналізу продукту конкурентів)?

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

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

Рівень можливостей (Scope)

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

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

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

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

Рівень структури (Structure)

Третій рівень передбачає опрацювання досвіду взаємодії користувача з продуктом. Розробка інформаційної архітектури та проєктування користувацького досвіду передбачає відповіді на такі запитання:

  • Як допомогти користувачеві вирішити завдання за мінімальний час і кількість кроків?
  • Чи зрозуміла архітектура проєкту користувачам?
  • Чи відповідає дизайн очікуванням користувачів?
  • Чи можна безболісно змінювати архітектуру за необхідності?

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

Тестування архітектури — процес набагато складніший, ніж концептуальні дослідження. На цьому етапі необхідно проводити usability-дослідження, A/B та Side by Side тести, тест привабливості, тестування методом спільного дизайну. Результат — розроблена з урахуванням користувацького досвіду інформаційна архітектура, що пройшла перевірку на реальних користувачах з-поміж вашої цільової аудиторії.

Рівень компонування (Skeleton)

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

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

Список далеко не повний. Основне завдання цього етапу — звести всю роботу попередніх рівнів у загальну систему. Потрібно перевірити, наскільки результат відповідає очікуванням користувачів, власників і розробників продукту. На цьому рівні ми проводимо той самий комплекс досліджень, що й під час проєктування архітектури та користувацького досвіду, але вже більш орієнтуючись на загальні враження від продукту. Це знову usability-дослідження, A/B тестування, Side by Side тести, тест привабливості, спільний дизайн, інтерв'ю. Результат — перевірений на реальних користувачах прототип продукту.

Рівень поверхні (Surface)

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

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

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

Зауваження можуть стосуватися коректного відображення на різних типах пристроїв — планшети, телефони, а також у різних положеннях пристрою — альбомному/портретному. Це також можуть бути вказівки щодо обмеження відображення елементів на певних типах пристроїв через конструктивні особливості. Наприклад, коректне відображення з урахуванням «шторки» iPhone X, на якій розміщені фронтальні сенсори.

Що ще почитати на цю тему:

Створення мобільного застосунку — від ідеї до запуску
Гайд для замовників з детальною покроковою інструкцією для розробки мобільного застосунку. Містить усі ключові етапи реалізації застосунку.
Просто про фриланс, штатну роботу і не тільки: блог FreelancehuntDeniel Sonis

Етапи прототипування мобільних застосунків

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

  • userflow,
  • мальовані прототипи (sketches),
  • шаблони дизайну і колірні палітри,
  • дизайн (design),
  • анімований прототип застосунку,
  • фінальний рендеринг макетів (усі фінальні екрани готові до розробки).

Поговоримо детальніше про основні етапи.

Userflow

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

Sketches

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

Прототипування

Після створення userflow для кожного екрана починаємо роботу з прототипами екранів. Прототипи — це низькодеталізовані начерки застосунку — ескіз чи схема того, де розташовуватимуться зображення, ярлики, кнопки та інше. Тобто ескіз того, як застосунок працюватиме. На цьому етапі проєктування вдалою ідеєю є використання лекал для малювання каркасів. Робота за допомогою лекал, як-от UI Stencils, економить час і дає непогану робочу ділянку для макетування та нотаток.

Іншим, більш лаконічним варіантом є друк форми екрана пристрою на аркуші паперу.

Після створення прототипів, використовуючи додаток Pop, можна зробити знімок малюнків і отримати клікабельний прототип, зв'язавши всі екрани за допомогою кнопок. Для автоматизації процесу створення прототипів можна скористатися сервісом iphonemockup.lkmc.ch, що дає змогу конструювати прототипи, як на папері, у вигляді схематичного зображення елементів управління чи стилізованого «від руки».

Дизайн

Переходимо до використання програмного забезпечення для створення дизайну: це має виглядати реалістично та бути схожим на реальний застосунок. Існують програмні засоби розробки та інструменти для створення дизайну. Найбільш часто для дизайну iOS використовують інструменти Sketch та Adobe Photoshop. Також популярні Figma та InVision App.

Для заповнення візуальних контейнерів доцільно використовувати стокові графічні зображення, які поширюються під вільними ліцензіями сервісами Pixabay, Shutterstock, Adobe Stock Photo, VectorStock.

Щоб надати рендерам додаткової стилістики для демонстрації клієнту, можливе використання сервісів, що додають фонові рамки: MockUPhone, ShapeItApp, mockDrop, Dunnnk, MockupsJar та інші.

Стайл-гайди (Style Guide). Упродовж усього процесу прототипування, особливо, для мобільних інтерфейсів, необхідно дотримуватися стайл-гайдів (для iOS це Apple Human Interface Guidelines). Вони регламентують загальні практики розміщення елементів управління на екрані, порядок екранів, ієрархію вікон тощо. Залежно від платформи — iOS, Android — стайл-гайди можуть відрізнятися, наприклад, в аспектах використання різних елементів управління.

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

Замість висновків

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