Наверняка каждый из нас наталкивался на сотни заметок о бумажном прототипировании интерфейса, в каждой из которых и раза в раз рассказывались прописные истины о том, что он – очень удобное средство тестирования сайта, его удобства и функциональности еще до этапа разработки.
Но недавно я заметила, что
у него есть еще две полезные функции, не знаю, задумывался ли кто-то о них раньше (наверняка задумывался), но все-таки я решила этой мыслью поделиться, так как кому-то она может показаться полезной.
1. Маркетинговая
Имеется ввиду следующее: часто общаясь с клиентом он все-таки не может принять решение о необходимости сайта для его бизнеса. Ему кажется, что при всех положительных чертах есть и масса вопросов, которые лично ему (человеку далекого от мира информационных технологий) совсем не понятны.
Более того,.как правило сам клиент просто не представляет как это все будет выглядеть и работать.
Чтобы не пояснять на пальцах, можно воспользоваться бумажным прототипом.
Как правило, перед переговорами с клиентом я делаю три вещи:
1. Прикидываю примерно, какие цели могут быть у клиента (именно его личные специфические цели по использованию сайта для его компании)
2. Составляю
mindmap с примерной структурой, функциональностью и задачами сайта
3. Отрисовываю бумажный прототип, чтоб клиент могу «пощупать» как будет работать его сайт, если он согласится
Тут мы сразу убиваем нескольких зайцев: во-первых, клиенту намного легче понять, что он хочет и он может это выразить, на примере того же прототипа, а, во-вторых, клиент понимает, что вы пришли ему не «впаривать», а помогать развить его бизнес с помощью IT (причем порой очень даже примитивных)
2. Предохраняющая
Второй функцией бумажных прототипов лично я бы назвал предохраняющую. Допустим, вы получили заказ, и руки уж чешутся приступить к делу. Однако, много раз лично я сталкивалась с ситуацией, когда, несмотря на Т3 и другие документы клиент в наглую начинает требовать определенные изменения в дизайне (которые часто естественно влекут изменения в программной части).
Т.е. начинаются «качели» вроде «передвиньте вот этот блок», «это мне не нравится», «мы подумали, что новости нам не нужны…» и т.д.
К примеру, вы уже нарисовали дизайн и дали задание программисту, а выясняется, что затраты времени и денег были лишние, что особенно актуально, если клиент вас вообще намерен, несмотря на договор и прочее «кинуть».
В этом случае, бумажный прототип – отличный выход из ситуации. Он намного понятнее, чем Т3 и помогает реальному осознанию клиентом необходимости того или иного раздела, той или иной функции.
Т.е. вы не будете рисовать лишние блоки в дизайне, программировать не используемые в будущем функции и т.п.
Кроме того, если клиент вас решит кинуть на первых этапах, то вы не потратите ничего, кроме 10 листов бумаги и времени.
Совсем недавно именно так у меня и случилось, потому и расстраиваться особо не пришлось.
Что думаете на этот счет?
комментарии (8)
«лично я бы назвал»
«лично я сталкивалась»
kernel panic
Субьективно, бумажный портотип, в частности сайта, должен быть, бумажная версия нативно понятна. Тоже самое можно сказать о бумажной органайзере/блокноте/стикерах.
Как вариант-можно прототип делать ХТМлом. И заказчику понятно и внятно можно объяснить как будет функционировать, и на основе протатипа ТЗ удобно составлять.
конечно это все уже после подписания, вначале нужно уболтать заказчика, вот здесь на месте и потребуются «бумажки».
заказчики же почти все сначала хотят подешевле, а потом уже покруче =)
требовать то всегда можно — но будет ли клиент доволен и будет ли клиент вообще…
тут сталкиваются два суждения:
— заказчику это не выгодно, и он найдет такую контору, которая в договоре такой пункт не укажет… ну или укажет, скажем, какое то минимальное бесплатное количество переделок (скажем 2 раза)
— а дизайнеру, в свою очередь, все равно нужен «хлеб», и он зачастую идет на колоссальные уступки заказчику, дабы получить таки хоть что-то кроме предоплаты…
сразу оговорюсь, я скорее на строне дизайнера, который вправе просить за каждый дополнительный штрих сверх ТЗ дополнительных денег просто потому, что он банально тратит свое время на эти исправления…
однако порой выгоднее удержать заказчика всеми силами, при этом пойдя на уступки (часто значительные...)
безусловно удобно и понятно клиенту…
к тому же основные рыбы для такого «хтмл-макета» практически не меняются…
главный минус для использования — это доведение до ума заказчика, что это именно «модель с базисными блоками», а не окончательный вариант, принятый для дизайна…
объясню на простейшем примере…
рисуем элементарный «базовый черновик» вида: шапка / левая колонка, центральная контентная, правая / боттом…
при этом заказчик видит фактически «плоскую» шапку; условно в левой колонке меню, в правой ссылки на сервисы (поиск, карта, последние новости), в центре контент; плоский боттом…
одновременно с этим пишется ТЗ на дизайн…
и то, и другое по отдельности утверждается заказчиком…
но когда он получает конечный дизайн, он начинает опираться на первичный макет с претензиями «а почему не так»:
— почему шапка не просто строка, а (условно) волна или треугольник
— почему вдруг меню стало горизонтальным под шапкой, а не в левой колонке, как планировалось…
— почему на место планировавшегося меню встали какие-то визуальные баннеры
— почему в правой колонке исчез поиск, и появился в боттоме
ну и т.д.
это самые простейшие примеры — на самом деле все гораздо глубже…
а на самом деле — золотое правило дизайнеров — не надо показывать ничего с начала работ и получения ТЗ до первого готового варианта!
особенно при работе с «крупными» заказчиками, славящихся определенной степенью бюрократизма…
проверено не раз!