Нужен ли заказчику прототип сайта? Или он все равно ничего не понимает и нужно сразу показывать дизайн?

Возьмусь ответить, т.к. я за свою деятельность был и на стороне дизайнера/разработчика, и на стороне заказчика и пару раз одновременно (на внутренних проектах).

Я считаю, что прототип нужно делать (или запрашивать делать) обязательно, но это совсем не то, что большинство дизайнеров привыкли показывать. Мне чаще всего в виде прототипа показывали статичные картинки, которые показывают верстку сайта на большом экране. В самом лучшем случае могли показать прототип на invision с простенькими реакциями на действия пользователя. Для меня (архитектора) - это как показывать картинки интерьера, не разобравшись с планировкой.

Я пришел к тому, что дизайн-прототип вещь приятная, но при неправильном порядке разработки - бесполезная, а иногда вообще мешающая.

По моему опыту серьезный сайт (не лендинг, не одностраничная визитка) нужно разрабатывать строго через стратегию контента. Когда веб-дизайнер предлагает картинку, не опирающуюся на то, какой контент, зачем и как будет отображаться, он делает кучу бесполезной работы.

Я (когда я со стороны заказчика) в первую очередь спрашиваю себя какой контент я буду генерировать для сайта и как я его буду в него (в сайт) запихивать. То есть мы начинаем с того, какой контент у нас есть, какой мы планируем создавать, как он будет привязан к SEO (пока вообще ничего про дизайн). Понимая структуру и сложность контента, мы совместно с разработчиком формируем упрощенную модель данных.

Например, пост в блог - это текст (насколько длинный, какие стили нам нужны), картинки/видео (сколько, какие), как мы его будем вводить (через WYSIWYG-редактор или загружать готовый), какие варианты контента нам нужны для мобильных устройств, для светлой/темной темы, для разных языков.

После этого мы просим сделать функциональный прототип, который представляет собой простой CMS, генерирующий страницы с основными типам контента - статичная страница, страница портфолио, страница блога и т.д. Генерируемые страницы имеют простейшую верстку и самую базовую стилизацию. Далее мы этот прототип тестируем, скармливая ему типовой контент, смотрим на мобилках и т.д. Дизайна все еще нет.

По результатам тестирования мы уточняем требования к контенту и одновременно - к CMS. Причем на всех последних проектах для нас приоритетом было именно удобство работы с CMS.

Дизайнер/верстальщик получает в качестве задания уже более-менее реальные страницы, с живым контентом, причем он сразу видит возможное разнообразие контента и как он должен работать на разных устройствах/темах. И вот только теперь дизайнер делает свой дизайн-прототип. Его можно смотреть в статике, но обычно логичнее и нагляднее сразу показывать его натянутым на функциональный прототип. Это особенно актуально, когда дизайн предполагает много интерактива. Такой подход довольно сильно ограничивает свободу дизайнера, но зато делает очень прозрачной всю логику разработки. Мы так работали и с российскими разработчиками, и с западноевропейскими, и с американскими. Всем было поначалу непривычно, но все оценили.

Коротко - если заказчик ничего не понимает, то нужно задуматься зачем вообще с ним работать. Если заказчик понимает зачем ему сайт и как он его будет использовать, то сначала стратегия контента, потом функциональный прототип и только потом дизайн-прототип.