Раз уж разговор зашел о святом, почему бы не подкинуть пару веток в костер?
Я дизайнер интерфейсов. И я люблю мокапы.
Да и почему бы мне их не любить, если я только и делаю, что их делаю?
О прототипах или Называйте вещи своими именами
Для начала отметим, что мокапы и прототипы — отнюдь не одно и то же. В нерусском ИТ-словаре существуют несколько терминов для визуалов, соответствующих разным стадиям работы над ИТ-продуктом. Границы этих терминов размыты, но, тем не менее, увидев нечто интерфейсно-графическое, классифицировать его нетрудно.
1. Sketch (набросок, эскиз) — первоначальный моментальный набросок от руки того, что бредет в голову.
2. Wireframe (блок-схема) — схема или чертеж, представляющие «скелет» страницы сайта или приложения. Никаких украшений, только расположение и примерные размеры заголовков, текстовых блоков, иллюстраций, мультимедиа- и навигационных панелей.
3. Prototype (прототип) — модель для тестирования концепции или процесса. Могут быть вставлены картинки, появиться цвето-тональные градации и т.д.
4. Simulation (симулякр, симуляция, полнофункцональный прототип) — на сложных проектах тоже модель для тестирования концепции или процесса, но — Hi-Fi (high fidelity — высокой точности, в отличие от протопипа, который является моделью низкой точности — Lo-Fi). Для создания симуляций (или симулякров, если угодно) обычно используется программа iRise. Там используются библиотеки визуалов, позволяющие изобразить страницы очень близко к конечному виду, есть выпадающие списки, кнопки, меняющие свой вид при наведении, навигация между экранами, поп-апы и т.д.
5. Mockup или mock-up (макет) — неработающая модель, выполненная в натуральную величину и выглядящая так, как будет выглядеть работающий экземпляр. То есть, сделанная в фотошопе веб-страница, отданная на верстку — это мокап. А дизайном она станет, когда появится интерактивность. Вообще-то, мокапы могут быть относительно динамичными и интерактивными, но об этом — как-нибудь потом.
Проекты, в которых полноценно представлены все эти стадии, крайне редки. И поскольку разработчикам недосуг разбираться в нюансах того, чем они не пользуются, термином «прототип» могут назвать всё, что угодно, в промежутке между первой почеркушкой и готовым продуктом.
О принципах работы дизайнера или Почему прототипы — это хорошо
На заре сайтостроения прототипы дизайнеры делали себе сами, называя их «эскизами», «скетчами», «набросками» и т.п. — кто во что был горазд. При этом они даже как-то не представляли, что совмещают в своей работе как минимум две-три разные специализации. Примерно так же сто лет назад автомобилист был водителем и механиком в одном лице, а еще чуть ранее — пожелавший изготовить бронзовый топор шел самолично копать руду.
Но теперь ИТ-специализации выкристаллизовались, что говорит о взрослении отрасли. На смену былым чисто-понтовым сайтам идут реально работающие, сложные сервисы, растут сметы, усложняется структура рабочих групп, 21-й век стучится в черепные коробки менеджеров. И это — хорошо.
Но почему дизайнерам не нравится это разделение труда? — Да очень просто: из-за значительной потери контроля над процессом создания продукта. Раньше можно было готовить всё, что угодно, а теперь на «кухне» появилась еще одна хозяйка, которая лучше знает, как готовить полуфабрикаты, а задача дизайнера отныне — довести их до кондиции и красиво подать. Да еще эти чертовы «проектировщики взаимодействий» трубят на всех углах, что их работа важнее, чем графическое оформление, и все с ними соглашаются!
Разные ли это профессии — вопрос не стоит. Они разные, и это многократно доказано. Могут ли в одном человеке полноценно сочетаться таланты проектировщика взаимодействий (дальше для краткости я буду писать «UX») и графического дизайнера? Не всегда, но могут. Примерно так же, как некоторые пианисты могут сносно играть на гитаре. Остается вопрос, всегда ли следует отделять процессы создания UX и графики и отдавать их на откуп разным людям?
В общих чертах с этим всё просто: если у визуального дизайнера достаточно способностей, опыта и времени, чтобы заниматься UX, лучше всё отдать ему (спецы по UX с визуалами справиться не могут, если за плечами нет дизайнерского прошлого).
Но чем сложнее работа, тем настойчивее возникает вопрос о разделении труда. Рассмотрим два типичных крайних варианта.
1. Вариант идеальный для дизайнера визуалов, с точки зрения UX простейший как амёба: веб-дизайнерское онлайн-портфолио.
Тут он сам себе — заказчик и исполнитель, и с UX справляется легко. Карьера обычно начинается с этого и других несложных сайтов, выполняемых командой из 2-3 человек, где дизайнер общается с заказчиком тет-а-тет и пребывает в полной уверенности, что все, не касающееся программирования — его дизайнерская епархия. Зачастую с этой уверенностью он и идет дальше по профессии.
2. Вариант взрослый: большое и сложное клиентское приложение, демонстрирующее во всей красе разницу между проектированием взаимодействий и визуальным дизайном, например, WPF проект, находящийся в разработке два-три года и более до первого релиза.
Обычно стейкхолдеры на таких проектах — персоны столь важные, что на беседы с проектировщиками у них просто нет времени. Поэтому за адекватность постановки задач отвечают директоры сервисов (service owners). Это специалисты из той же отрасли, что и стейкхолдеры, но с уклоном в ИТ. Они понимают, какие задачи и как должен решать продукт, но в начале работы окончательный вид приложения представляют смутно, особенно, если проект инновационный, не имеющий существующих аналогов.
Проект, естественно, разбивается на короткие отрезки — спринты (обычно длиной в месяц-полтора), и группа UX в плотном, ежедневном взаимодействии с директорами сервисов начинает от спринта к спринту постепенно формировать модели работы юзеров с разными модулями и основные принципы работы с продуктом. Группа UX может состоять из 2-3 и более UX-дизайнеров и дизайнера визуалов.
UX-дизайнеры имеют своего лидера, который фактически является бизнес-аналитиком, и ему приходится закапываться в отраслевую специфику довольно глубоко. На основе работы с директорами сервисов он определяет, какие методы и приемы построения интерфейса будут использоваться, а какие — нет, т.е. вырабатывает некое видение взаимодействия пользователя с будущим продуктом.
А визуальный дизайнер вырабатывает свое видение управления вниманием и эмоциями пользователя в рамках определенной визуальной айдентики. Можно сказать, создает сценарий управления вниманием и эмоциями пользователя, но в реале, конечно, задокументированного «сценария» нет, есть только идея и какие-то первоначальные блоки, которые постепенно «обрастают мясом». И дизайнер не пляшет от самой печки вместе с бизнес-аналитиком, а расходует всю свою творческую энергию кумулятивно, тратя всего несколько часов в неделю на обсуждения уже созданных моделей взаимодействия и пользуясь видеороликами с записями UX-последовательностей. При этом, конечно, он может предлагать свои UX-решения и внедрять их, если они не ломают общей концепции сценариев взаимодействий.
С другой стороны, никто не вмешивается в работу дизайнера по визуализации продукта, т.к. это подобно еще не написанной симфонии — никто, кроме автора не может знать, насколько будет уместна та или иная нота в законченном произведении.
Большинство проектов находится где-то посередине между этими крайностями, и тому, кто руководит проектом, виднее — доверить UX визуальному дизайнеру или нет. Как правило, проектирование взаимодействий — более трудозатратная и более важная часть работы над продуктом, и если дизайнер хочет контролировать процесс создания интерфейсов, он должен мигрировать в сторону UX. Но при этом нужно быть готовым к тому, что в один прекрасный день тебя отодвинут от создания визуала и наблюдать за ним придется издали.
Мне такая перспектива как-то не улыбается. Я люблю прототипы, но мокапы люблю еще больше.
Я нахожусь на Хабре в статусе Read-only и не могу оставлять комментарии. Поэтому прошу вас, добрые мои читатели, пройдитесь по хабу интерфейсов и замолвите слово о бедном мокапе.
P.s. Ответы на вопросы, заданные не мне 😉
Публикации Прототипируй это последовали Вопросы к посту Алекса Рублева про дизайн. Хотя спрашивали не меня, могу ответить из цеховых рядов.
1. Почему, когда дизайнеров просят что-то переделать, с ними приключаются истерики? Причем, чем существеннее доработки — тем более жуткие истерики.
— Ватсон, это элементарно! Дизайнеры, с которыми вы имели дело, не из высшей лиги и никогда в ней не будут. Если человек, делая интерфейс для тачскрина, рисует миллиметровые кнопочки, то это свидетельствует об отсутствии у него аналитических способностей. Быть хорошим графиком он может, хорошим дизайнером — нет. Дизайн — это не том, как красиво все должно выглядеть, а о том, как красиво все должно работать и решать поставленные задачи. И если дизайнеру в процессе работы указали на промах, он должен благодарить коллег за вклад, позволяющий сделать продукт лучше.
2. Прототипирование действительно несколько ограничивает свободу полета творческой мысли, но сильно снижает вероятность необходимости переделок. Таким образом, меньше вероятности дизайнерских истерик. Это не оправдывает применение метода?
— Вопрос риторический, не требующий ответа. Творческая мысль дизайнера должна лететь в заданном направлении как почтовый голубь, а не куда попало как мотылек. 😉
Или, может быть мне не такие дизайнеры попадались?
Если вы не боитесь узнать страшнобеспощадную правду, то уровень ваших дизайнеров соответствует уровню ваших проектов: «От десятков до сотен человекочасов, денег, крови и пота — чтобы получить интерфейс, удобный людям. И пять часов работы дизайнера, до или после.»
— Расходы на визуал составляют полпроцента проектной сметы? — Значит, для вас качество визуала — дело стопятидесятое. Получите и распишитесь! Думаете, в эпплах и гуглах работают по тому же принципу — «ну, всё готово, ща наймем кого-нибудь, чтоб за 5 часов разукрасил»? — Отнюдь, у них там целые дизайнерские отделы сидят!
Да, заказчику виднее, влияет ли уровень исполнения визуала на прибыльность проекта. Но что значит «до или после»? Есть же общепринятая, тысячекратно проверенная методология разработки информационных систем, определяющая последовательность: запрос заказчика > бизнес-анализ > UX > визуальный дизайн > программирование > QA и т.д. И неважно, делается ли проект методом винтажного ватерфолла или эджайлом со спринтами — последовательность одна и та же. Можно, конечно, извернуться и двинуть телегу впереди лошади, но зачем? Видимо, затем, что руководству проектами визуалы по барабану: до сделают или после, тот дизайнер или этот — лишь бы эта возня творческих личностей съела поменьше денег. А нормальные дизайнеры почему-то любят, когда к их вкладу в продукт относятся серьезно. И обычно у них есть выбор, где работать. Се ля ви…
ссылка на оригинал статьи http://habrahabr.ru/post/170549/
Добавить комментарий