Приветствую!
Мы снова на пороге прокуренной каморки Токсичного Деда, нашего проводника в таинственный и загадочный мир b2b-интерфейсов и толстого троллинга.
Мы: Здорово, Дед!
Т.Д.: Да че вам надо?
Мы: Спросить хотим.
Т.Д.: Ну, жгите.
Мы: Как тебе новое обновление для Figma?
Т.Д.: Никак. Я и старое не видел.
Мы: Ясно-понятно. Sketch, значит, теребонькаешь?
Т.Д.: «Смотрит на нас, как на говно»
Мы: Да что не так-то?
Т.Д.: Статичные прототипы можно юзать только на чем-то несложном. Мобильненькие приложеньица, лендинги, простые сайтики… в общем все, что вам так нравится на бехансике и дриббблике, девочки мои. А в нашей каморке принято делать прототипы, которые работают. Такие, чтоб с яйцами, чтоб от конечного приложения на первый взгляд не отличить!
Мы: Ну так Figma же может…
Т.Д.: Переходы между экранами?
Мы: Да!
Т.Д.: На рифму не нарывайтесь…
Мы: Ну, а сам-то, что используешь?
Т.Д.: По обстоятельствам. Axure, Justinmind, React. Если нужно быстро запрототипировать что-то сложное с кучей логических развилок и состояний, то проще всего в Axure или Justinmind. Если логика более или менее простая и сроки не жмут, можно сразу сверстать на React или чистом HTML/CSS. Ну а когда совсем все плохо, можно и накидать в QT Design, если приложение пилят на подходящем языке. Что б разрабов позабавить.
Мы: И в чем профит?
Т.Д.: Как не парадоксально — экономия времени. Когда у тебя грамотно собранный прототип на Axure, его легко и приятно поддерживать, а самое главное можно сразу показать, как приложение работает. Легкое прохождение по сценариям и как следствие ликвидация возможных ошибок на ранних этапах. Плюс позволяет увидеть картину в целом, что важно. Со статичными картинками такое вообще не прокатит. И потом b2b — это всегда марафон. Открыв прототип через год, ты хотя бы примерно сможешь вспомнить, как это работает. Ну а со статикой ты обречен на километры текстовых описаний, а в случае серьезных изменений еще и на кучу ручной работы по перерисовыванию/переписыванию.
Мы: Но порог входа у таких программ чудовищный! Дизайнер же не должен разбираться в верстке и уж тем более в программировании! Он должен создавать визуальное представление.
Т.Д.: Во-первых, кто сказал, что не должен? Если вы уж работаете в какой то сфере, было бы весьма неплохо разобраться, как что работает. Хотя бы примерно. А то ваши художества потом слишком дорого обходятся в реализации. Ну а порог входа не такой уж и высокий, в конце концов, даже мартышка научится. Во-вторых, визуальное представление — это вещь в себе.
Мы: Почему?
Т.Д.: Потому.
Мы: Можешь объяснить?
Т.Д.: Могу.
Мы:…
Т.Д.:…
Мы: Дед, задолбал!
Т.Д.: Ой, можно подумать… Ладно. Пример для тех, кто в танке. Представляете себе автомат?
Мы: Калашникова?
Т.Д.: Ну например. Он для чего нужен? Какая у него задача?
Мы: Стрелять.
Т.Д.: Отлично. Если его покрасить в красный, он будет стрелять?
Мы: Да.
Т.Д.: А если в зеленый?
Мы: Ну да.
Т.Д.: А если в синий?
Мы: Дед!
Т.Д.: То есть от цвета функционал не зависит?
Мы: Получается нет.
Т.Д.: Супер. А если взять затворную раму и поменять на приклад, изменить, так сказать, логическую модель? Будет стрелять?
Мы: Нет. Он даже не соберется.
Т.Д.: Стало быть, если автомат должен стрелять, то он может быть любого цвета, главное чтобы был правильно собран?
Мы: По идее, да.
Т.Д.: Я это все к тому, что визуальное представление в большинстве случаев изначально задано достаточно жесткими рамками. Интерфейс должен выполнять задачу и иметь оформление, которое этому способствует. В примере с автоматом есть первостепенная задача — он должен стрелять и второстепенная задача — автомат не должен демаскировать солдата на местности. Вторая задача в данном случае — это тонкая подстройка, например красить уже готовый автомат под «лес» или под «пустыню». В любом случае работающий автомат, покрашенный в «лесной» камуфляж, в пустыне будет лучше, чем неработающий, но замаскированный сообразно местности.
Мы: Глубоко копаешь.
Т.Д.: На полный штык! Конечно, приятно, когда у тебя полное совпадение и работающий продукт хорошо оформлен и все работает в связке. Но на деле ты можешь только выбирать форму и размер рожка, накладки на рукоять, наличие подствольника ну и тонну обвеса. НО! Все это опять же будет зависеть от конкретной задачи, а значит список вариаций в каждом конкретном случае будет небольшим. Конечно, можно поставить обвес на все случае жизни, но любой профи тебе скажет, что чем больше инструмент заточен под конкретную задачу, тем лучше. И в интерфейсах вам придется искать этот самый баланс специализации и многофункциональности.
Мы: Как страшно жить!
Т.Д.: А ты думал. Если резюмировать, то интерактивный прототип — это именно прототип автомата из которого можно не просто имитировать стрельбу, а натуральным образом жахнуть. Будут присутствовать все необходимые органы управления, затвор будет ходить, гильзы будут выбрасываться и в целом будет понятно, как с этим всем жить дальше. Какой обвес поставить, каким магазином комплектоваться. А статика больше напоминает детскую пластиковую формовку. Органы управления вроде есть, но они просто выпуклости на корпусе и в конечном счете приходится представлять как это все будет работать. На такой модели можно только прикидывать текстуры и раскраску, что, как мы уже выяснили, не первоочередная задача.
Мы: А зачем React, HTML/CSS и чего ты там еще говорил?
Т.Д.: А это, чтобы лучше тебя видеть, внученька!!!
Мы: Дед!
Т.Д.: Ой все. Бывают в жизни моменты, когда нужно просто нарисовать морду, без чижолой логики, без 100500 всплывашек, просто несколько экранов. И зачем, спрашивается, делать двойную работу? Сначала рисовать, потом отдавать в верстку, потом авторски надзирать. Проще сразу сделать самому и отдать верстальщику на верификацию.
Мы: То есть статичные прототипы — зло?
Т.Д.: Нет. Просто неудобны для сложной разработки. И что это у вас за категории такие, зло/добро, черное/белое, “гибчее” надо быть. А то срам один.
Мы: Ты же понимаешь, какое бурление говен будет в комментах?
Т.Д.: Да пофиг. Я выдуманный.
Мы: Ну да. Логично. Может мы уже пойдем?
Т.Д.: Скатертью по *опе.
Мы: Скажи что-нибудь напоследок.
Т.Д.: Вот така х… ня, малята.
