Многие маркетологи довольно часто применяют параллельное и итерационное тестирование, дабы проверить эффективность разных вариантов дизайна, поскольку таковой подход способен значительно повысить пользовательский опыт.
Самым стремительным методом внедрения данной методики есть бумажное макетирование (paper prototyping). Бумажные макеты разрешают дизайнерам оптимизировать структуру ресурса в короткие сроки, и оказывают помощь найти наилучшее ответ для редизайна при минимальных финансовых затратах. К тому же, обучиться такому макетированию возможно легко и скоро.
В данной статье мы продемонстрируем, как Mozilla применила бумажное макетирование наровне с сбором и пользовательским тестированием данных, дабы скоро внедрить UX-ориентированные трансформации на своем сайте.
Тестирование макетов с пользователями еще до работы над HTML-кодом выяснилось очень недорогим и продемонстрировало, какие конкретно другие предположения дизайна трудились оптимальнее .
- SplitGen: cтратегический подход к сплит-тестированию
Итерации
Одной из главных целей редизайна было улучшение юзабилити, благодаря которому пользователи имели возможность стремительнее искать нужную информацию. Главной мерой успеха в этом случае было сокращение количества запросов на форумах техподдержки Mozilla.
Первостепенными точками входа на сайт технической поддержки являются справочные целевые страницы (product-help landing page), так как при применении продуктов визитёры переходят на них через меню «Справка». Самый просматриваемый раздел сайта — справочная страница Firefox — содержал большое количество нужной информации, но с таким дизайном пользователям все равно приходилось посещать форум и уже в том месте задавать вопросы.
На данной странице были размещены ссылки более чем на 30 статей, но в случае если кто-то нуждался в информации по теме, которая не была указана, ему оставалось лишь искать её. Вместо этого, визитёрам нужно было дать возможность выбрать категорию, связанную с их проблемами, и найти пара постов с ответами этих вопросов.
Долгие исследования юзабилити говорят о том, что через чур большой выбор опций сбивает пользователей с толку. В то время, когда люди кликают по нужной ссылке с первого раза, они решают собственную задачу фактически в 3 раза чаще.
Руководствуясь данной мыслью, в первой итерации разработчики стремились минимизировать количество дешёвых вариантов. Новый дизайн разрешал визитёрам начать или с их неприятности, или с продукта либо сервиса, и предлагал им 5 самый востребованных ссылок в боксе, в левом нижнем углу страницы.
Дизайнеры делали макеты, применяя OmniGraffle, а после этого распечатывали их на недорогой бумаге и подгоняли под необходимый формат. Потому, что копаться с кодом не было не требуется, данный способ макетирования разрешал сотрудникам Mozilla скоро внедрять дизайнерские трансформации конкретно на протяжении тестирования.
Пользователи Firefox помогали улучшать юзабилити дизайнерских проектов, разрешая разработчикам следить за тем, как они ищут ответы на топовые вопросы. Если они останавливались в каком-то месте либо путались, команда сразу же вносила в дизайн правки.
На данной ранней стадии проектирования эксперты не желали фокусироваться на графических нюансах и слоях — они пробовали узнать, какие конкретно опции нужно дать на каждой странице, и проверить познание меток. В конечном итоге, любой из этих элементов возможно было выразить при помощи вторых интерактивных виджетов, таких как стандартное либо раскрывающееся меню.
В более поздней итерации дизайна, продемонстрированной ниже, группировки задач для справочного материала были перемещены под продукты, на слой ниже в информационной архитектуре, в частности по причине того, что все задачи не были доступны для услуги и каждого продукта, а таковой порядок размещения слоев разрешал сгладить это нужное различие максимально изящно.
Дабы не путать пользователей и не отвлекать их, разработчики кроме этого задействовали технику прогрессивного открытия (progressive disclosure): разные продукты Mozilla сейчас были скрыты в выпадающем меню.
В данной итерации пользователям приглянулись громадные иконки (2), но их запутали формулировки некоторых опций (3): «Принимайте участие: Как вы имеете возможность оказать помощь вторым» (через чур обобщенно) и «Фидбек: Изложите нам собственные предложения при помощи Firefox input» (через чур специфично). Дизайнеры протестировали пара вторых фраз, пока не нашли формулировки, каковые трудились оптимальнее .
Примечание о написании для веб-среды: в течении изучения сотрудники Firefox желали узнать, как много информации необходимо дать пользователям, дабы они имели возможность с легкостью найти самые важные вещи, поскольку один из основных правил чтения с экрана показывает, что меньше — значит лучше. Просматривать на экране тяжелее, чем на бумаге, и низкий уровень грамотности кроме этого есть проблемой.
Потому, что люди, в большинстве случаев, вначале сканируют эти, а не просматривают их, изучая данные в Сети, они видят больше смысла в маленьких фразах и вычисляют лаконичные страницы более эргономичными. Помимо этого, поскольку визитёры сайта Mozilla говорят на всех языках мира, разработчики пробовали реализовать словесный перевод и локализацию как возможно несложнее.
Когда тестирование бумажных макетов завершилось, сотрудники сверстали следующую версию в HTML. В этом дизайне употребляются замечательные фоновые цвета и группировки, дабы различать типы информации и доступные действия. Но, масштабировать данный проект все еще было сложно, исходя из этого до реализации его упростили, а после этого дополнили продуктами, задачами и услугами.
- Кейс от Evernote: несложная, но нужная onboarding рассылка
Последний этап
В финальной версии дизайна все начиналось с выбора продуктов, а по окончании первого клика пользователи видели основанную на задачах навигацию, которая соответствовала нужным правилам прогрессивного открытия. Помимо этого, все возможности учавствовать в работе работы помощи были объединены под одной кнопкой «Доброволец для помощи Mozilla».
Это разрешило людям высказывать заинтересованность в подобном содействии через одну точку входа, а уже на следующей странице выяснять, как как раз они смогут оказать помощь, за счет дополнительных пояснений и опций.
Сотрудники Mozilla всегда оценивают уровень сотрудничества с веб-сайтом, исходя из этого уровень контента и поддержки дизайна увеличивается на базе взятых данных.
Высоких вам конверсий!
По данным: nngroup.com, image source: Minna Perala
Случайные статьи:
- Как создать шаблон бизнес-модели, или lean canvas?
- 5 Принципов визуальной привлекательности современного веб-дизайна
Обзор бумажной модели, ГАЗ-66, 1/25, W.M.C.
Подборка похожих статей:
-
Как сплит-тесты повысили конверсию на 457%: кейс от fiverr
Всего 10-15 лет назад отыскать эксперта для нишевых заказов (дизайн нестандартных элементов, работа с редкими программными платформами и т. д.) было…
-
Кейс от evernote: простая, но полезная onboarding рассылка
Onboarding — это ускоренный процесс ознакомления новых пользователей с главной сокровищем вашего оффера. Чем стремительнее клиенты воспользуются…
-
Как улучшить онбординг: кейс от pinterest
Хорошие отношения постоянно строятся на балансе, взаимных уступках и компромиссах — среди них и отношения между пользователем и компанией. Pinterest…
-
Как итеративное тестирование сократило количество обращений в техподдержку mozilla на 70%
Один из самые частых вопросов, что задают себе маркетологи, пожалуй: «Стоит ли делать редизайн для улучшения юзабилити? Иначе говоря каким будет возврат…