Регистрация и вход в систему: ошибки в дизайне (часть 2)
8 More Design Mistakes with Account Sign-in
Автор: Jared Spool
Источник: User Interface Engineering
Разработка процесса регистрации и входа в систему, который не препятствовал бы пользователям, задача довольно сложная. Она может казаться простой в самом начале, но куча тонкостей может превратить то, что должно быть простым, в стресс для пользователей.
В предыдущей статье я обсудил восемь общих дизайнерских ошибок при разработке процесса входа в систему. В этой статье я опишу еще восемь ошибок, с которыми сталкиваются пользователи при попытке регистрации и при входе в систему.
Ошибка 9: Не сообщать требования к имени пользователя и длине пароля
На сайте Cisco, когда пользователь подбирает себе идентификатор, ему сообщается, что имя «должно содержать минимум одну букву, не может содержать пробелов, может содержать цифры». Но после того как пользователь попытается зарегистрироваться с именем из 6 символов, появляется сообщение об ошибке, которое на самом деле изменяет правила – «имя должно быть длиной от 9 до 50 символов».
Не ясно, зачем Cisco удивляет таким дополнительным требованием пользователей, выбравших для себя короткие имена. Ни один из пользователей, принимавших участие в нашем тестировании, не был рад узнать эту дополнительную информацию.
При создании новой учетной записи Google Mail, пользователю доступна кнопка «Check Availability», которая проинформирует пользователя о требовании минимальной длины (6 символов). Такое решение лучше, чем на сайте Cisco, так как пользователю не нужно заполнять всю форму целиком, чтобы узнать, что учетную запись нельзя зарегистрировать.
Blinksale поступает еще лучше, проверяя логин после каждого напечатанного символа. По мере того, как пользователь вводит символы, ему сообщается, что логин слишком короткий или содержит недопустимые символы.
Ошибка 10: Предъявлять требования к паролям строже, чем в АНБ
Наша история о регистрации на сайте Cisco была бы не полной, если бы мы не заглянули еще на одну страницу: страница длиной в два с половиной экрана, рассказывающая как правильно выбрать пароль. Они действительно не хотят, чтобы кто-нибудь покупал их мячи для гольфа.
Многие выбирают пароли, основываясь на важности информации. Они спрашивают себя, что случится, если эта информация утечет наружу? Некоторые из пользователей, с которыми мы общались, используют несколько паролей, по одному для каждого уровня важности.
Жесткая политика безопасности для большинства обычных пользователей работать не будет. Это значит, что пользователям придется придумать и запомнить новый пароль – действия с высокой когнитивной нагрузкой (которые, по мнению пользователей, могут оказаться слишком сложными). Важно, чтобы сайты не остались без пользователей с высокими требованиями к безопасности.
Ошибка 11: Использовать контрольные вопросы, ответы на которые нельзя вспомнить через год
Один пользователь потерял доступ к своему банковскому счету, потому что не смог вспомнить ответ на контрольный вопрос. Прошло почти два года с момента, когда эта информация была введена. Например, вопрос, «На какой улице вы росли» может запутать пользователя, если он часто переезжал. Или пользователь не сможет вспомнить, как конкретно он ввел название улицы – «Forest» или «Forest Drive».
Служба поддержки может довести пользователя до инфаркта: «Помните, что ответы вводятся с учетом регистра». Вы не просто должны помнить ответы в течении нескольких лет, вы еще должны помнить какими именно символами вы их вводили.
Контрольные вопросы, новая техника для помощи пользователям в восстановлении пароля, по-прежнему не проверена. Трудно придумать вопрос, ответ на который будут помнить долгое время.
Virgin America используют сумасшедшие наборы вопросов, например (это не шутка), «Кто ваш любимы актер или актриса?», «Какой ваш любимый сборник музыки?» и «Сколько деревьев заточил бы сурок, если бы сурок мог бы точить деревья». Мы наемся, что они не станут долго использовать эти вопросы для восстановления паролей.
Ошибка 12: Не возвращать пользователя к его цели
На сайте AllRecipes вы можете легко найти рецепт и сохранить его, чтобы вернуться через некоторое время. Конечно, для этого нужно сначала создать учетную запись. Четыре экрана с вопросами, мало связанными с рецептами. Когда все сделано, пользователя отправляют на главную страницу и предлагают заново найти рецепт, который он хотел бы сохранить.
Реализовать возвращение в точку, откуда пользователь отправился на регистрацию, технически сложно. Тем не менее, не нужно недооценивать, насколько сложно пользователю снова добраться до своей цели.
Ошибка 13: Не объяснять подробности при вводе неправильного логина или пароля
Вернувшись на сайт электронного магазина, на котором он не был несколько месяцев, пользователь ввел адрес электронной почты и пароль, которые, как он считал, должны подойти к этому сайту. Но они оказались неправильными. Сообщение об ошибке было простым: «Неправильный логин. Попробуйте еще раз». Был введен неправильный пароль или же он зарегистрировался на другой адрес?
Пользователь попробовал несколько комбинаций адресов и паролей, но ничего не подошло. В конце концов, он оставил корзину с товарами на 500 долларов и ушел. Магазин потерял довольного пользователя и приобрел разочарованного в один момент.
На сайте Staples при вводе неверного имени пользователя сообщается: «Извините, но мы не можем найти учетную запись для этого имени пользователя». При вводе неправильного пароля сообщается: «Имя пользователя и пароль не совпадают с нашими записями». Эта тонкость помогает пользователям войти немного быстрее.
Сайт American Express сообщает, что введен неправильный пароль, даже если введен неправильный логин. Чтобы добить пользователей, они предлагают две отдельных процедуры восстановления: одна при неправильном логине, другая при неправильном пароле. Лучшие сайты предлагают одну процедуру, независимо от ошибки пользователя.
Ошибка 14: Не показывать ссылку на регистрацию, при ошибке авторизации
Многие пользователи зарегистрированы на таком количестве сайтов, что иногда не могут вспомнить, на каких сайтах уже имеют учетные записи. Многие пользователи сначала пытаются войти под наиболее вероятным с их точки зрения именем и паролем. Если войти не удается, они отправляются регистрироваться.
На сайте CollegeBoard при неудачной авторизации пользователю предлагается нажать на ссылку «Забыли пароль?». На новой странице пользователь может ввести адрес электронной почты, на которую будут отправлены восстановленные данные.
Однако, если адрес не совпадает с записями уже имеющихся, пользователю нужно зарегистрироваться. К сожалению, на этой странице нет никакой возможности сделать это. Пользователю придется вернуться на несколько страниц назад, чтобы начать процедуру регистрации.
Ошибка 15: Не позволять пользователям восстановить свой пароль без отправки его по электронной почте
Сообщить пользователю, что вы отправите ему пароль по электронной почте прекрасное решение, если пользователь знает, какой адрес вы используете. К сожалению, многие пользователи меняют свои адреса со временем. Или же пользователь может не иметь возможности получить доступ к своей почте (например, из дома не может посмотреть рабочий почтовый адрес).
Ошибка 16: Требовать более чем один элемент при восстановлении пароля
Если пользователь забудет логин или пароль на JC Penney, ему нужно будет ввести адрес электронной почты и номер телефонного счета. Потребовать одно или другое было бы замечательно, но требование обоих значений, вероятно, будет приводить к снижению продаж.
Поиск ошибок
Создание удобного процесса регистрации и входа в систему требует много работы. Лучший способ найти проблемы – периодические юзабилити-тестирования с постоянными пользователями, пользователями, которые иногда пользуются сайтом и новыми пользователями. Если вы тестируете, вы обнаружите эти ошибки (и, возможно, другие) практически мгновенно.

Комментарии
Есть еще ошибки:
1. Не сохранять поля пароль и повторный пароль при неудачной регистрации.
2. Не сохранять капчу или сохранять введенный пользователем текст в поле капчи, но менять картинку при неудачной регистрации.
ну, если отвечать на коммент - не сохранять пароль-повтор пароля это общепринятая и вполне правильная практика, т.к. пароль передает защищенным способом и его сохранение на странице означает то, что его можно и перехватить. капча также должна обязательно меняться! а вот то, что часто не предусматривают обновление капчи без обновления страницы - это да, это очень плохо. или я встречала как-то, просили ввести пароль, потом повторить пароль, потом почту,
потом ее повторить. вот это глупость.
а если по тексту, то многое не то, чтобы высосано из пальца, но просто не учитывает особенности систем. например, требование более, чем одного элемента для восстановления пароля требуется для увеличения защищенности - в особенности, если замешаны деньги или личная информация. та же история с восстановлением только по е-мэйлу - контрольный вопрос, особенно если он интуитивный, можно сломать.
но за перевод спасибо, на дельные мысли наводит.
да, не сообщать о том, что пост подвергнется премодерации до того, как я его отправлю - это тоже моветон.
Не надо его тупо пересылать пользователю. Сохранил на сервере, пользователя проидентифицировал кукой и вместо полей пароля поставил заглушки с надписью «пароль сохранён, хотите поменять?»
Куда лучше если до правильного заполнения формы информация никуда не отправляется. А предлагать менять пароль для пользователя который ещё и не зарегестрировался даже…
———————
> Ошибка 13: Не объяснять подробности при вводе неправильного логина или пароля
> На сайте Staples при вводе неверного имени пользователя сообщается: «Извините, но мы не можем найти учетную запись для этого имени пользователя». При вводе неправильного пароля сообщается: «Имя пользователя и пароль не совпадают с нашими записями». Эта тонкость помогает пользователям войти немного быстрее.
———————
Ошибка приведена не к месту. Это неудачная практика - так как позволяет получить злоумышленнику список логинов пользователей данного сайта.
Кроме того, после перевода статей стоило бы озаботиться и о регистрации здесь на сайте, а то смешно выходит - публикуем умные статьи, а сами из них никакого толка не берем. Что это за поле “E-mail (will not be published) (required)” - какого черта оно required - это уже было в одной из ошибок.
required оно по воле разработчиков WordPress’а
У нас это не очень актуально, а вот в Забугрляндии… Если твои персональные данные данные попадают в чужие руки (по причине хака сайта или просто подбора пароля - не важно), пользователи поднимают жуткий вой и дело (нередко!) доходит до суда. Поэтому вполне понятно, почему владельцы сайтов пытаются себя обезопасить.
У меня была база из 12000+ пользователей, пароли там хранились в открытом виде… И очень много (больше, чем хотелось бы) паролей были вида 123456, qwerty, asdf, pass, password и в том же духе. При этом сайт был очень взрослым. И немногие бы обрадовались, выйди о них информация/жутко приватные фото наружу… В таких случаях жесткие требования к паролям я считаю вполне оправданными.
С другой стороны: какие самые часто задаваемые секретные вопросы, например, в отечественных почтовиках? Одни и те же: номер паспорта, девичья фамилия матери, кличка домашнего животного и в том же духе - в принципе, та информация, которую не очень трудно узнать (особенно благодаря всяким социальным сетям). Поэтому отправка пароля на электронную почту - вполне оправданная мера безопасности. Если же пользователь не помнит свой адрес, для этого есть Contact Us, где можно связаться с админом.
Про это уже сказали - опять же, так поступают чисто из соображений безопасности.
Программисты меня поймут: я работал над одним проектом, так там авторизация осуществлялась круче: SELECT * FROM member WHERE user LIKE ‘$user’ AND pass LIKE ‘$pass’ - т.е. если имя похоже на имеющееся в БД, и пароли тоже похожи, пусть заходит. Так лучше?
Ошибка 15 - бред.
Самый лучший способ восстановления. Самый быстрый и удобный + безопасный.
Вы указываете login а сис-ма берет ищет в СУБД по логину почту и высылает туда все данные аккаунта. А вам показывает алерт “Все регистрационные данные для аккаунта $login высланы на $email”
И все счастливы. Ни тебе дебильных вопросов типа “Какой длины у вас левый палец на правой ноге?”, ни тебе огромных форм а ля MAIL.RU для восстановления пароля. Просто login + CLICK по кнопке “выслать пароль”. И все.
А как вы говорите “забыл пароль от почты”… Тяжелый случай. Надо тогда все записывать. Имхо этот вариант самый удобный и для разработчиков и для пользователей.
>Вы указываете login а сис-ма берет ищет в СУБД по логину почту и высылает туда >все данные аккаунта. А вам показывает алерт “Все регистрационные данные для >аккаунта $login высланы на $email”
А если кому-то хочется узнать почту по логину какого-то человека, то ему проблем это не составит никаких..
Оставьте комментарий
You must be logged in to post a comment. Log in