Апр. 17

User Testing, або Як дизайнер може змінити проект

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

Немає кращого тестувальника, ніж новачок, який ще не надів окулярів-фільтрів. Особливо якщо цей «новачок» — UI/UX-дизайнер. У цій статті я б хотіла поділитися своїм досвідом того, як дизайнер може вплинути на розвиток проекту й вивести його на новий рівень завдяки використанню User Testing (UT).

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

Images by Zena Assi

Усвідомлення проблеми

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

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

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

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

За весь час існування проекту User Testing не проводили ніколи, бо ніхто не знав, наскільки це корисно й чи справді потрібно. А проте застосунок мав реальних користувачів, які використовували його щодня.

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

Головна проблема в тому, що дизайн у наших реаліях не може стати high-priority-завданням. Його переосмислення, покращення й разом із тим User Testing завжди відкладатимуть «на завтра», бо сьогодні купа багів й основна фіча раптом припинила працювати, і дедлайн ось уже зараз. Це треба прийняти, але можна й змінити.

Я почала звертатися (читай «проїдати» мозок) до всіх, хто міг мені допомогти, щоб провести User Testing. До речі, це взагалі здавалося мені настільки очевидним і потрібним, що я не могла змиритися з тим фактом, що це треба пояснювати й когось переконувати. Чому для всіх очевидно, що на проекті потрібні QA чи релізи? Для всіх було дикістю, коли я говорила про User Testing. «Ви серйозно?» — думала я, але вголос мило пояснювала, чому нам це треба.

Проте жодного разу ніхто не відмовив мені й ніхто не сказав відчепитися зі своєю ідеєю, не сказав, що ми не маємо на це часу. Але ніхто й не відповів: «Так, нумо! Що тобі для цього треба?» Я лише чула, що така ідея є, але це в перспективі.

Початок метушні

Я переконана, що немає сенсу бути на проекті, який не в кайф, яким ти не можеш зробити чиєсь життя зручнішим. Я завжди всередині злюся, коли чую, як хтось принижує свій проект. Хочеться сказати: «Зміни щось або йди!»

Єдиний раз за участь у проекті в мене з’явилася можливість поговорити з безпосереднім замовником, коли він приїхав до нас із візитом в офіс. Для зустрічі з ним я підготувала чіткий план просування User Testing:

для чого це треба;
що це нам дасть;
команда;
витрати.

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

Активні дії

Я переконана, що тему з UT не можна закривати ніколи, навіть коли здається, що шансів немає й «завтра», на яке намічено все, ніяк не настає. Замовнику не до цього, і доступ до реальних користувачів — як мрія. Але рано чи пізно випаде мить, яка дасть змогу повернути проект у правильне русло. Головне — не пропустити її, сидячи зі складеними руками.

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

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

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

Виникає логічне питання — куди з цим далі йти? Часу обмаль, адже команда повинна вкластися в дедлайн та вже на повну працює над web-версією. Я вирішила відправити клієнту мою пропозицію із альтернативною версією, додавши до нього величезний опис кожної зміни (окремо виділила User Testing напрямок). У копію листа я додала всіх, з ким варто було узгодити це рішення попередньо. Напевно, варто додати, що такий вчинок максимально неправильний та нераціональний — насамперед він містить колосальну кількість ризиків та наслідків як для мене, так і для проекту. Було важко визначити, чи відповідало моє рішення всім цим ризикам. Але в моєму випадку я розуміла, що стандартний процес узгоджень катастрофічно довгий і велика ймовірність того, що ідея буде відкладена в світле майбутнє і вона не потрапить до єдиної людини, яка може змінити хід проекту. Одним словом, не повторюйте ці дії вдома :)

Проведення User Testing

За кілька днів внутрішньої паніки й передчуття, що проектові вже потрібен новий дизайнер, я одержала найнесподіванішу відповідь із можливих. Відповідь була «так», «так» на всі пропозиції, «так» і на User Testing, «так» на зміни.

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

І от настав час мого ідеально світу. Зрозуміло, що UT мені б хотілося бачити в інших умовах і за моїми правилами. Найкращий варіант — коли можна стежити за роботою в реальному середовищі користувачів:

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

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

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

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

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

Я змогла перевірити всі свої гіпотези, які виклала в альтернативній версії застосунку. Але головне — з’явилося багато ідей, як сервіс можна вдосконалити. Кілька блоків було цілком переосмислено й спрощено. Змінився сценарій роботи з пацієнтами та організаціями, а також принципи сортування й фільтрування. Особливу увагу було приділено роботі з клавіатурою, додано гарячі клавіші, кілька меню об’єднано та реорганізовано. З’явилася вкладка з індивідуальним налаштуванням інтерфейсу, і, звісно, виконано ще низку побажань користувачів. Це вже було безцінно.

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

Комунікація — це важливо

У межах проекту треба підтримувати позитивні взаємини. Навіть якщо йде міні-війна, вона має бути професійною й приязною.

Хотілося б тут зупинитися та трохи більше розповісти про важливого персонажа «гри» — бізнес-аналітика від замовника, через якого проходили всі зміни й із яким я безпосередньо комунікувала щодо всього. Головною його метою був стабільний розвиток проекту, і, звісно, я не одержала відкритого підтримування всіх моїх ідей щодо змін. Я зрозуміла, що без особливого підходу зміни можуть вплинути на наші взаємини. Тому розробила окремий «план»:

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

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

Їм байдуже до змін, головне, щоб таски були на завтра й на післязавтра... Їх легко розпізнати за фразами: «Що за фігню ти придумала?», «Для чого тобі це треба?», «Тобі нічого робити?» Вони йшли своєю дорогою й виконували поточні проектні завдання.
Зациклені на часових межах. Коли пропонуєш якусь зміну в проекті, перше, що кажуть представники цієї групи: «Буде швидше, якщо ми зробимо ось так». Для них у пріоритеті знайти вирішення, яке можна буде швидко й просто втілити, зручність і корисність другорядні. Такі люди корисні в команді, але я вирішила своїми ідеями з ними не ділитися, розуміла, що частину моїх ідей відсіють через нестачу часу, а зараз завдання зробити зручно, а на це потрібен час.
І група, представники якої дискутувати, пропонувати й шукати підводне каміння. З ними можна було говорити та ділитися ідеями. Я дуже вдячна за їхню підтримку й люблю їх після всього ще більше. Круто, що сюди потрапили люди з різних стеків, і в мене була доволі повна картина в дискусіях. Тут я помітила цікавий, але передбачуваний момент: що довше хтось на проекті, то менша його віра у світле майбутнє. Мене не підтримали ті, хто починав проект, але дуже допомогли нові люди, які встигли побути з проектом деякий час.

Результати та хепі-енд

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

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

Сторінки були в Sketch із максимальною кількістю зв’язків, щоб можна було повернутися з будь-якого екрана на потрібний будь-коли під час презентації. Я розбила кожну сторінку на логічні блоки з описом змін і причин, через які їх було впроваджено. Між блоками запропонувала робити паузи на обговорення та дискусію. Так ми рухалися поступово всіма макетами. Цей варіант мені подобається більше, ніж презентація всього одразу й далі нескінченне обговорення.

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

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

У статті використані ілюстрації ліванської художниці Zena Assi, серія «My City». Ця серія чудово демонструє структуру та «організованість» складних проектів. Можливо, інколи корисно видалити все і зробити заново, знаючи, як це має функціонувати, а не набудовувати нову фічу на без того хитку конструкцію.