Коллективная разработка интерфейсов
Messing up the interface
Автор:
Источник:
При разработке интерфейсов рано или поздно наступает момент, когда нужно определиться с приоритетами. Казалось бы, самое очевидное решение – сделать приоритет на удовлетворение потребностей пользователей. Но в большой компании это не так просто.
Упростим задачу – предположим, что вы разрабатываете форму обратной связи. В этот процесс будет вовлечено множество людей из разных отделов и каждый будет решать свои проблемы.
Специалист по юзабилити
Очевидно, что пользователи хотят простые формы, которые можно быстро заполнить. Идеальная, форма обратной связи, с точки зрения пользователя должна состоять из двух или трех полей. Ребята из отдела юзабилити думают также, поэтому пришлют примерно такой макет:
Отдел продаж
С другой стороны, отправляемые формы кто-то должен обрабатывать. Пусть это будет менеджер по продажам. И его явно не устраивает такая форма, так как она не дает ему никакой полезной информации о потенциальном клиенте. Поэтому вы получите что-то вроде этого:
Программист
Программисту достаточно одного взгляда, чтобы понять, что такая форма ему не подходит. Такая форма не позволяет занести клиента в базу данных – нет способа определить фамилию и имя клиента, почтовый код пользователь может и не ввести и вообще, новая база данных требует, чтобы у всех клиентов были занесены сотовые телефоны и электронная почта. Так что форма должна быть примерно такой:
Маркетинг
Поскольку, отдел маркетинга, обычно, является основным заказчиком сайта, неплохо бы спросить и их мнение. В результате внизу формы появятся несколько флажков, а на самой форме – поля вроде даты рождения и пола.
Юридический отдел
Юристы потребуют, чтобы в конец формы было добавлено уведомление, о том, что пользователь заполняет данные на свой страх и риск, и никто ему сохранность его данных гарантировать не будет. Если вам повезет, то в том же поле будет сообщаться, что данные будут храниться семь лет и не будут передаваться третьим лицам. Наверное.
Ох…
Итак, теперь у вас форма с 15 полями, вместо трех, которая перегружена на 400%.
Они хотят все
Если возможно, то попытайтесь убедить клиента остановиться на первой форме. Если в вашей стране есть законы, ограничивающие сбор личной информации, то воспользуйтесь этим аргументом. Или вы можете сделать два варианта формы и проверить, какой будет пользоваться большей популярностью.
Длина полей
Если число полей уменьшить не удается, попытайтесь облегчить жизнь пользователям. Сделайте так, чтобы длина полей соответствовала типу вводимой в эти поля информации – с точки зрения пользователя форма будет выглядеть проще для заполнения.
Простота ввода
Используйте поля разного типа таким образом, чтобы помочь пользователям заполнить их правильно. Не используйте текстовое поле, если есть только два значения. Используйте радио-кнопки, чекбоксы, выпадающие списки (в зависимости от ситуации).
Проверка «на лету»
JavaScript можно использовать для проверки формы «на лету». Рядом с полями, в которые нужно вводить текст определенного формата, можно ставить отметку – зеленую галочку, если поле заполнено правильно, или красный крестик, если в поле ошибка.
Комментарии
А мы вопрос с кучей полей решили следующим образом:
http://www.club66.ru/order/
Что бы не пугать пользователя, необязательные поля скрыли ссылкой. При клике появляются дополнительные поля.
Кол-во заказов с облегчёнными полями увеличилось более чем в два раза. Хотя добавило работы менеджерам по продажам, ибо необязательные поля меньше стали заполнять. Но заказы выросли.
Супер! Очень доходчивый пример, как-нибудь при случае его обязательно упомяну у себя =).
Я бы оставил первый вариант, аргументировав это тем, что во главу угла надо ставить пользователей, а не маркетинговый отдел.
если бы уважаемый Cven, было все так просто
> будет сообщаться, что банные будут храниться семь лет
вероятно, «данные»
Спасибо, исправил.
Оставьте комментарий
You must be logged in to post a comment. Log in