8 историй о прототипах

“Надо попробовать” стало моей мантрой при работе над любым проектом. Чем быстрее получается сделать то, что можно потрогать, потыкать, посмотреть и ощутить, тем лучше. Иногда приходится доказывать необходимость создания прототипа другим участникам проекта, брать на себя организацию или делать самому. Но без прототипов никуда.

Говорить о прототипах сайтов и мобильных приложений, создаваемых в inVision и других подобных инструментах, я не буду. Уверен, вы знаете и часто применяете их в своей работе. Итак, поехали.

1. Симкомат из картона. Быстрая проверка идеи

Симкомат — это киоск по автоматизированной продаже симкарт. Человек платит деньги, сканирует свой паспорт, подписывает договор и забирает симкарту, которая уже зарегистрирована на него.

Внутри симкомата много устройств: сканеры, принтеры, купюроприемник, кардридер, симдиспенсер и другие. Когда мы проектировали новую версию симкомата, мы планировали сделать один универсальный корпус. Чтобы в него можно было устанавливать разный набор этих устройств в зависимости от пожеланий заказчика. Нам нужно было прикинуть, возможно ли это в принципе. Влезут ли все устройства в корпус? Сможем ли мы изменять конфигурацию в зависимости от потребностей ? Будет ли это удобно пользователям? Промышленный дизайн и чертежи готового изделия на этом этапе нас не интересовали.

Сначала мы планировали использовать цифровую среду моделирования: CAD или 3DSMAX, но в итоге решили сделать проще и использовали картонные коробки.

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

Благодаря макету мы смогли попробовать десятки вариаций. На все ушел один вечер. Боюсь представить сколько времени мы бы потратили, если бы делали модель в “цифре”.

Я написал две подробные статьи об интерфейсах в этом проекте. Читайте тут: “Особенности работы в железном проекте. Часть 1” и “Часть 2”.

2. Когда устройства нет, а потрогать хочется

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

Они дают возможность ощущать. Чувствовать устройство в руках: его размер, вес (для этого использую пластилиновый утяжелитель). Представлять, как я с ним взаимодействую. В картонки можно тыкать пальцами, “открывать” и “закрывать” их, “смотреть” как реагируют на мои действия “индикаторы”.

Здесь, как и в ситуации с симкоматом, я не занимался промдизайном, а проектировал только некоторые функциональности и систему обратной связи.

3. Уточняем требования к автомобильному дисплею с помощью листа бумаги

Когда я работал в компании Charge, которая занимается разработкой электрических грузовиков, нам требовалось сделать пользовательский интерфейс для тачскринов в кабине. Но на тот момент было непонятно, какого размера и ориентации должны быть дисплеи, потому что грузовик только начали разрабатывать.

Делать графический интерфейс, не зная, на каких устройствах он будет использоваться, не совсем правильно. Чтобы понять, с чем нам предстоит работать, я нашел грузовик, похожий по размерам на наш и исследовал кабину. Нарезал из плотной бумаги несколько размеров “дисплеев”, нарисовал примерный вид интерфейса (концепт у меня уже был) и прикладывал их на переднюю панель.

Изначально мы планировали сделать большой тачскрин “а-ля Тесла” :). Но стало ясно, что подобный дисплей нельзя использовать. Посадка водителя в грузовике совсем иная, нежели в легковом автомобиле: другой угол взгляда на приборную панель, положение относительно руля, угол наклона рулевой колонки, положение руки относительно панели и пр. И если просто поставить большой вертикальный дисплей без внесения существенных изменений в интерьерные формы, то пользоваться им будет очень неудобно.

Таким образом мы поняли ограничения и уточнили требования к дисплею за пару часов, хотя до этого мы рассуждали и спорили довольно долго.

4. Узнать, как ведут себя люди с системой, где единственный фидбек — свет

Сейчас я работаю над проектом “Лайтпак 2”. В нем много необычных решений, поэтому пользовательское тестирование важно было провести на самых ранних этапах.

“Лайтпак” — это устройство, которое подсвечивает стену за телевизором, когда вы его смотрите. Цвет подсветки зависит от изображения на экране. Очень похоже на Philips Ambilight, только лайтпак вы можете прикрепить на свой телевизор или монитор, без необходимости покупать новый Philips. Устройство может дополняться пятью или десятью светильниками в виде кубиков. В видео хорошо все показано:

Чтобы посмотреть детали можете глянуть кампанию на кикстартере.

Кубики называются “пикселями” и это довольно необычные устройства с точки зрения пользовательского взаимодействия. Они могут работать вместе с лайтпаком во время просмотра фильма, т.е. их свет зависит от того, что происходит на экране. Могут работать, как единая система динамического освещения без участия телевизора, могут выступать в роли отдельных светильников. А самое интересное, что они являются устройством ввода. Иными словами — вы можете с их помощью управлять некоторыми функциями системы. Постучите дважды — и он будет гореть как ночник.

Есть одна сложность: для того, чтобы пиксели работали синхронно с изображением на телевизоре, лайтпак должен знать, где находится пиксель относительно этого телевизора. Настройка этого положения происходит с помощью пикселя. В ролике можно посмотреть, как это работает:

Тестирование такого необычного взаимодействия для продукта жизненно необходимо. Финальная версия пикселя в то время еще не была готова, поэтому мы сделали прото-версию силами “дизайн отдела” с минимальным привлечением инженеров. А наш промдизайнер и продукт менеджер сделал прошивку для прототипов пикселей.

Представьте себе тестирование взаимодействия с физическими предметами и световым фидбеком! Это был самый интересный эксперимент, который мне доводилось организовывать и я планирую написать отдельную подробную статью про это.

Я использовал прогрессивный метод тестирования, когда тест проходит в несколько этапов для одного человека. Так мы смогли собрать максимум данных:

1. Как человек понимает устройство нашей системы, как по его мнению она должна работать;
2. Как человек настраивает систему без наших подсказок, если не понимает полностью устройство системы;
3. Как взаимодействует, если понимает принципиальное устройство системы;
4. Справится ли при наличии письменной инструкции.

В итоге тест помог нам выявить узкие места нашей системы. Рассказал о ментальных моделях, на которые опираются люди при работе с ней. А за счет того, что мы оперативно, после 2–3 респондентов, вносили правки в устройство системы, мы смогли проверить много гипотез и найти много интересных решений. Тесты продолжаются.

5. Программный прототип, который позволил экспериментировать со звуками

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

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

После того, как я проработал контексты, сценарии, систему сущностей, событий и необходимого фидбека, подошло время разработать непосредственно сигналы (звуковые и световые). В качестве устройства вывода звука у нас была обычная пищалка с возможностью менять частоту (высоту) звука. Проектировать звук умозрительно тяжело. Хотя можно было бы написать в техзадании “при нажатии на кнопку такую-то устройство пищит дважды” и надеяться, что разработчик все остальное сделает сам. Но если углубляться в детали, то возникает очень много вопросов. Как пищит, на какой частоте? Какая пауза между сигналами? Какова продолжительность самих сигналов? Как человек отреагирует на эти сигналы. Будет ли его восприятие соответствовать тому, что нам нужно? Тут я намеренно опускаю вопросы более высокого уровня, касающегося UX, например “а надо ли вообще пищать в данной ситуации?”

Если отдать сырое описание программисту, потом придется многократно править каждый элемент в готовой прошивке. А это очень неудобно и дорого. А у меня, как дизайнера, будет мало возможностей для экспериментирования. Мы поступили так: я установил софт, в котором разрабатываются прошивки для устройств и попросил программиста сделать специальную прошивку для моих экспериментов. Идея в том, чтобы я сам мог программировать команды для устройства: задавать высоту звуков, интервалы, длительность звучания и пауз, цвет LEDов и так далее. Но при этом у меня были простые программные функции без необходимости глубоко погружаться.

Итого: несколько часов программиста и я получил прекрасный, хоть и с ограничениями, инструмент. Это позволило мне экспериментировать и найти хорошее решение не отвлекая инженера. Результат при этом не нужно было описывать словами, все было в коде.

6. Попробовать свои силы в разработке игры

Недавно я заинтересовался программированием игр. Для обучения решил освоить относительно простой движок GameMaker. Я не был уверен в своих силах, поэтому не стал планировать создание законченной игры. Вместо этого сделал “песочницу” для экспериментов, в которой можно пробовать все, что захочется. Начал с механики перемещения, системы колизий, затем перешел к управлению “персонажем”. Вот видео первого прототипа:

Целью было попробовать максимальное количество этапов создания игры с тем, чтобы понять насколько это сложно и реально ли сделать игру полностью своими руками. Это моя детская мечта. Дальше я перешел к рисованию, анимированию, программированию анимации, программированию логики. В итоге все-таки подобрался к попытке сделать осмысленную игру, т.е. заняться геймдизайном. Оказалось, что геймдизайн — самая сложная часть! В основном из-за противоречий с самим собой :)

“Песочница” помогла мне оценить масштабы и сложность всего, что скрывается за понятием “сделать игру”. Открывались аспекты, которым не придавал много значения. Например, нетривиальной и интересной задачей оказалось проектирование и программирование поведения камеры, следящей за персонажем. Вот в каком виде у меня сейчас прототип:

Итого: сложно, дико интересно, буду копать дальше.

7. Как прототип помог завершить проект

В этой истории прототип выполнял две задачи: посмотреть, как оно выглядит вне экрана монитора, и мотивировать нас продолжить заниматься проектом.

Мы с Ольгой, моей женой, делали книжку-сувенир для иностранных туристов. В ней были иронично описаны и проиллюстрированы русские традиции вперемешку с предубеждениями иностранцев о России.

В какой-то момент у нас совсем не осталось сил продолжать работу и я буквально заставил Ольгу напечатать книжку в реальном размере на хорошей бумаге (мог бы и сам напечатать). Хотелось почувствовать “вот оно, оно уже близко и оно классное”.

Помогло. Сейчас мы напечатали уже второй мини-тираж, а книжка продается в нескольких магазинчиках в Питере.

Сайт книжки http://www.travel-souvenir.ru/

Купить ее можно в “Подписных изданиях”

8. Стол-трансформер удовлетворяет любопытство

Как-то я решил работать стоя. Для этого есть специальные столы, которые можно поднимать и опускать. Но стоят они приличных денег. Чтобы понять, надо ли оно мне, я соорудил простую конструкцию и пару дней поработал стоя. Я мог ставить монитор вниз и иногда это делал.

Эксперимент показал, что стоять не всегда удобно, и менять положение хочется довольно часто. А кайфа маловато.

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

У меня всё. Делайте прототипы. Больше, быстрее, смелее.

Если вам нужно спроектировать интерфейсы или продукт целиком, то вы можете обратиться ко мне. Я работаю над софтовыми и хардварными продуктами. Портфолио на моем сайте.

Почитайте другие мои посты на тему UX и проектирования интерфейсов. Ну и поделитесь в фейсбуке, если понравилось.