Текст книги "Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки"

Обратная связь через тестирование

Мы любим считать себя разумными существами. На самом деле, мы не такие. На нас все имеет влияние, начиная с детского опыта до невыпитой чашки кофе сегодня утром.

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

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

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

Другая причина, по которой данное свойство играет нам на руку, это то, что людям нравится считать себя логичными. Если вы представляете логичный, объективный аргумент в пользу дизайна, то слушатель гораздо быстрее примет его, ведь он должен реагировать логически. Желание быть последовательным и поддерживать свой имидж может даже превзойти его личную неприязнь к дизайну.

Вспоминаю, как несколько лет назад я делал дизайн в отрасли высшего образования. Сайт был прямо нацелен на то, что тогда называлось «поколением MySpace»[7]7
  Некогда популярная социальная сеть. – Примеч. ред.


[Закрыть]. Лично я ненавидел этот дизайн, и мой заказчик тоже.

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

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

А как вы будете уговаривать клиента принять метод тестирования при переделывании его сайта?

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

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

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

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

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

Есть несколько возможных вариантов, и выбрать правильный очень важно. Я остановлюсь на трех, которые я применяю чаще всего.

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

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

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

В опрос хорошо включить следующие пункты:

• Выбор между двумя подходами к дизайну, с едва уловимой разницей.

• Получение мнения по поводу того, правильно ли дизайн отражает ключевые качества, характеризующие бренд (например, свободный и небрежный либо профессиональный дизайн, консервативный или либеральный?).

• Вопрос пользователям, какими опциями из ограниченного набора они будут пользоваться.

• Проведение сортировки закрытых карт (где пользователь должен систематизировать страницы по категориям).

В инструментальных средствах (в сервисных программах, в серверах), поддерживающих этот вид онлайн-тестирования пользователей, нехватки нет. Я лично использую два – Verify4 и WebSort .5. Польза от опроса в том, что ответы подсказывают определенный тип дизайна, а клиент приобретает уверенность при принятии решения.

Второй вид тестирования пользователей – тестирование дизайна. Здесь проверяется, насколько эстетичен и удобен в использовании интерфейс. Обычно я провожу тестирование дизайна на начальной стадии разработки с относительно большой группой пользователей (20 и больше). Опрашивать их можно индивидуально или в малых группах. Я провожу несколько тестов, но наиболее распространенные – это тест на эмоциональную реакцию и флеш-тест.

В тесте на эмоциональную реакцию вы показываете пользователю дизайн и (как было сказано выше) просите его сделать выбор между ключевыми парами. Дизайн тесный или просторный, классический или современный? Смысл в том, чтобы оценить, соответствует ли дизайн тому образу, который вы представляете. Ключевые слова, которые выберет пользователь, должны содержать желаемые результаты. Если пользователи выбирают эти слова, я знаю, что я на правильном пути в разработке эстетики.

Иногда, правда, такие эмоциональные тесты могут преподносить сюрпризы. Мой коллега показывал один свой дизайн пожилой даме. Увидев его, она вдруг разрыдалась. Просто оказалось, что элемент дизайна – собачка – напомнила ей о ее больном питомце. Это говорит о том, что когда вы проводите тестирование дизайна, тенденции лучше всего искать по его результатам, чем по индивидуальным комментариям.

Флеш-тест основывается на контенте и визуальной иерархии. Вы показываете дизайн пользователям на несколько секунд и потом убираете его. Затем вы просите их воспроизвести элементы страницы.

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

Наверное, самый хорошо известный вид тестирования – это проверка удобства пользования (юзабилити-тестирование). Как видно из названия, оно проверяет удобство и простоту использования вашего дизайна больше, чем его эстетический вид. Подобную тему широко раскрыли Стив Круг, Якоб Нильсон и Джаред Спул, поэтому я не хочу здесь слишком сильно углубляться в нее.

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

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

Причина, по которой тестирование так часто сводится к формальной сессии в конце проекта, кроется в очевидных затратах на него. Люди думают, что найти участников и провести сессию – это процесс дорогой и трудоемкий. Позвольте мне убедить вас в том, что это не так.

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

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

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

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

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

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

• Вы согласны с тем, что изменение дизайна отражает ценность бренда компании?

• Соответствует ли переделывание сайта тем бизнес-задачам, которые мы обговаривали?

• Соответствует ли переделывание сайта персонажам, которые мы обсуждали?

• Побудят ли пользователей утвержденные призывы к действию после переделки сайта?

• Отражает ли дизайн принятые карты настроений и прототипы?

• Все ли подходящие отзывы, полученные из тестирования, мы учли?

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

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

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

Положение вещей становится угрожающим, когда клиент предлагает решение проблемы, которое он не может четко изложить. Например, клиент просит вас изменить цвет с голубого на розовый, не называя причины. А причина в том, что аудиторию составляют девочки в возрасте 9–12 лет.

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

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

Не удастся – задайте вопрос «зачем?». Как я уже сказал, вопрос «зачем?» поможет клиенту разобраться в корне проблемы.

Суть данного раздела сконцентрирована на процессе работы с заказчиком при создании сайтов, ориентированных на бизнес-задачи. Мы увидели, как нужно проводить исследования и тестирование проекта, а также рассмотрели методы работы с заказчиками. Прежде чем подвести черту, давайте посмотрим, насколько долго может продлиться жизнь сайта, который вы создаете. И в особенности как обеспечить будущее сайту после его переделывания.

Вечная переделка

Я должен признаться, что как веб-дизайнер я не всегда был дальновидным в своем методе создания сайтов для заказчиков, что шло во вред мне и им. Уверен, что я не один такой.

Мы совершенно не виноваты в этой недальновидности. По большому счету она – порождение культуры, о которой я говорил ранее. Когда клиент каждые несколько лет утверждает новый сайт (зачастую, всякий раз с разными дизайнерами), мало толку планировать его долгое существование.

Я уже объяснял недостатки подобного подхода, как для клиента (с точки зрения эффективности сайта), так и для дизайнера (с точки зрения дальнейшего сотрудничества). Поэтому мы должны строить непрерывные рабочие отношения с заказчиками, а не ограничиваться однократными встречами. Это срабатывает независимо от того, дорабатываем ли мы сайты или переделываем их с нуля.

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

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

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

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

Нам следует помнить, зачем и что мы делаем как веб-разработчики. Если мы об этом забудем, то начнем практиковать неправильные вещи. Речь идет о веб-стандартах.

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

Веб-стандарты помогают обеспечивать будущее сайтов. Но все равно я вижу тревожное количество сайтов, созданных с CSS, HTML и JavaScript, в которых это разделение не так явно: строки JavaScript либо встроены непосредственно в код HTML, либо рассчитаны на присутствие определенных элементов HTML, а тот, в свою очередь, «нашпигован» классами и идентификаторами элементов, чья единственная цель – задание внешнего вида страницы. Не поймите меня неправильно: я не ярый борец за чистоту кода. Я знаю степень неминуемости таких накладок в коде. Когда вы пишете код, спросите себя, как ваши решения повлияют на обновления через год-другой.

Следующий вопрос, который возникает, когда мы говорим о будущем сайта, – это поддержка браузеров. Как веб-дизайнеры, мы много говорим о поддержке старых браузеров, но мало о поддержке будущих. Мы должны обеспечивать доступ к сайтам через старые браузеры, но нам также нужно думать и о будущей жизни сайта.

Поддержка старого браузера, чья рыночная доля снизится за счет появления новых, имеет мало смысла в финансовом плане. Я – ярый сторонник создания сайтов с использованием HTML5 и CSS3, так как мы знаем, что эти технологии будут все больше и больше поддерживаться. Мы создаем сайты для будущего, не зацикливаясь на браузерах, чья рыночная доля идет на убыль. Понятно, что можно установить баланс, но кто-то может возразить, что поддержка старых браузеров – не лучшее вложение и без того ограниченных ресурсов. Говоря о поддержке, я не могу не посвятить часть раздела мобильному будущему сайта.

Как веб-разработчики, мы входим в азарт от мобильности. Однако мобильность все еще не стоит на повестке дня у многих заказчиков. Для многих из них использование мобильности еще сравнительно невысокое, и поэтому они неохотно вкладываются в него.

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

Шаги, которые следует предпринять, будут зависеть от того, какую мобильную стратегию предпочтет клиент. У него есть несколько вариантов, и нам надо рассказать клиенту о них.

Для начала он должен решить, что он хочет: приложение или сайт. Приложения ориентированы на задачи и узко специализированы, тогда как сайт направлен на контент и его возможности намного шире. Если заказчик выбирает приложение, то вопрос в том, какое оно будет: основанное на веб-технологиях или «родное», т. е. написанное, например, под конкретную мобильную платформу. Это сложное решение, которое мы не можем подробно рассмотреть в этом разделе[8]8
  Вы можете узнать больше о мобильной платформе в редизайне в разделе Арэла Балкана в этой книге.


[Закрыть].

Так или иначе, здесь представлены некоторые моменты, которые вам необходимо обсудить с заказчиком:

• Какие «родные» характеристики должны быть доступны?

• Вы можете позволить себе разработку под множество платформ?

• Вы захотите разделить доходы с владельцем магазина приложений?

• Ваше приложение будет доступно через магазин приложений?

• Есть ли какие-либо выгоды от распространения приложения через такие магазины?

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

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

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

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

Что дальше?

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

• Будьте кем-то большим, чем просто исполнителем проекта

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

• Подготовьтесь перед стартом

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

• Тестируйте все

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

• Планируйте будущее

Разработайте с вашим заказчиком действующую программу развития, которая обеспечит будущее сайту. Подтолкните его к тому, что нужно принимать во внимание мобильный Интернет и будущие браузеры, а не ориентироваться на старые технологии, чья доля идет на убыль.

Вот и все. Надеюсь, что я не слишком деморализовал вас всеми этими разговорами о возврате инвестиций (ROI) и бизнес-механизмах. На самом деле это может быть захватывающей штукой. Мы разработчики, а не художники. Основное отличие в том, что мы создаем вещи, которые решают проблемы. Иногда это проблемы пользователей, но иногда это проблемы, которые испытывают сами клиенты.