Метка: защита решения

Очень часто я слышу аргумент, которым пытаются «покрыть» собственную плохую работу по дизайну. «Зато наш дизайн — продаёт!» И сразу же предлагают привести примеры дизайна лучше, который продаёт не хуже. И собеседник, сражённый аргументом, либо пытается судорожно припомнить что-то красивое, либо ретируется. Это как раз история о том, как более громкий побеждает более тихого. Но никак не лучший худшего.

История «продающего дизайна» мутна и непонятна, поэтому и хочется внести в неё ясность. Самое главное — дизайн не продаёт в принципе. Точно так же, как задача мясника в магазине рубить, а не продавать, у дизайна задачи совершенно иные. И мешать всё в кучу может скорее человек, плохо ориентирующийся в дизайне или плохо понимающий в продажах.

…

Из заметки директора Syndicated Brands Сергея Славинского «Магазинная полка: продажи и дизайн».

Иногда вы точно знаете, что клиент просит совершенно не то. Может случиться так, что вы испробуете все известные способы объяснить клиенту, что он не прав, но ничего не сработает.

Можно притвориться, что признали свое поражение! После того, как вы сломили сопротивление клиента, согласившись с ним, вы можете получить над ним власть и думать позитивно о том, как можно превратить поражение в победу и выиграть всем.

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

Реализуйте A/B тестирование, и пусть статистика разрешит спор. Ни один клиент не будет продолжать настаивать на своем решении, если ваш вариант лучше отобьет вложенные в него инвестиции.

…

Из статьи Сэма Барнса «Как сказать клиенту, что он не прав».

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

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

Реальные пользователи — и представляющие их персонажи — не пластилиновые, у них есть конкретные требования, основанные на их целях, способностях и контексте использования продукта.

…

Из книги Алана Купера «Об интерфейсе», 5-я глава.