Метафорический дизайн — или, что бывает чаще, дизайн по сравнению — это такая ситуация, в которой клиент заказывает дизайн или разработку, ссылаясь на другой продукт. Такое можно встретить в концепциях высокого уровня, например, “MySpace, но для задач B2B”, и в отдельных деталях, например “логин должен быть таким же, как в Gmail”.
В разговорном языке есть интересный аналог метафорического дизайна: если вы недостаточно свободно говорите на каком-то языке, вам часто приходится использовать свой ограниченный словарный набор для построения странных описательных фраз, вместо того, чтобы прямо сказать, что именно вы имеете в виду. Возможно, вы помните свой последний отпуск за границей, и ваши вопросы о том, как пройти в “магазин, где обменивают банкноты”. Точно так же, вы по большей части увидите сравнения в спецификациях клиентов, которые не знают, как сказать, что они хотят “базу данных регистрации пользователей с отчетами X, Y, и Z” или “меню JavaScript, которые разворачиваются в списки CSS-формата”.
Метафоры и сравнения также являются отличным способом быстрого обобщения многих почти не связанных друг с другом концепций. В конце концов, базовое поведение любого форума, формы контакта или корзины, как этот HTML шаблон интернет магазина, по большому счету такое же, как у всех остальных, если не принимать во внимание специфический контент сайта.
Что хорошего в сравнительном дизайне?
Метафорический или сравнительный дизайн, будучи использован для определения абстрактных концепций или необычных деталей дизайна, служит мостом через пропасть непонимания. Возможно, клиент с трудом может объяснить, что именно он хочет взять с другого сайта, но в некоторых случаях достаточно просто указать на этот сайт, чтобы пояснить свои желания опытным разработчикам.
И наоборот, сравнительные ссылки могут быть очень полезными для разъяснения дизайн-решений клиенту. Очень немногие клиенты способны снабдить вас всеобъемлющими спецификациями, и если ваши решения не совпали с тем, что ожидал клиент, готовьтесь к вопросам с его стороны. Если вы поясните, что разработали процесс заказа “как в Expedia”, вы легко обобщите диапазон возможных путей развития системы, а также получите дополнительный авторитет, показав, что ваши решения идентичны использованным в успешной системе.
Сравнения атакуют
К несчастью, мощь этого способа коммуникации достается нам недешево. Если клиент говорит, что хочет, чтобы его новый аукцион был “как eBay”, что именно он имеет в виду? Художник слышит: “У него запоминающаяся цветовая гамма”. Разработчик слышит: “Он должен быть способен принять до 20 миллионов пользователей”. Пользователь слышит “На нем есть пользовательские рейтинги каждого продавца”. Что именно из всего этого клиент имел в виду? Вы можете провести десятки часов, расписывая спецификации для eBay-подобных особенностей, о которых клиент даже и не думал.
И наоборот, например, создание интернет магазина HTML, определяя собственную работу в терминах других продуктов, вы можете вызвать у клиента недопустимые сравнения или представления. Если вы хвалитесь, что новая корзина покупок работает на 95% так же, как и корзина Amazon, клиент может быть захвачен мыслью о “приведении в порядок” тех 5%, в которых кроется различие, или же может ошибочно предположить, что его сайт в целом получил возможности и характерные особенности Amazon.
Более того, возможность определить общие черты в одном сравнении может вынудить клиентов непредумышленно включить ненужные или чересчур дорогие детали в спецификацию. Например, многие магазины мгновенной покупки включают в себя широкую поддержку различных валют и видов налогообложения. Это добавляет изрядную толику сложности, и если ваша торговая точка работает на Chandler, Arizona, может быть и не стоит тратить дополнительные $5,000 на разработку лишь для того, чтобы ваш магазин, “такой же, как Zen Cart”, был готов обработать британский налог на добавленную стоимость.
Наконец, клиент, который умеет говорить только сравнениями, возможно, не сможет представить вам лучшие варианты для выбора. Если клиент продает какой-то товар, он, скорее всего, скажет, что ему нужна самодостаточная система покупок в стиле его любимого сайта электронной коммерции — но такое сравнение ограничено его опытом. Возможно, он не видел примеров серверных корзин для покупки, или кнопки одного клика “Buy Now”, на которые он мог бы сослаться, пусть даже они и лучше подойдут его нуждам. Здесь уже дело за вашим опытом и знаниями, поскольку вы сможете предложить своим клиентам варианты выбора, о которых они не знали, и спасти их от тирании сравнения.
Прыжок назад в реальный мир
Двусмысленностью, присущей обсуждениям дизайна, основанным на сравнениях, нужно научиться управлять, иначе вы закончите попытками построить сайт-мутант, работающий как YouTube плюс Newegg, помноженный на DeviantArt… при бюджете в $750. К счастью, существует практическая стратегия контроля роста затрат: используйте метафоры и сравнения только в тех фазах проекта, где они лучше всего подходят.
Имеет смысл начать со сравнений, особенно если вы собираетесь разработать достаточно новый функциональный блок. Однако, в этом случае второй этап разработки спецификации становится критическим. Когда вы достаточно хорошо понимаете, чего клиент хочет на высоком уровне, нужно подтвердить это понимание в более конкретных терминах, что и станет основой для контракта на дизайн. Вы даже можете шаг за шагом пройти по продукту, с которым клиент сравнивает задачу, и уточнить, что он действительно имеет в виду. Нет ничего страшного в том, чтобы спросить: “какую часть процесса вы хотите скопировать?” Зачастую разработчики излишне усложняют неясные требования, и вы можете быть приятно удивлены, когда узнаете, что все, что клиент хочет взять от коммерческого сайта стоимостью $300,000 – это его цветовая гамма и размещение меню.
Вы также сможете контролировать двусмысленные сравнения, относясь к ним не только как к описанию дизайна, но также как к источнику исходного материала. Сравните совместимость и производительность сайта-примера: когда вы проверяете свой сайт на представителях целевой аудитории, позвольте им решить задачу на вашем сайте, а затем на сайтах, которые клиент предложил в качестве примеров. Прямое сравнение впечатлений пользователя от работы, и степень успешности выполнения задачи будут хорошими доказательствами того, что ваш сайт не хуже сайтов-примеров, или даже лучше их. Подобная стратегия особенно эффективна, когда клиент сомневается в удобстве сайта для пользователя.
Если стало ясно, что клиент опирается на плохой или неадекватный аналог, потому что не знает других вариантов выбора, комбинируйте его понимание сравнений со своим богатым вокабуляром дизайнера. Говорите на его языке, и предлагайте “попробовать использовать вот этот другой пример вместо вашего”. Отлично подойдут в качестве пример платные шаблоны WordPress.
Наконец, не умаляйте значимость суммации примеров клиента. Если все сайты, которым он поклоняется, в среднем имеют 700k картинок и Flash-роликов на страницу, невысказанным посланием будет: “цельный вид, насыщенный графикой, для меня важнее, чем пользователи с модемами 28.8.” Умение читать между строк здесь не менее важно, чем в традиционной спецификации.
Еще один инструмент коммуникации: не больше, не меньше
Сравнительный дизайн поможет вовлечь клиентов в процесс разработки, и в то же время сделает обсуждение понятным для них. Однако, практикующие такой метод должны понимать, что плохой анализ метафор может привести к избытку или недостатку информации. Необходимость такого баланса не позволяет этой технологии стать панацеей, но и не мешает ей приносить пользу.
