Макетирование интерфейсов на этапе брифа

Только что прочитал любопытную статью Владислава Головача и Александра Белышкина “Проектирование интерфейса как часть разработки ТЗ”. Суть ее авторы любезно разместили в лиде: “Иногда можно упростить внедрение, просто передвинув процесс проектирования пользовательского интерфейса на этап написания ТЗ”. Я скажу еще более радикальную мысль: процесс проектирования пользовательского интерфейса надо передвинуть на этап написания брифа.

Мы в процессе сайтостроительства решаем с заказчиком несколько задач, результаты которых закрепляются в нескольких “бумажках”: требования заказчика, бриф, коммерческое предложение, договор, календарный план, техническое задание, акт приемки.

Одна из проблем, которую приходится решать - это трансформация “брифа” в “техническое задание”. За время нашей работы было всякое: то по брифу делаем сайт, а потом все критические замечания “укладываются” в бриф и мы дорабатываем бесконечно, то показываем заказчику только ТЗ, но он в нем ничего не понял, и к этому аппелирует, критикуя результат, и приходится либо уступать какой-то стороне, либо разрывать отношения. Когда же необходимость двух документов: брифа и ТЗ была выстрадана потом и кровью, то возник вопрос об их содержании. Каково их различие и что у них общее?

На мой взгляд суть этих двух документов, которые подписываются обеими сторонами в следующем: “бриф” и “ТЗ” - это полные описания одного проекта для двух адресатов (заказчика и исполнителя).

А поскольку заказчик воспринимает свой заказ как то, что он увидит (страницы сайта), то именно в брифе становится актуальной демонстрация экранных форм. Понятно, что здесь демонстрируется не конечный продукт, но макеты. Здесь как раз уместно бумажное прототипирование.

Можно, конечно, засомневаться в том нужно ли превращать бриф в ЭТО. Тут надо уточнить, что в нашей работе бриф - это не статичный документ. Он самый изменяющийся документ. Точнее будет сказать, что под брифом мы объединяем несколько документов - это как бы стадии брифа. Он должен видоизмениться, трансформироваться при тесном общении исполнителя и заказчика: из заметок над требованиями заказчика до концепции проекта. Вот только когда исполнитель понял, что хочет заказчик и предложил ему решение, а заказчик понял, что исполнитель его правильно понял - только тогда можно расчитывать трудозатраты и формировать коммерческое предложение. И только имея утвержденную обеими сторонами концепцию, можно с уверенностью надеяться, что и ТЗ по этой концепции будет также подписано. А значит будет внятный критерий для сравнивания получившегося продукта с желаемым.