Comments 8
«Но недавно я заметила»
«лично я бы назвал»
«лично я сталкивалась»
kernel panic
Субьективно, бумажный портотип, в частности сайта, должен быть, бумажная версия нативно понятна. Тоже самое можно сказать о бумажной органайзере/блокноте/стикерах.
«лично я бы назвал»
«лично я сталкивалась»
kernel panic
Субьективно, бумажный портотип, в частности сайта, должен быть, бумажная версия нативно понятна. Тоже самое можно сказать о бумажной органайзере/блокноте/стикерах.
Прототипирование-это очень хорошо.
Как вариант-можно прототип делать ХТМлом. И заказчику понятно и внятно можно объяснить как будет функционировать, и на основе протатипа ТЗ удобно составлять.
Как вариант-можно прототип делать ХТМлом. И заказчику понятно и внятно можно объяснить как будет функционировать, и на основе протатипа ТЗ удобно составлять.
а не проще чтобы заказчик подписывал дизайн-макеты, а потом за переделку требовать оплату?
дизайн макеты это дальше чем прототип
тогда ТЗ, если заказчик не в силах написать ясное и подробное ТЗ, можно составить самому и на эту услугу в договоре потребовать оплату. по сути ТЗ и есть первоначальный этап работы, после него уже создавать дизайн-макеты.
конечно это все уже после подписания, вначале нужно уболтать заказчика, вот здесь на месте и потребуются «бумажки».
заказчики же почти все сначала хотят подешевле, а потом уже покруче =)
конечно это все уже после подписания, вначале нужно уболтать заказчика, вот здесь на месте и потребуются «бумажки».
заказчики же почти все сначала хотят подешевле, а потом уже покруче =)
проще…
требовать то всегда можно — но будет ли клиент доволен и будет ли клиент вообще…
тут сталкиваются два суждения:
— заказчику это не выгодно, и он найдет такую контору, которая в договоре такой пункт не укажет… ну или укажет, скажем, какое то минимальное бесплатное количество переделок (скажем 2 раза)
— а дизайнеру, в свою очередь, все равно нужен «хлеб», и он зачастую идет на колоссальные уступки заказчику, дабы получить таки хоть что-то кроме предоплаты…
сразу оговорюсь, я скорее на строне дизайнера, который вправе просить за каждый дополнительный штрих сверх ТЗ дополнительных денег просто потому, что он банально тратит свое время на эти исправления…
однако порой выгоднее удержать заказчика всеми силами, при этом пойдя на уступки (часто значительные...)
требовать то всегда можно — но будет ли клиент доволен и будет ли клиент вообще…
тут сталкиваются два суждения:
— заказчику это не выгодно, и он найдет такую контору, которая в договоре такой пункт не укажет… ну или укажет, скажем, какое то минимальное бесплатное количество переделок (скажем 2 раза)
— а дизайнеру, в свою очередь, все равно нужен «хлеб», и он зачастую идет на колоссальные уступки заказчику, дабы получить таки хоть что-то кроме предоплаты…
сразу оговорюсь, я скорее на строне дизайнера, который вправе просить за каждый дополнительный штрих сверх ТЗ дополнительных денег просто потому, что он банально тратит свое время на эти исправления…
однако порой выгоднее удержать заказчика всеми силами, при этом пойдя на уступки (часто значительные...)
сталкивался с подобным… сначала прикидка на бумаге «от руки», потом черновая реализация в хтмл — для черновой же прикидки общего функционала…
безусловно удобно и понятно клиенту…
к тому же основные рыбы для такого «хтмл-макета» практически не меняются…
главный минус для использования — это доведение до ума заказчика, что это именно «модель с базисными блоками», а не окончательный вариант, принятый для дизайна…
объясню на простейшем примере…
рисуем элементарный «базовый черновик» вида: шапка / левая колонка, центральная контентная, правая / боттом…
при этом заказчик видит фактически «плоскую» шапку; условно в левой колонке меню, в правой ссылки на сервисы (поиск, карта, последние новости), в центре контент; плоский боттом…
одновременно с этим пишется ТЗ на дизайн…
и то, и другое по отдельности утверждается заказчиком…
но когда он получает конечный дизайн, он начинает опираться на первичный макет с претензиями «а почему не так»:
— почему шапка не просто строка, а (условно) волна или треугольник
— почему вдруг меню стало горизонтальным под шапкой, а не в левой колонке, как планировалось…
— почему на место планировавшегося меню встали какие-то визуальные баннеры
— почему в правой колонке исчез поиск, и появился в боттоме
ну и т.д.
это самые простейшие примеры — на самом деле все гораздо глубже…
а на самом деле — золотое правило дизайнеров — не надо показывать ничего с начала работ и получения ТЗ до первого готового варианта!
особенно при работе с «крупными» заказчиками, славящихся определенной степенью бюрократизма…
проверено не раз!
безусловно удобно и понятно клиенту…
к тому же основные рыбы для такого «хтмл-макета» практически не меняются…
главный минус для использования — это доведение до ума заказчика, что это именно «модель с базисными блоками», а не окончательный вариант, принятый для дизайна…
объясню на простейшем примере…
рисуем элементарный «базовый черновик» вида: шапка / левая колонка, центральная контентная, правая / боттом…
при этом заказчик видит фактически «плоскую» шапку; условно в левой колонке меню, в правой ссылки на сервисы (поиск, карта, последние новости), в центре контент; плоский боттом…
одновременно с этим пишется ТЗ на дизайн…
и то, и другое по отдельности утверждается заказчиком…
но когда он получает конечный дизайн, он начинает опираться на первичный макет с претензиями «а почему не так»:
— почему шапка не просто строка, а (условно) волна или треугольник
— почему вдруг меню стало горизонтальным под шапкой, а не в левой колонке, как планировалось…
— почему на место планировавшегося меню встали какие-то визуальные баннеры
— почему в правой колонке исчез поиск, и появился в боттоме
ну и т.д.
это самые простейшие примеры — на самом деле все гораздо глубже…
а на самом деле — золотое правило дизайнеров — не надо показывать ничего с начала работ и получения ТЗ до первого готового варианта!
особенно при работе с «крупными» заказчиками, славящихся определенной степенью бюрократизма…
проверено не раз!
Sign up to leave a comment.
Бумажный прототип – не только удобно при планировании сайта, но для заключения сделок