Часто клиент может выразить свои пожелания, только сравнивая желаемый ресурс с уже существующими. Это может касаться как самой концепции ресурса — «MySpace, но для сектора B2B», так и некоторых деталей — «Логин должен быть таким же как на Gmail».

Это свойственно не только дизайну, если человек не очень хорошо знает язык, на котором говорит, то вместо прямого указания на предмет, можно услышать причудливые и многословные описания. В спецификациях составленных клиентами часто можно встретить забавные описания, когда они хотят сказать «база данных зарегистрированных пользователей с отчетами X, Y и Z» или «JavaScript меню, которое деградирует в отформатированные с помощью CSS списки».

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

Зачем мириться с дизайном на основе аналогий?

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

С другой стороны, указание на похожие элементы может быть очень полезны при объяснении клиенту решений дизайнера. Иногда заказчик предоставляет спецификации, в которых все уже предусмотрено и если вы решите сделать, что-то не так как он представлял, то это вызывает вопросы. Если вы объясните, что процесс заказа сделан «как в Expedia», то сможете обосновать заказчику принятые при разработке решения и заодно подкрепить их авторитетным примером.

Когда аналогии атакуют

Как и любого другого у метода сравнений и аналогий есть недостатки. Если клиент говорит, что хочет аукцион «как eBay»,— что именно это означает? Художник подумает «Кричащая цветовая схема», программист «Поддержка до 20 миллионов пользователей», пользователь «Рейтинг и отзывы на каждого продавца». А что из этого имел ввиду клиент? Вы можете потратить много времени, составляя спецификации проекта похожего на eBay, и при этом не угадать, что именно было нужно клиенту.

К тому же обсуждение проекта на основе аналогий может вызывать у заказчика неприемлемые ассоциации и пристрастия. Если вы скажете, что новый интернет магазин будет на 95% работать как Amazon, заказчика может одолеть желание доработать оставшиеся 5%, будучи уверенным, что тогда его магазин достигнет объемов и возможностей Amazon.

Более того, способность перенимать возможности простым сравнением может спровоцировать заказчика на включение нерелевантных или бесполезных дорогостоящих возможностей в спецификации проекта. К примеру, множество мелких электронных магазинов поддерживают возможность оплаты различными валютами, которая ими никогда не используется. Это значительно усложняет разработку, и если вы ориентируетесь на рынок Аризоны, то едва ли захотите тратить дополнительные $5000, чтобы ваш магазин «такой как Zen Cart» поддерживал работы с британской налоговой системой.

В конце концов, клиент который может выразить свои пожелания только в виде сравнений может просто не знать лучше всего подходящих ему примеров. Торговец, вероятно, скажет, что он хочет систему похожую на его любимый электронный магазин, но он приводит такое сравнение потому, что у него нет достаточного опыта в этой области. Едва ли он видел достаточно много различных сервисов и возможно не знает об удобных кнопках для покупки в один клик или других полезных элементах, которые хорошо подходят к его нуждам. Обладая большим опытом в этих вопросах, вы должны предложить клиенту возможности, о которых он не знал, и спасти его от неподходящих аналогий.

Возвращаемся в реальный мир

Вы должны держать под контролем все двусмысленности, которые возникают в процессе обсуждения аналогий, иначе вы будете обречены на безуспешные попытки создания мутанта работающего как YouTube плюс Newegg помноженный на DeviantArt с бюджетом $750. К счастью, на практике стратегия отбора хороших аналогий очень проста, используйте только те, которые кажутся вам достаточно конкретными и полезными.

Начать с аналогий имеет смысл, даже если вы разрабатываете, что-то принципиально новое. Но в этом случае особое значение приобретает второй этап разработки, когда поняв, что нужно клиенту, вы должны выразить это в более конкретной форме и включить в спецификации проекта. Не помешает и рассмотрение отдельных частей проекта, который был выбран в качестве примера, от вопроса «что именно отсюда вы хотите скопировать» вреда в любом случае не будет. Разработчики часто склонны усложнять вопросы, и бывают очень удивленны, когда оказывается, что все, что клиент хочет взять от проекта за $300 000, это цветовая схема и расположение меню.

Еще одна возможность защититься от двусмысленных сравнений, это рассматривать их не только как рекомендации, но и как отправные точки для тестирования. Сравните удобство вашего решения и примера приведенного клиентом с помощью тестирования, попросите пользователей выполнить типичные задачи на вашем сайте и сайте примере. Сравнение впечатлений пользователей и успешности выполнения задач может быть доказательство того, что ваше не уступает или даже превосходит модель. Особенно эффективен такой подход, когда заказчик имеет довольно таки смутное представление о поведении пользователей.

Часто заказчик приводит неадекватные аналогии просто потому, что это все, что он знает, в таких случаях вы должны понять, что ему нужно и предложить более подходящие примеры.

Не забывайте сделать выводы из того, какие аналогии предлагает клиент, если большинство из предложенных им сайтов содержать Flash и 700K графики на каждой странице, то можно сделать вывод, что для него внешний вид куда важнее, чем пользователи с модемами на 28.8кбит. Читайте между строк, чтобы получить максимум информации о предпочтениях клиента.

Еще один способ обсуждения не больше, не меньше

Обсуждение на основе аналогий и сравнений может помочь максимально вовлечь заказчика в процесс разработки, не выходя за границы его познаний. Тем не менее, на практике нужно постоянно балансировать, не позволяя этой технике стать панацеей, но используя ее полезные стороны.

Translated with the permission of A List Apart Magazine and the author[s].