Зачем усложнять?
Зачем делать сложный прототип сервиса, если можно сделать простой? Ведь заказчик в большинстве случаев даже не заметит разницы. А если и заметит, то можно доработать только те моменты, на которые он указал. И дальше втыкать в Netflix.
Коль вы согласны с этим, закрывайте пост и отписывайтесь нафик от канала - вы безнадежны, не тратьте время. С остальными же мы разберемся, зачем нужно засовывать в прототип максимум и почему богоподобные Sketch/Figma/XD так и останутся пока уделом простых проектов и UI-дизайнеров.
Если проектировщик - ленивая жопа, он всегда найдет причины не реализовывать в прототипе сложную интерактивность. Не будьте ленивой жопой, ищите возможности, а не причины.
Под сложным прототипом я понимаю такой прототип, который способен предоставить максимально приближенный к реальному пользовательский опыт (хотя бы в сценарном плане). Где логин меняет состояние страниц, попап загрузки изображений показывает реальную последовательность, а листинги имитируют перестройку при асинхронной фильтрации. Это все влияет на поведение пользователей, это позволяет даже на таком раннем этапе провести предварительное юзабилити-тестирование, отвергнуть или подтвердить гипотезы. В общем, детально проработанные прототипы решают множество задач.
Но Вселенная любит равновесие, поэтому я не могу пройти мимо очевидных минусов сложных прототипов - и даже начну именно с них.
Минусы сложных прототипов
Сложный прототип - не панацея. Это всего лишь инструмент. И, как всякий инструмент, он применим далеко не везде. Где-то не нужен микроскоп, достаточно кувалды.
Целесообразность - для слабаков
На самом деле, конечно, нет. Целесообразность - это важно. Если ваш проект - типовой, вы сами пилите UI или даже кодите, то можете даже не заморачиваться.
Прежде чем определить "глубину прорисовки" пользовательских сценариев в прототипе, нужно оценить множество вещей: от условий реализации проекта до контекста использования прототипа. Иногда прототипы делают не для тестирования гипотез, а лишь для проекционной презентации клиенту и передачи затем UI-дизайнеру. Если при этом вы можете осуществлять авторский надзор на всех этапах, сидеть вместе с остальными над дизайн-макетами и в целом не стеснены полномочиями - пробуйте делать просто.
Время беспощадно
На сложные прототипы уходит много времени. Реально много. Я считал: на один раздел с глубокой интерактивностью лично у меня уходит в четыре-пять раз больше времени, чем на простой набросок интерфейса. "Потоковая" разработка не потерпит таких потерь - а именно бизнес платит нам деньги.
Если ваша компания занимается конвейерным производством или ваши доходы даже в долгосрочной перспективе зависят от количества прототипов, а не от глубины их проработки - не парьтесь, делайте статику.
Тут вам правки по макету
Чем более детализирован ваш прототип, тем сложнее потом вносить в него правки. Чтобы не запутаться в переменных и условиях, мне пару раз приходилось составлять собственную документацию с указанием всех зависимостей. То есть это был отдельный файл, который нужен был только мне - и лишь для того, чтобы не заблудиться в функциях и состояниях страниц, вернувшись через две недели с новой порцией доработок.
Если у вас итерационный процесс, и вы делаете прототип одновременно с исследованием аудитории, выяснением бизнесовых и технических нюансов - то в случае со сложным прототипированием вам понадобятся стальные яйца и еще пара часов в сутках.
Чтобы минимизировать этот нюанс, нужно постараться провести основную исследовательскую работу до начала прототипирования. Возможно, вам придется на первом этапе ограничиться скетчами интерфейсов, не углубляясь в интерактивности. Протестируете/одобрите их - и тогда уже можно буриться в тонкости пользовательского взаимодействия.
Плюсы сложных прототипов
Ну а теперь - про то, почему же порой стоит попотеть, заставляя интерфейс быть умницей даже в прототипе.
Состояния бывают разные
Самый простой пример: различные состояния одной и той же страницы для авторизованного пользователя и гостя сайта; для администратора блога и простого читателя; для покупателя, отдавшего свои кровные за товар или только раздумывающего над этим; для пользователя, просматривающего свой или чужой профиль. И так далее. Это я не говорю еще о разных типах листингов (список/плитка/карта), попапах и прочих историях, которых в рамках одного представления может быть тьма.
Дизайнеры, пришедшие в UX из UI, иногда предпочитают делать несколько страниц в прототипе: для каждого состояния свою - мотивируя это тем, что так проще разобраться программистам и клиенту. Нет, так проще только вам, ребятки.
Программисту/фронтендеру проще нажать на подсказку (есть в Axure такие "Notes") и прочитать, что вот тут можно жмакнуть на кнопку логина, "войти" через соцсеть и глазами увидеть логику. А не переключаться между страницами, выискивая "десять различий" (и даже интерфейсная спецификация тут не поможет).
Что же касается клиента, то чаще всего он вообще не будет удерживать в голове разные состояния и сравнивать их, кликая по страницам. Он может что-то упустить, не до конца понять, запутаться, расплакаться, обидеться и уйти. Клиенту, как и простому юзеру, значительно проще использовать прототип привычным способом - просто пройдя по сценарию, не одергивая себя на каждом клике "а, это же только прототип, ок".
Состояния могут меняться в зависимости от массы причин: авторизация, наличие товаров в корзине, права пользователя, его конкретные действия (выбор фасовки или типа листинга), локализация (валюта проставляется до или после стоимости), отправка данных формы - список бесконечен. Я не встречал ни одного сервиса сложнее лендинга, где можно было бы ими пренебречь. Да и в лендингах, если они грамотные, тоже не все статично. Так почему же некоторые юиксеры отдают всю эту тьму факторов, дробящих пользовательский опыт, как шрапнель котенка, на откуп внимательности и фантазии программистов?
Ну и конечно, без смены состояний вы никогда не проведете ни одного нормального тестирования - только очень поверхностные. Но об этом в следующем разделе.
Тестирование - мать учения
А аналитика - и мать, и отец, и брат, и любимый щенок.
Вообще, работа с гипотезами - штука не самая благодарная, хотя и жутко интересная. Но так получается, что значительная часть нашей работы строится именно на гипотезах. Пусть иногда и косвенно подтвержденных, но почти никогда не подтвержденных железно. До той самой поры, пока мы сами не посмотрим на дорогих нашему сердцу представителей ЦА, бодро снующих взад-вперед по сервису и заливающих кипятком смартфоны. Или напротив, захлопнувших вкладку браузера и вытирающих холодную испарину со лба (если только вы не хоррор-сервис, да и то вряд ли).
Чем позже вы поймете, что ваша гипотеза ошибочна, тем больше убытков понесет сервис. Я не стану сейчас рассуждать о том, откуда вообще берутся ошибочные гипотезы - это тема отдельной статьи. Но они берутся, это факт. И если хотя бы часть из них можно проверить в самом начале - глупо этого не делать. Но тут, конечно, надо считать. Если потенциальная цена ошибки - 500 баксов в перспективе, а детальная проработка прототипа обойдется в штукарь, то можно и болтик подзабить. А уж в релизе, глядишь, и проверите.
А ведь есть еще одна возможность, которую практически никто не использует. Количественное тестирование. Вот представьте: есть у вас действительно проработанный прототип. С заглушками, конечно, кое-где, но относительно симпатичный даже. А главное - он позволяет пользователю самостоятельно, без окриков "куда прешь, это ж прототип!", пройти базовые сценарии. Вы вешаете на него аналитику (да хоть гугловую) и отправляете тестовой группе. Не нужно сидеть у них за плечом в душной комнатке, записывать на бумажечку спорные моменты - графики построятся сами, укажут на дырочки в воронках. Вы их залатаете - а вот уже тогда можно и респондентов в душную комнатку пригласить. Сэкономите бабло бизнесу, серьезно.
1 благодарность программиста == 5 жертвоприношений
Если вы покажете программисту, как именно это должно работать, а не просто кинете ему макеты, карту переходов и ТЗ/ТО - он скажет вам спасибо, обещаю. Конечно, это не умаляет роль документации, но значительно повышает шанс получить на выходе именно то, на что вы рассчитывали.
Проработанный прототип сокращает коммуникативные риски. Вместо туманных объяснений типа "ну вот этот блок двигается вот сюда, а этот уползает под него, но остается краешек" или "здесь картинку сначала надо кропнуть вот так, а потом уже накладывать фильтр" программист получает прямое, визуальное указание. И не будет дергать вас каждый раз, когда не уверен в поведении того или иного элемента - а откроет прототип и посмотрит. Вы же сможете аргументированно указать ему на ошибки, если они случатся, - и не придется звать толмача комментариев в слаке.
Кроме того, проработанный прототип позволяет заранее продумать компонентную архитектуру. Например, у меня был случай, когда фронтендер подошел ко мне после ознакомления с прототипом и предложил немного поменять поведение одной из форм, чтобы она вписывалась в общую архитектуру фронта. Изменение было не критическим, на UX практически не влияющим - но позволило чуток сократить время разработки и выдать более лаконичный код, который проще поддерживать.
Вообще, кодеры любят детальные прототипы, они позволяют существенно упростить производство. Уважайте их работу, если хотите, чтобы они уважали вашу.
Конечно, мастодонты могут обойтись вообще без всего этого: накидать дизайн-макеты, нарисовать графики анимаций, добавить еще десяток фреймов с состояниями. Но выше я уже писал про недостатки такого подхода. И даже если если сгладить его сработанностью команды и опытом исполнителей, все равно остается слишком много других "если".
Суперпрототип против Бэтмена
Я тут рассуждал лишь о сложности, об интерактивности и глубине проработки UX-составляющей прототипа. Конечно, одного этого мало. Идеальный прототип - это готовая верстка с дефолтными данными. Но это дорого, долго и далеко не всегда вообще оправдано.
Я перепробовал множество инструментов, но ни один, к сожалению, не дал мне той свободы действий, которую дала Axure. Это всегда либо ограниченность состояний (когда для каждого нужно пилить свой фрейм/артборд и логикой даже не пахнет - например, тот же XD или Figma), либо уже кодинг в полный рост (когда на выходе ты получаешь, по факту, фронтенд - например, Ionic Creator).
При этом Axure тоже имеет ряд недостатков, c которыми все мирятся. Типа долгой загрузки страниц в сложных прототипах или туповатой анимации при "push/pull widgets". А еще есть ряд вещей, которые в Axure почти никто не делает, хотя они прям напрашиваются: вроде интеграции глубокой аналитики или использования произвольных событий в мастерах. Про внедрение собственной JS-надстройки, позволяющей вытворять в прототипе абсолютно всё, я вообще слышал только от наших зарубежных коллег. Ну и, конечно, никто не любит делать в Axure прототипы мобильных приложений.
И вот теперь тут, в Дзене, я буду периодически рассказывать, как с этим бороться и делиться лайфхаками прототипирования. С этого поста начинается целый цикл мини-статей на тему суперпрототипа в Axure.
Еще больше букв и картинок про дизайн и проектирование можно увидеть на моем сайте и здесь, в дзен-канале.
