Иногда, правда, такие эмоциональные тесты могут преподносить сюрпризы. Мой коллега показывал один свой дизайн пожилой даме. Увидев его, она вдруг разрыдалась. Просто оказалось, что элемент дизайна – собачка – напомнила ей о ее больном питомце. Это говорит о том, что когда вы проводите тестирование дизайна, тенденции лучше всего искать по его результатам, чем по индивидуальным комментариям.
Флеш-тест основывается на контенте и визуальной иерархии. Вы показываете дизайн пользователям на несколько секунд и потом убираете его. Затем вы просите их воспроизвести элементы страницы.
Воспроизведенные элементы и их последовательность хорошо указывают на то, правильно ли расставлены акценты в дизайне. Например, если пользователю не удается назвать ваш главный призыв к действию, значит, скорее всего, что-то нужно изменить. Оба эти теста могут проводиться в форме опроса и, таким образом, вовлекать намного больше пользователей. Но беседа с пользователями вживую имеет преимущества. Это помогает не только лучше понять их, но и дает вам шанс следить за их вопросами и копнуть немного глубже.
Юзабилити-тестирование
Наверное, самый хорошо известный вид тестирования – это проверка удобства пользования (юзабилити-тестирование). Как видно из названия, оно проверяет удобство и простоту использования вашего дизайна больше, чем его эстетический вид. Подобную тему широко раскрыли Стив Круг, Якоб Нильсон и Джаред Спул, поэтому я не хочу здесь слишком сильно углубляться в нее.
Я же хочу подчеркнуть, что успех юзабилити-тестирования зависит от многократных подходов в течение всего жизненного цикла проекта. В течение нескольких лет я откладывал тестирование пользователей на конец проекта, когда было уже слишком поздно вносить изменения. Тестирование на завершающей стадии также не дает возможности провести последующие, чтобы подтвердить эффективность усовершенствований.
Для эффективного тестирования его следует проводить на каждом этапе процесса переделки сайта. Мы должны тестировать абсолютно все, от эскизов, карт настроений и до завершенного дизайна. Проведение однократного теста недостаточно.
Когда и кого тестировать
Причина, по которой тестирование так часто сводится к формальной сессии в конце проекта, кроется в очевидных затратах на него. Люди думают, что найти участников и провести сессию – это процесс дорогой и трудоемкий. Позвольте мне убедить вас в том, что это не так.
Юзабилити-тестирование редко требует точного соответствия по демографическому признаку между выборкой респондентов и предполагаемой целевой аудиторией. Большинство преград, с которыми мы сталкиваемся и которые мешают удобству пользования, обычны для всех.
Для того чтобы набрать участников опроса нужно не больше и не меньше, чем ссылка на существующий сайт. Исключением является тестирование дизайна, для которого требуется приложить немного больше усилий, чем просто набор участников. Их количество должно быть сравнительно высоким, и подбор нужных людей действительно имеет значение. Но сами по себе тесты могут проводиться где угодно и без специального оборудования.
Только однажды я присутствовал на сессии по тестированию пользователей, которая проводилась в специальном центре тестирования с полупрозрачными зеркалами и подключенным видео. Но я думаю, что на самом деле это было менее эффективным, чем партизанское тестирование. У вас будет больше возможности регулярно устраивать тестирование, если вы будете проводить его облегченную версию.
В конце концов, тестирование помогает сделать сайты лучше и легче получить одобрение клиента. Это говорит о том, что клиенты хотят сказать свое слово, а поэтому мы должны уметь получать обратную связь от них.
Как быть с отзывами заказчика
Хотя тестирование реальных пользователей уводит заказчиков от собственного мнения, иногда им тоже нужно помочь правильно выразить свои отзывы о дизайне.
Мы ухудшим положение вещей, если спросим: "Как вы думаете?" или "Не могли бы вы дать мне свой отзыв?" Подобными вопросами мы стимулируем их выражать свое личное мнение. Вместо этого я задаю заказчикам ряд специальных вопросов, когда собираю их отзывы по определенному дизайну. Вот некоторые неплохие вопросы:
• Вы согласны с тем, что изменение дизайна отражает ценность бренда компании?
• Соответствует ли переделывание сайта тем бизнес-задачам, которые мы обговаривали?
• Соответствует ли переделывание сайта персонажам, которые мы обсуждали?
• Побудят ли пользователей утвержденные призывы к действию после переделки сайта?
• Отражает ли дизайн принятые карты настроений и прототипы?
• Все ли подходящие отзывы, полученные из тестирования, мы учли?
Весь ваш труд окупится авансом. Когда заказчик будет иметь возможность обращаться к утвержденным картам настроений, прототипам, результатам тестирования пользователей и т. п., он больше сосредоточится на бизнес-задачах и потребностях пользователей, чем на собственном мнении.
Одержимость личным мнением не единственная проблема. Часто обратная связь от клиента представляет собой список изменений в дизайне, которые вы должны внести по их желанию. К сожалению, эти изменения не всегда в лучшую сторону.
Я активно поддерживаю своих клиентов в том, чтобы они вносили свои предложения по улучшению дизайна. Ведь я же верю, что они могут дать ценную информацию, особенно если вы вовлекаете их в процесс дизайна и обучаете их.
Положение вещей становится угрожающим, когда клиент предлагает решение проблемы, которое он не может четко изложить. Например, клиент просит вас изменить цвет с голубого на розовый, не называя причины. А причина в том, что аудиторию составляют девочки в возрасте 9–12 лет.
Не зная сути проблемы, вы не предложите лучшее решение и не оцените, насколько к месту идея заказчика. Поэтому важно, чтобы он сначала мог высказать проблемы, а потом предложить решения.
Если у заказчика входит в привычку предлагать решения скорее, чем выражать проблему, то обычное напоминание часто возвращает их на место.
Не удастся – задайте вопрос "зачем?". Как я уже сказал, вопрос "зачем?" поможет клиенту разобраться в корне проблемы.
Суть данного раздела сконцентрирована на процессе работы с заказчиком при создании сайтов, ориентированных на бизнес-задачи. Мы увидели, как нужно проводить исследования и тестирование проекта, а также рассмотрели методы работы с заказчиками. Прежде чем подвести черту, давайте посмотрим, насколько долго может продлиться жизнь сайта, который вы создаете. И в особенности как обеспечить будущее сайту после его переделывания.
Вечная переделка
Я должен признаться, что как веб-дизайнер я не всегда был дальновидным в своем методе создания сайтов для заказчиков, что шло во вред мне и им. Уверен, что я не один такой.
Мы совершенно не виноваты в этой недальновидности. По большому счету она – порождение культуры, о которой я говорил ранее. Когда клиент каждые несколько лет утверждает новый сайт (зачастую, всякий раз с разными дизайнерами), мало толку планировать его долгое существование.
Я уже объяснял недостатки подобного подхода, как для клиента (с точки зрения эффективности сайта), так и для дизайнера (с точки зрения дальнейшего сотрудничества). Поэтому мы должны строить непрерывные рабочие отношения с заказчиками, а не ограничиваться однократными встречами. Это срабатывает независимо от того, дорабатываем ли мы сайты или переделываем их с нуля.
Как создать программу непрерывной работы
Как мы уже обсудили, есть веский довод для того, чтобы непрерывно инвестировать в сайт. Однако представлять что-то и осуществлять это на практике – две разные вещи. Важно настроить механизмы, которые обеспечат непрерывные инвестиции.
Я предложил составлять перечни пожеланий и поэтапное развитие сайта как способы подтолкнуть клиента к планированию. Но это не единственные варианты. Раз в три месяца мы устраиваем с заказчиками встречи, где обсуждаем, как можно усовершенствовать их сайты. Также мы проводим ежегодный анализ сайта и предлагаем варианты его усовершенствования на будущий год.
Какой бы механизм вы ни использовали, будь то инфобюллетени по электронной почте или ежегодные анализы, цель одна: показать заказчику, как сайт может перейти на следующий уровень. И помните, что вы должны не просто представить ему новые функциональные возможности и техники. Вы должны объяснить бизнес-выгоды, которые можно извлечь из этого. Только тогда они увидят возврат инвестиций, которые сделают, воплощая ваши идеи.
Однако кроме текущей программы инвестирования есть и другие способы обеспечить сайту его дальнейшее будущее. Существуют еще технические решения.
Использование технологий для обеспечения будущего сайту
Нам следует помнить, зачем и что мы делаем как веб-разработчики. Если мы об этом забудем, то начнем практиковать неправильные вещи. Речь идет о веб-стандартах.
В основе веб-стандартов лежат простые принципы: мы должны разделять контент, дизайн и логику работы сайта. Одним из многих преимуществ этого подхода является то, что это облегчает изменение сайта в будущем.
Веб-стандарты помогают обеспечивать будущее сайтов. Но все равно я вижу тревожное количество сайтов, созданных с CSS, HTML и JavaScript, в которых это разделение не так явно: строки JavaScript либо встроены непосредственно в код HTML, либо рассчитаны на присутствие определенных элементов HTML, а тот, в свою очередь, "нашпигован" классами и идентификаторами элементов, чья единственная цель – задание внешнего вида страницы. Не поймите меня неправильно: я не ярый борец за чистоту кода. Я знаю степень неминуемости таких накладок в коде. Когда вы пишете код, спросите себя, как ваши решения повлияют на обновления через год-другой.
Следующий вопрос, который возникает, когда мы говорим о будущем сайта, – это поддержка браузеров. Как веб-дизайнеры, мы много говорим о поддержке старых браузеров, но мало о поддержке будущих. Мы должны обеспечивать доступ к сайтам через старые браузеры, но нам также нужно думать и о будущей жизни сайта.
Поддержка старого браузера, чья рыночная доля снизится за счет появления новых, имеет мало смысла в финансовом плане. Я – ярый сторонник создания сайтов с использованием HTML5 и CSS3, так как мы знаем, что эти технологии будут все больше и больше поддерживаться. Мы создаем сайты для будущего, не зацикливаясь на браузерах, чья рыночная доля идет на убыль. Понятно, что можно установить баланс, но кто-то может возразить, что поддержка старых браузеров – не лучшее вложение и без того ограниченных ресурсов. Говоря о поддержке, я не могу не посвятить часть раздела мобильному будущему сайта.
Планирование мобильного будущего сайта
Как веб-разработчики, мы входим в азарт от мобильности. Однако мобильность все еще не стоит на повестке дня у многих заказчиков. Для многих из них использование мобильности еще сравнительно невысокое, и поэтому они неохотно вкладываются в него.
Несмотря на это, мало кто выражает свой скептицизм по поводу того, что мобильность может сыграть существенную роль в будущем сайта. Это означает, что даже если поддержка мобильности сайта не является одной из бизнес-задач компании в ближайшем будущем, клиентам нужно уже сейчас планировать ее.
Шаги, которые следует предпринять, будут зависеть от того, какую мобильную стратегию предпочтет клиент. У него есть несколько вариантов, и нам надо рассказать клиенту о них.
Для начала он должен решить, что он хочет: приложение или сайт. Приложения ориентированы на задачи и узко специализированы, тогда как сайт направлен на контент и его возможности намного шире. Если заказчик выбирает приложение, то вопрос в том, какое оно будет: основанное на веб-технологиях или "родное", т. е. написанное, например, под конкретную мобильную платформу. Это сложное решение, которое мы не можем подробно рассмотреть в этом разделе.
Так или иначе, здесь представлены некоторые моменты, которые вам необходимо обсудить с заказчиком:
• Какие "родные" характеристики должны быть доступны?
• Вы можете позволить себе разработку под множество платформ?
• Вы захотите разделить доходы с владельцем магазина приложений?
• Ваше приложение будет доступно через магазин приложений?
• Есть ли какие-либо выгоды от распространения приложения через такие магазины?
Когда клиент останавливается на сайте, то и выбор становится проще. Если сайт будет переделываться глобально, то сейчас самое время сделать его отзывчивым (т. е. заставить его реагировать на доступное экранное разрешение). На маленьких экранах (таких как смартфоны) макет упрощается для удобства использования, тогда как на больших экранах у вас будет обычный макет под настольные компьютеры.
Если сайт не планируется серьезно переделывать в скором времени, тогда предпочтительней выбирать адаптивный подход. Адаптивный дизайн легче осуществлять на существующем сайте, это позволяет изменить формат ключевых экранных размеров (таких как экран планшетного компьютера).
Однако адаптивный дизайн, так же как и отзывчивый, подойдет не для каждого макета, и хотя адаптивный сайт может выглядеть великолепно на сегодняшних устройствах, есть вероятность, что он окажется неоптимизирован для будущих.
В настоящее время Интернет переживает еще одно глобальное развитие, где применяются новые технологии, новые устройства и методы. И нам, веб-разработчикам, выпала миссия помочь нашим заказчикам подготовиться к встрече с этим прекрасным новым миром.
Что дальше?
В этом разделе мы осветили много тем, но не слишком углублялись в них. Основная идея была в том, чтобы научить вас думать на более высоком уровне, чем только о технологии и дизайне, концентрироваться на сложных проблемах, с которыми сталкиваются клиенты, и обеспечивать эффективность их сайтов насколько это возможно. Все, что вам нужно, это взять на вооружение несколько принципов. Вот некоторые рекомендации:
• Будьте кем-то большим, чем просто исполнителем проекта
Неустанно работайте над тем, чтобы изменить ваши взаимоотношения с клиентами. Прекратите быть просто человеком, двигающим пиксели, работайте в команде с клиентами. Умейте возразить им, особенно когда они требуют глобальной переделки сайта. Вместо этого предложите им преобразование и вовлекайте их в этот процесс.
• Подготовьтесь перед стартом
Сдерживайте свои порывы приступить к переделыванию с ходу; сначала лучше выполните домашнее задание. Убедитесь, что вы готовы к тому, что проект может разрастись. Убедитесь с помощью тестирования заинтересованных лиц и аналитики действующего сайта, что вы понимаете бизнес-задачи.
• Тестируйте все
Не полагайтесь только на свой опыт разработчика. Проводите тестирования для того, чтобы процесс разработки был менее субъективным, и для обоснования изменений. Тестирование также поможет вам подсчитать потенциальный возврат вложений, который клиент ждет от вашей работы.
• Планируйте будущее
Разработайте с вашим заказчиком действующую программу развития, которая обеспечит будущее сайту. Подтолкните его к тому, что нужно принимать во внимание мобильный Интернет и будущие браузеры, а не ориентироваться на старые технологии, чья доля идет на убыль.
Вот и все. Надеюсь, что я не слишком деморализовал вас всеми этими разговорами о возврате инвестиций (ROI) и бизнес-механизмах. На самом деле это может быть захватывающей штукой. Мы разработчики, а не художники. Основное отличие в том, что мы создаем вещи, которые решают проблемы. Иногда это проблемы пользователей, но иногда это проблемы, которые испытывают сами клиенты.
Об авторе
* * *
Пол Боуг (р. 1972) вырос в Уашворде (Великобритания), учился в Университете Портсмута и начал свою веб-карьеру в IBM в 1994 году, когда веб-дизайн включал в себя блокнот, серый фон и не имел возможности верстки. Пол – соучредитель "Хэдскэйп" (Headscape – компания, работающая в области веб-дизайна и адаптивного дизайна). Здесь он работает над веб-стратегиями, пишет об успешных сайтах и выступает на конференциях по всему миру. Время от времени он выпускает подкасты. Пол живет в небольшом городке в самом сердце английской сельской местности и активно участвует в жизни местной церкви. Он любит проводить время, играя в Skyrim (компьютерная игра). Пол считает себя любителем животных, потому что его отец – фотограф дикой природы, поэтому у них дома все время были все: от совы до оленей. Его любимые цвета – все оттенки серого. Самый большой урок, который он изучил за свою карьеру, – быть страстными и полным энтузиазма, никогда не терять любовь к Интернету и играть с инновациями. Послание Пола к читателям гласит, что успешность проекта обеспечивается сотрудничеством с клиентом. Возможно, вам непросто работать с клиентом, но без его знаний о бизнесе и сфере деятельности сайт будет провальным. Более того, клиент должен любить ваш дизайн. Если ему не нравится дизайн, он не будет вкладываться в него и использовать в полную силу. Вы обязаны работать совместно.
О рецензенте
