Комментарии 11
А какой смысл показывать клиенту прототип на стадии прототипирования? Мне всегда казалось на то он и прототип, что с его готовой версии начинается обсуждение. Да и работая в Axure, даже если у клиента возникают замечания которые в корне изменят прототип, на все правки уйдет не больше пары часов, причем можно это сделать прямо при клиенте, чтобы не терять в дальнейшем времени на согласования.
Да, такой сценарий тоже существует. Бывают случаи, когда проектировщик уверен на 100%, что сделает именно то, что нужно, с первого раза, а последующие комментарии будут незначительными и не займут много времени. Хорошо, если так. Но статья не об этом. Она о том, как сделать так, чтобы и клиент был доволен, и риски дополнительных издержек были сведены к минимуму.
Вы ещё не успеваете познакомиться с человеком с момента заключения договора. Может быть, когда вы покажете ему финальную версию, он скажет «Мне это не нравится» и на этом его аргументация закончится.
Суть проектирования заключается в процессе. Обсуждение начинается задолго до подхода к прототипу. Даже если вы делаете точно то, что нужно клиенту, лучше делать это так, словно вы вместе работаете над прототипом, как одна команда. А не так, что прошёл месяц, вот вам прототип, делайте с ним, что хотите. А клиент понимает, что проделанная работа действительно стоит тех денег, что он заплатил, но это совершенно не то, что ему нужно. Я очень много раз сталкивался с такой ситуацией, когда клиент с улыбкой платит исполнителю, а потом идёт к другому, чтобы всё-таки получить то, что ему нужно.
Процитирую самого себя:
«Чаще всего клиенты, которые обращаются за проектированием и платят за это больше сотни, точно знают, чего хотят. Им в первую очередь нужен исполнитель, а во вторую — консультант. А исполнитель не обязательно должен обладать собственным экспертным мнением.
Высший пилотаж в процессе работы с таким клиентом показать ему свою экспертность, при этом выдавая именно тот результат, который был заранее сформирован в голове клиента. А если вы так умеете, то вот вы уже и в той позиции, когда вас рекомендуют, а не вы кого-то ищете. И снова прототипы в вашем портфолио не играют большой роли».
Вы ещё не успеваете познакомиться с человеком с момента заключения договора. Может быть, когда вы покажете ему финальную версию, он скажет «Мне это не нравится» и на этом его аргументация закончится.
Суть проектирования заключается в процессе. Обсуждение начинается задолго до подхода к прототипу. Даже если вы делаете точно то, что нужно клиенту, лучше делать это так, словно вы вместе работаете над прототипом, как одна команда. А не так, что прошёл месяц, вот вам прототип, делайте с ним, что хотите. А клиент понимает, что проделанная работа действительно стоит тех денег, что он заплатил, но это совершенно не то, что ему нужно. Я очень много раз сталкивался с такой ситуацией, когда клиент с улыбкой платит исполнителю, а потом идёт к другому, чтобы всё-таки получить то, что ему нужно.
Процитирую самого себя:
«Чаще всего клиенты, которые обращаются за проектированием и платят за это больше сотни, точно знают, чего хотят. Им в первую очередь нужен исполнитель, а во вторую — консультант. А исполнитель не обязательно должен обладать собственным экспертным мнением.
Высший пилотаж в процессе работы с таким клиентом показать ему свою экспертность, при этом выдавая именно тот результат, который был заранее сформирован в голове клиента. А если вы так умеете, то вот вы уже и в той позиции, когда вас рекомендуют, а не вы кого-то ищете. И снова прототипы в вашем портфолио не играют большой роли».
Вы ещё не успеваете познакомиться с человеком с момента заключения договора.
При заключении договора идет как минимум двухчасовая беседа, составляется бриф, уточняется что именно человек имеет под разными терминами, такими как «Каталог» или «Обратная связь» ищутся примеры реализации похожих вещей, предлагаются свои варианты, так же с примерами, и только после всего этого составляется прототип, который уже в полной мере совпадает с ожиданиями заказчика.
Все правки, которые за этим последуют, в большинстве случаев сведутся к: «А давайте подвинем корзину и напишем в ней количество товаров»
Есть клинические случаи, когда слова клиента можно перефразировать как «Нет, это не то, я не скажу что здесь не так, но вы делаете совсем не так как я хочу!», но таких можно отсекать на первой беседе, перед заключением договора.
Кажется, не туда ответил. Сейчас перечитываю и вижу, что ответ скорее конфронтальный, чем солидарный. На самом деле это не так. Вы всё совершенно верно написали и про беседу, и про уточнения, а я воспринял это, как тотальную формализацию. Но это не отменяет того, что промежуточный результат в процессе проектирования сокращает потенциальные издержки на правки и позволяет безболезненно подкорректировать курс, даже если появляются новые функциональные требования.
Отвечу на обо комментария сразу:
Бриф это не страховка исполнителя, это гарант взаимопонимания, потому что риски несет как исполнитель, так и заказчик. Собственно прототип это второй гарант.
Теперь про издержки:
В первом случае делается прототип -> показывается заказчику -> согласовываются правки -> доделывается прототип -> утверждается прототип
Во втором случае делается часть прототипа -> показывается заказчику -> согласовываются правки -> вносятся правки -> доделывается прототип -> согласовываются правки -> вносятся правки -> утверждается прототип
Мне не кажется этот путь сокращением издержек, более того мне не кажется такой путь понятнее и приятнее для клиента, кроме случая когда исполнитель пропадает на месяц(любой другой немыслимый срок), с разработкой прототипа.
Бриф это не страховка исполнителя, это гарант взаимопонимания, потому что риски несет как исполнитель, так и заказчик. Собственно прототип это второй гарант.
Теперь про издержки:
В первом случае делается прототип -> показывается заказчику -> согласовываются правки -> доделывается прототип -> утверждается прототип
Во втором случае делается часть прототипа -> показывается заказчику -> согласовываются правки -> вносятся правки -> доделывается прототип -> согласовываются правки -> вносятся правки -> утверждается прототип
Мне не кажется этот путь сокращением издержек, более того мне не кажется такой путь понятнее и приятнее для клиента, кроме случая когда исполнитель пропадает на месяц(любой другой немыслимый срок), с разработкой прототипа.
Значит, мы всё-таки остались каждый при своём мнении.
Я не соглашусь с описанными сценариями, потому что, как в первом, так и во втором случае, ограничиться одной-двумя итерациями, значит не проектировать, а сделать прототип под ключ, внести в него один набор правок и прикрыться договором с функциональными требованиями.
Я всё это описывал не с позиции «мне кажется». Четыре года я работал по методологии, описанной в первом сценарии, до тех пор пока сам не оказался клиентом, которому нужны услуги проектировщика. И ещё три года я работал уже по методологии, описанной в статье, сначала как фрилансер, а затем как собственник компании. Вторая показала себя лучше, особенно на проектах от 150 экранов. При ней функциональные требования могли меняться на лету и клиент получал то, что ему нужно, а не то, что было оговорено в течение двух часов перед брифом.
Я не соглашусь с описанными сценариями, потому что, как в первом, так и во втором случае, ограничиться одной-двумя итерациями, значит не проектировать, а сделать прототип под ключ, внести в него один набор правок и прикрыться договором с функциональными требованиями.
Я всё это описывал не с позиции «мне кажется». Четыре года я работал по методологии, описанной в первом сценарии, до тех пор пока сам не оказался клиентом, которому нужны услуги проектировщика. И ещё три года я работал уже по методологии, описанной в статье, сначала как фрилансер, а затем как собственник компании. Вторая показала себя лучше, особенно на проектах от 150 экранов. При ней функциональные требования могли меняться на лету и клиент получал то, что ему нужно, а не то, что было оговорено в течение двух часов перед брифом.
Все что я говорил тоже взято из собственного опыта. К сожалению мне не приходилось разрабатывать прототипы в более чем 30-50 экранов, и там первая методика срабатывала на ура. В случае действительно больших прототипов возможно Вы и правы.
Наверное можно вывести какую то формулу, по которой после определенных трудозатрат на прототип второй вариант становится более целесообразным.
Наверное можно вывести какую то формулу, по которой после определенных трудозатрат на прототип второй вариант становится более целесообразным.
Я всё же соглашусь с автором поста и вот почему.
Заказчик изначально представляет себе желаемый функционал, но никак не внешний вид.
Если вы делаете единственный бриф, то увеличиваете риск желания переделки заказчиком полученного результата. Либо, если у вас жесткий запрет на переделки в договоре, скрытое его недовольство.
Итерационные же встречи спокойнее сводят в единую точку реальности галлюцинации клиента о будущем сайте и созданные прототипы.
И да, конечно, это тем важнее, чем больше сайт.
То есть не только поэтапное согласование само по себе, но и снижение риска требования переделок.
Заказчик изначально представляет себе желаемый функционал, но никак не внешний вид.
Если вы делаете единственный бриф, то увеличиваете риск желания переделки заказчиком полученного результата. Либо, если у вас жесткий запрет на переделки в договоре, скрытое его недовольство.
Итерационные же встречи спокойнее сводят в единую точку реальности галлюцинации клиента о будущем сайте и созданные прототипы.
И да, конечно, это тем важнее, чем больше сайт.
То есть не только поэтапное согласование само по себе, но и снижение риска требования переделок.
Я ведь именно об этом и пишу. Исполнители подстраховываются брифом, выдают готовый результат, который в человекочасах стоит затраченного бюджета, а клиента счастливым за его деньги не делает. Я бы уже занервничал, когда у меня исполнитель спросил: «А давайте уточним, что такое обратная связь?» Это значит, что в процессе проектирования, я не смогу передумать и по сути я покупаю результат в виде чёрного ящика, а не прозрачный процесс, который приведёт к нужной мне цели. С таким брифом проектирование происходит в момент заключения брифа.
Я описываю клиентоориентированную методологию, при которой снижаю риски, появляющиеся из-за этой клиентоориентированности.
Я описываю клиентоориентированную методологию, при которой снижаю риски, появляющиеся из-за этой клиентоориентированности.
Лично я проектирование начинаю с миндмапа со структурой сайта и всеми возможными целями пользователя. На этом этапе можно с клиента получить почти все его «фантазии». И только когда уже ясен список страниц и цели можно начинать проектировать.
Во-первых, дает возможность получить максимум информации не отвлекая клиента на внешний вид (многим даже перед чернобелым прототипом тяжело не думать о картинке), а во-вторых экономит кучу времени и пониманием желаний клиента. Чаще всего миндмап составляеться вместе с клиентом (или отвественным лицом) за час-полтора. В редких случаях требуеться ссамостоятельная и глубокая проработка.
Во-первых, дает возможность получить максимум информации не отвлекая клиента на внешний вид (многим даже перед чернобелым прототипом тяжело не думать о картинке), а во-вторых экономит кучу времени и пониманием желаний клиента. Чаще всего миндмап составляеться вместе с клиентом (или отвественным лицом) за час-полтора. В редких случаях требуеться ссамостоятельная и глубокая проработка.
можно еще и провести пользовательское тестирование чтобы отсечь субьективность истории. Например, тут www.fabuza.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как правильно показывать клиенту интерактивный прототип сайта в первый раз