Откуда берутся неудачные дизайнерские решения
8 сентября 2011 | Опубликовано в статьюшечки | Нет комментариев »
Иногда, пытаясь что-то сделать на сайте, я задаю себе вопрос: «И какому гению пришло в голову реализовать это именно так?»
Проведя несколько лет по ту сторону занавеса веб-дизайна, я столкнулся с рядом причин, приводящих к тому, что веб-приложения не работают так, как хотелось бы пользователю. Давайте рассмотрим несколько основных камней преткновения, из-за которых дизайнеры и принимают эти, на первый взгляд, «дурацкие» решения.
1. Слишком большой объем работы
Как подсказывает опыт, основной причиной неудачных дизайнерских решений является то, что перед командой веб-разработчиков стоит слишком много задач в пределах каждого этапа дизайн-проекта (анализ групп пользователей, разработка структуры/архитектуры проекта на карточках, создание бумажного прототипа сайта, создание каркасного шаблона всех элементов, тестирование юзабилити и т.д. )
И дело не в том, что разработчики не хотят выполнять все эти этапы. Но за всем прочим, чем им в то же самое время приходится заниматься — поддержкой уже существующих разработок, работой в разннобразных новых проектах, общением с ключевыми партнерами и клиентами — у них просто не остается возможности выполнить их.
И часто-густо дизайнеры вынуждены лепить конечный продукт, основываясь лишь на личных своих суждениях да на лучшем из того, что они могут выжать из всей наспех проделанной подготовки.
2. Недостаток времени
Даже в том случае, когда веб-проект не имеет четкого дед-лайна (что для них крайне редко), все равно настает пора, когда надо завершать его, чтобы начать работу над другим.
Я никогда не отзываю проект, который был признан завершенным и запущен в работу. Все недочеты и возможные улучшения, которые могут подождать, записываются в соответствующий список недоработок, к которому нужно будет вернуться после запуска и исправить проблемы.
Конечно, этот метод гарантирует вам переход к следующему проекту по завершению предыдущего, но никак не гарантирует завершение списка недоработок.
3. Фактор HIPPO
Не сбрасывайте со счетов и важность HIPPO (Highest Paid Person Opinion). Или в переводе, «Мнения того, кто больше всех получает.» Как и всюду, в веб-дизайне часто случается, что команда принимает решение или направление только потому, что его навязал босс, работодатель или какое-нибудь еще начальство.
Исходя из моего опыта, мало кто из нанимателей, рассматривая эскиз веб-проекта, обращает особое внимание на содержимое и соответствие его целям пользователя. Вместо этого они сосредотачиваются на общем внешнем виде, фирменной символике, цветовой гамме и т.д. И если какие-то из этих пунктов не соответствуют их представлению, проект возвращается на доработку независимо от того, насколько хорошо продуман дизайн с позиции пользовательских функций.
Это, конечно, дело личное, но обычно те, кому надо кормить семью и кто стремится сохранить постоянные деловые контакты, не слишком охотно вступают в подобные споры. Иногда намного безопасней с точки зрения личной выгоды «последовать за лидером», даже если это идет вразрез с интересами пользователя.
4. Нехватка таланта
Случается, что далеко не все в веб-команде, хватают с неба звезды. И наступает время, когда остается только снова и снова применять один дизайн или элемент функционала, чтобы хоть как-то завершить проект вовремя.
Случается же, что начинаешь докапываться до каждого пикселя, понимая со временем, как сильно отклонился от выполнения основных обязанностей. Учитывая правило уменьшения количества возвратов и необходимость завершить определенный этап работы, в конечном итоге приходится признать работу законченной, даже если понимаешь, что это не совсем тот уровень качества, которого хотелось бы достичь.
Я люблю повторять себе фразу «Лучшее — враг хорошего». В большинстве случаев, когда вы пытаетесь сделать какой-то «хороший» элемент «идеальным», он и так уже достаточно хорош для пользователя и не стоит тех дополнительных усилий и времени, которые вы потратите на его доработку.
5. Клиенты и работодатели
Будучи частью сферы обслуживания, учитывая субъективное представление людей о дизайне, вы не можете не учитывать влияние на вас заказчика, будь то клиент, посредник или ваш начальник.
Следовательно, дизайн веб-проекта всегда предполагает компромиссы и уступки. Как представитель команды веб-разработчиков, вы должны решить для себя, какие пункты вы будете отстаивать до последнего, а какими можно будет пожертвовать при необходимости. Опять же, иногда приходится соглашаться на заведомо неудачное дизайн-решение какого-то малозначительного вопроса, когда это позволяет выиграть спор в куда более важном, по вашему мнению, моменте.
6. Разные цели
Думаю, вас не сильно удивит, что цели организации-заказчика не всегда соответствуют целям пользователя. Задача сайтов чаще в том, чтобы подписать пользователя на рассылку, показать рекламу, предоставить информацию о себе и т.п. , в то время как пользователь просто хочет сделать то, зачем он пришел, и как можно быстрее.
Это зачастую приводит к решениям, выполняющим цели заказчика (всплывающие формы подписки, промежуточные рекламные страницы и другое в таком духе) за счет целей пользователя.
Также, интересы пользователя часто страдают из-за необходимости соблюдать цели безопасности. Никому не хочется ставить CAPTCHA в регистрационных формах или требовать от пользователей создания сложных паролей и ответов на всяческие вопросы для соблюдения безопасности. Но иногда это просто необходимо для предотвращения атак злоумышленников.
7. Изоляция
Команды веб-разработчиков редко видятся со своими заказчиками, и зачастую оказываются изолированы от аудитории. Пользователей своих веб-сайтов они наблюдают в виде групп чисел в программах для аналитики, но никак не в виде обычных людей, пытающихся достичь своих целей с помощью этих сайтов или веб-приложений.
Добавьте сюда избыточный объем работы и нехватку ресурсов — и у вас обрисуется потенциально серьезная проблема, в которой хороший для веб-разработчиков и их нанимателей дизайн, сильно отличается от дизайна, хорошего для пользователя. Слишком разные у них цели и требования.
8. Технологии
Далеко не на каждом сайте управление контентом ведется с учетом современных технологий и последних достижений в сфере веб-дизайна. Иногда, ограниченность технологий, используемых для управления сайтом, приводит к неразрешимым проблемам, и улучшить ничего нельзя без значительных затрат времени и сил.
Если это мелкие либо трудноразрешимые проблемы, они будут накапливаться до тех пор, пока список необходимых улучшений не вырастет до небес. И решить его можно будет только путем перевода сайта под новую CMS, а все мы знаем, чего стоит этот процесс.
Вот, собственно, основные факторы, приводящие к неудачным дизайнерским решениям, с которыми я сталкивался в своей практике. Если у вас есть свои мнения на этот счет, расскажите о них в комментариях, пожалуйста.
Оригинал статьи.