Ще одне докучливе есе про проектування, UX Guru
Проблема всіх есе про процес проектування – це те, що вони читаються як ханжі закиди. Я розумію, що вам не хочеться слухати про те, що для виконання роботи потрібна організованість. Все це цілком очевидно, але напрочуд важко робити день у день, коли ви хотіли б вивчати Framer і кодувати прототип. Тож я постараюся це врахувати.
Проблема із простотою
Раніше я вважав, що процес проектування відбувається так: Хтось про щось думає; потім вони просять мене намалювати ескізи; я малюю ескізи; ми їх кодуємо, проводимо тестування користувача, і налаштовуємо; потім запускаємо продукт.
Насправді, коли надходить запит, я зазвичай зайнятий іншим проектом. На той час, як я приступаю до роботи, доводиться поспішати. Потім я показую свої ескізи людям, і ми всі сперечаємося про дрібниці візуального дизайну. Всі зайняті, всі поспішають, і ми ще трохи сперечаємось. Потім дизайнерам набридає сперечатися, і вони починають розробляти те, що вважають найкращим.
Ми намагаємося врегулювати нашу суперечку користувальницьким тестуванням. Але ми не маємо чіткого уявлення про те, що тестувати, дослідники зайняті, і ми поспішаємо випробування. Зрештою ми розуміємо, що спроектували неправильний продукт. Коли пил укладається, я говорю щось на зразок: «Що трапилося — я думав у вас є план.» А вони кажуть: «О, а ми думали, що у тебе був план!»
Коли члени команди відчувають, що вони відстали, або не мають поняття, що буде далі, проблеми та розбіжності здаються непереборними.
За цимслідують непорозуміння та звинувачення. У більшості випадків, більш реалістичний план допоміг би нам цього уникнути.
Як багато часу це займе?
Зрештою, я став краще розуміти, на скільки затягнеться великий проект. Але все ще лишалася одна проблема: ніхто мені не вірив. Я міг передбачити, де виникнуть труднощі, але я не міг переконати людей вжити заходів, щоб уникнути їх.
Мало хто хоче дивитися на процес проектування у реальному світлі, щоб визнати, що він безладний, потребує співробітництва та компромісів. Простіше опустити голову, зосередитися на своїй роботі та сподіватися, що в когось іншого є план.
У спробі змусити людей вкладатися в більш реалістичні терміни, я почав аналітично ставитися до проектів, над якими працював, і став прозорим з приводу того, скільки займе проект часу. Я не хочу відбирати у вас задоволення виявлення власних термінів, але сподіваюся дати деяке уявлення про те, куди дійсно йде час, і чому варто очікувати деякого безладдя.
Відточування процесу у Facebook
Я приєднався до Facebook як дизайнер під час особливо швидких змін. Продукти, якими займався один дизайнер, раптово розбилися на величезні шматки інфраструктури, які підтримують сотні інженерів і приносять мільйони доларів доходу.
Тепер окремі дизайнери відповідають за дублювання частин головоломки, які разом повинні представляти цілісний продукт.
Було дуже цікаво знаходити найкращі практики, які б дозволили проектам ефективно розвиватися. Я працював із партнером, який займався дослідженнями та невеликою групою дизайнерів. Нашим завданням було зрозуміти, як різні групи та окремі люди себе організують.
Мивигадали спосіб, який не особливо відрізнявся від того, що ви читали в більшості книг або статей про процес проектування. Але наша модель приносила більше часу на початку процесу, який можна було витратити на зіставлення досліджень та вимог, продумування, тестування та відкидання ідей — по суті, все, що потрібно, для переходу від грубого плану до хорошого з найменшими витратами.
- Розуміння – Погодитись із проблемою, яку треба вирішити.
- Моделювання – Звузити мислення та описати концепцію візуально.
- Проектування - створення продукту
- Запуск — Тестування та координування з ринком.
Затвердження моделі
Я вважаю, що люди схильні мені вірити, якщо я приходжу до них з даними. На щастя, у мене вже є більшість потрібної мені інформації. З того часу, як я став менеджером з дизайну, я дивився, як працюють різні команди, і ретельно документував усе, що вони роблять.
Команди постійно надають звіти про стан роботи з короткими нотатками про ключові події своїх проектів протягом попереднього тижня. Я закликаю їх записувати лише важливі події, а не перераховувати все, що було зроблено.
Аналізуючи ці записи, мені вдалося зібрати картину виконаної роботи за попередні 6 місяців. Після ще 3-місячного відстеження наших проектів, у мене була картинка прогресу, досягнутого за 9-місячний період. Я зробив таблицю, в якій кожному проекту виділялася одна лінія, та відзначив основні події у житті кожного проекту, у тому числі:
- Коли ми вперше призначили проект дизайнера або контентного стратега.
- Коли ми нарешті домовилися про те, що ми творитимемо.
- Коли ми всі домовилися про конкретне одненабір ескізів.
- Коли дослідження було найкориснішим.
- Коли ми вважали проект закінченим. (Як правило, це відзначалося тестом або альфа запуском.)
- Коли ми запустили продукт.
Після того, як я відобразив все це в таблиці, я міг зробити крок назад і порівняти різні проекти, великі та маленькі, та їх конкретні часові рамки. У деталях кожен проект був хаотичним і різним. Але на макрорівні вони відповідали нашому теоретичному чотириетапному процесу:
Оскільки продуктові менеджери не бачили відмінності між етапами Розуміння та Моделювання, початкові плани команд щодо того, що включатиме дизайн були дуже схематичні. У результаті все зводилося до «зроби малюнок».
Коли я запитав продуктових менеджерів, скільки часу зазвичай займає "зробити малюнок" вони відповіли тиждень або два. На перший погляд це не здається дурним. Зазвичай, навіть із складними продуктами, дизайнери укладалися тим часом. Але дані показали, що наш звичайний час від «Призначити дизайнера» до «Узгодити начерки» складав близько 6-8 тижнів.
Щоб з'ясувати чому так відбувається, потрібно ще трохи детективної роботи.
Прокляття виразу «майже готове»
Я став уважно спостерігати за командами, які були на ранніх стадіях проектування. Я був присутній на їхніх щотижневих зборах, і спостерігав, як вони намагаються дійти згоди. Процес розпочинався добре. Вони визначали, чого прагнули, і що проектуватимуть.
Але коли команда починала говорити про дизайн, виникали несподівані суперечки та проблеми. Розбіжності навколодрібні деталі виявилися величезною проблемою. Члени команди ходили колами, поки хтось не знаходив рішення, яке було досить близьким до того, чого вони хотіли, і намагався закрити дискусію, щоб розпочати проектування.
Це знову і знову призводило до нових проблем та суперечок. Оскільки команда вважала, що нариси «майже готові», вони продовжували копатися у деталях.
Вони не помічали, що насправді не погоджуються щодо основних цілей проекту.
Я бачив команди, які настільки застрягли у цьому кругообігу, що вони не могли просунутися далі та кидали проект.
Творчий цикл та смертельна спіраль
Фаза розуміння потрібна не для того, щоб задовольнити креативність дизайнера. Цей час, за який команді, потрібно належним чином висловити свої ідеї, і навести їх у форму, в якій вони можуть бути реально оцінені. Цим, зазвичай, займається як дизайнер. Всі повинні висловити свої потреби та думки, а потім переглядати набори ескізів, щоб ці думки оцінити.
Якщо я знову і знову повторюю якийсь дизайнерський процес, який повинен допомогти висловити нову ідею, то це недаремно витрачений час. Але якщо я постійно повертаюся назад, щоб, наприклад, «подивитися, як це буде виглядати з чекбоксом, замість випадаючого списку» – це означає, що я керуюся речами, що не належать до справи, уникаючи реальних проблем, а також той факт, що ми так і не домовилися, що збираємося робити.
Я знайшов два основні способи, які повинні допомогти командам уникнути цих маленьких смертельних спіралей. Перший - більше дбати про те, щоб пояснити, що потрібно дизайнеру для того, щоб створити корисні начерки. Це зазвичай прирівнюється до чіткого відділення процесу з'ясування того, що ви намагаєтеся досягти (крокрозуміння) від виконання нарисів (крок Моделювання).
Інший спосіб - зробити карту, будь то діаграма Ганта або інша візуалізація. Використовуйте свої навички дизайнера, щоб показати де в процесі ви знаходитесь. Покажіть її іншим членам команди та переконайтеся, що ви знаходитесь в одній з ними точці.
Як би страшно це не здавалося, краще визнати відмінності в очікуваннях раніше, ніж виявити їх пізніше.
Коли всі знають, що вони далеко від фінішної прямої, вони зазвичай перестають до неї рватися.
Це може здатися простим, але те, де ви знаходитесь насправді, на відміну від того, де б вам хотілося бути, радикально відрізняються. Це не тільки позбавить вас головного болю, але також допоможе вам створювати продукти, які краще послужать людям, для яких ви їх розробляєте.