Як ми проектуємо і прототипируем всяку фігню



Головний ворог роздовбайства — план.

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

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

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

Може здатися, що прототипировать — це ніби як не дуже потрібно. Херак-херак — і продакшн. Насправді, це дуже важливо в будь-якому процесі; наприклад, за заповітами юзабелистов — це 70% роботи. Питання тільки в тому, як це можна робити.

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

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


На цьому аркуші картону в підсобці ми намалювали одну з найважливіших схем взаємодії

Якщо б ми одразу почали це прототипировать в тому ж Візіо у вигляді схеми процесів на ноутбуці, то пішло б набагато більше часу. Метод Бетмена хороший тим, що можна записувати і будувати схему зі швидкістю мови. Тобто у реальному часі без відволікання на процеси. Вже потім, після обговорення, хтось один може вибудувати струнку структуру. А зараз «ні, все не так, ось тут треба інакше» — це один рух, а не двадцять.

Виходить щось приблизно таке (це схема іншого процесу, дуже проста):



Але повертаємося до паперу. Ось мій робочий стіл, на якому лежить коробка з часто потрібними мені речами для прототипування ігор. Найголовніше – велика купа порожніх карток різних розмірів, генератори випадкових чисел, таймери і фішки. Загалом, якщо у вас є купа порожніх карток, ви можете зробити що завгодно. Треба відзначити, що у нас з авторами ігор неодноразово велися суперечки з приводу підходу до прототипу. Я дотримуюся методів Rapid Prototyping – про них розповідає, наприклад, дядько Скотт Клеммер з Курсеровского курсу HCI.



Поле малюю прямо на столі, благо на ньому завжди А1 замість скатертини. На цьому ж столі (він стоїть окремо від основного робочого) може скупчитися досить багато записів, які потім будуть перенесені в todo, або просто будуть нагадувати про контексті.

Зміст швидкого прототипування такий: треба якомога частіше перевіряти гіпотези. Тому прийшла ідея – відразу ж взяли і намалювали-написали на картках що хотіли (10 хвилин) – і пограли. Зібрати прототип на комп'ютері – мінімум півгодини, плюс потім ті ж 10-15 хвилин на наклеювання на основу або вставку папірців у протектори з іншими картами. Чим коротше ітерація, тим легше перевірити багато різних гіпотез «на льоту». І тим більше все можна вигадати по ходу, не тримаючи в голові відразу всю картину, а акцентуючись на деталях. Це означає продуктивність. Я знаю авторів ігор, мучать свої проекти за 5-7 років. Думаю, приблизно рік вони б заощадили на розумінні того, як ефективніше прототипировать.

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

Гра прототипируется мінімально, до стану демки. Наприклад, якщо ми б робили вікторину, то назбирали б не тисячу запитань, а штук двадцять, щоб зіграти два-три кола.

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

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

Наступний крок після того, як є розуміння базової збірки – деталізація до межі.

Ось, наприклад, прототип для сайту mosigra.com на передфінальної стадії:



Спочатку це був wireframe по типу такого:



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

Ось цей шматок сторінки збирався, мабуть, три дні:



Справа в тому, що знайти усі дані про усі потрібні ігри (елементарно скласти їх список для початку) – завдання не сама тривіальна.

І дизайнер, верстальник, і коректор хочуть бачити все відразу. Тому що, очевидно, якщо зібрати контент до початку робіт, потім результат буде однозначна. Ідеальний прототип – це майже результат, тільки менше і іншого. А якщо віддати дизайнерові блоки з Dolorem Ipsum, при заповненні може зустрітися будь-який сюрприз. Власне, вони і зустрілися б – як в старому анекдоті про «концепція змінилася», напрям думок по мірі викопування нових фактів і висловлювань відділів про те, що вони хочуть бачити на сторінках, змінювалося.

Так, ось ще – внутрішні узгодження. Справа в тому, що звичайні люди не вміють читати недеталізовані прототипи кшталт «тут буде те-то». Треба просто взяти і прикласти. Я навчився цього ще коли креслив зрозумілі для наших клієнтів схеми підключення супутникових систем на турбазах (не було питань, де і як піде кабель, як його маскувати і так далі), потім закріпив навик, коли ми кілька разів погоджували сайти. Тепер можу сказати впевнено – весь контент на прототип, тому що потім половину уріжуть. Це щоб люди в ланцюжку не робили зайву роботу. З іншого боку, з'явиться щось нове точно, що інакше буде описуватися так: «цього не було в ТЗ, платна доробка». А воно нафіг нікому не треба. Зрозуміло, що можна закласти 10-20% на такі непередбачені ситуації (вони трапляються завжди), але чим більше і щільніше ви підготуєтеся на березі – тим краще.

У підсумку я збирав матеріали, факти, графіки, перекази і перевіряв, що всього вистачає приблизно 6 тижнів. І тільки 3 тижні сайт був в роботі після цього. Причому ніяких питань не було: і дизайнер, верстальник бачили, як воно повинно бути. Заносили конкретний контент. Якщо були сумніви – показували відразу «чистий» прототип, щоб вибрати з двох варіантів (траплялося одного разу на початку і один раз при визначенні деградації верстки для мобільних телефонів). Всі.

Стан перед версткою:


І взагалі, подібний підхід виявився дуже зручний в плані менеджменту. Зробив прототип – один файл відправив у дизайн, другий – в переказ, третій – коректора. Всі параллелится при мінімумі рухів.

Прототипировать можна що завгодно
Я обожнюю масштабовані WYSIWYG-інтерфейси, які дозволяють в одній робочій середовищі збирати проект. Потрібно писати текст – будь ласка, клікнув і прямо на полі. Потрібно вставити картинку – ось вона, прямо тут, ніяких двозначностей, чітке розуміння, що і як ляже в більд. Давним-давно я починав з Aldus (потім компанії Adobe PageMaker, потім перестрибнув на Візіо. Але користуватися можна будь-якими інструментами: наприклад, Саша, що працює з планограммами, обожнює AutoCAD, виробничники іноді надсилають малюнки в XLS, в дорозі легко використовувати Balsamiq Mockups.


Проектна область, один з робочих столів

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



Дуже легко показувати принцип бага:



Легко обговорювати макети:



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



А ось як це виглядає в друку:


до Речі, так, на всяк – Таксі – це гра для навчання базовим навичкам алгоритмізації, і ми ще в минулому році відкрили її компоненти в Creative Commons, щоб можна було друкувати вдома.

Ось сирої прототип ще одного розвиваючої гри:



Типовий вигляд нашої ніби-як-газети, яку ми кладемо в замовлення, в прототипі:



Схема процесів в інтерфейсі:



Частина складання ТЗ на розробку зовнішньої реклами:



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

А ось історія прототипування карти Нефариуса (ось тут детальніше про процес). Ось що надіслав автор, стадія першого наближення:



Файли з техзавдання (тут перераховані всі структурні компоненти, плюс є базові малюнки «аби щось було»):



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



Результат:



Шматочок планограми викладки в магазині (навігація по стіні):



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

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



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



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

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

Загалом, якщо є можливість, прототипируйте все. Це добре дисциплінує. І прискорює проекти.

Розкажіть, будь ласка, як прототипируете і плануєте ви, це дуже цікаво.

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

0 коментарів

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