Проектирование регистрации

UX/UI, Документация, Технический дизайн 7-9 минут на прочтение

Регистрация и логин на стероидах

Поделиться:

Что может быть проще и понятнее, чем стандартная регистрация? Даже если она включает в себя вход через соцсети и восстановление доступа. Даже если нужно рассказать разработчикам о логике — что там рассказывать-то?

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

Но не всё так просто.

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

§ Почему регистрация

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

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

§ Проблема

Однако почему же тогда регистрация на большинстве сервисов отнюдь не идеальна?

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

  1. Что произойдёт, если Facebook, с помощью которого регистрируется пользователь, не вернул e-mail?
  2. Что делать, если соцсеть вообще отвалилась и не работает (например, кто-то из админов поменял конфиги)?
  3. А если соцсеть при регистрации вернула e-mail, который уже есть в базе?
  4. Как быть, если пользователь восстанавливает доступ, но у него нет пароля, так как он создавал аккаунт через ВКонтакте?
  5. Нужно ли при попытке регистрации или восстановления доступа напоминать пользователю, что он уже регистрировался через Twitter?
  6. А можно как-то заранее сообщить пользователю (ещё до нажатия кнопки входа), через какую соцсеть он входил в прошлый раз?

И ещё тьма вопросов. Все они относятся к бизнес-логике, интерфейсам и юиксу. И очень часто некоторые из них попросту обходятся дизайнерами. Разработчики тоже не боги. Они сперва делают то, что описано; потом — то что принесли тестировщики; потом — то, до чего додумались сами; а затем — чинят то, что поломали предыдущие два шага. И в части этих работ они уже не обращаются к дизайнерам, а делают «по аналогии». Понимаете, что происходит в такие моменты? Да, UX валится к чертям. Потому что красное сообщение о том, что «пароль не подходит» следовало бы заменить на синенькое «не тупи, ты регался через фэйсбук, у тебя нет пароля».

§ Не решение

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

Учитывал ли он, кто именно будет пользователем этого описания? Может быть, разработчикам будет не очень удобно вычёсывать логику из тридцати листов текстовой документации? И даже если их не избежать, может, стоило сделать погружение более плавным?

А общался ли наш дизайнер с разработкой, чтобы пощупать серверную логику и выяснить, можно ли вообще сделать так, как он описал — или это космически дорого и долго?

Он не подумал, что какие-то части могут быть общими для разных сценариев? Это здорово бы упростило (читай «удешевило») разработку. Хотя бы потому, что не всегда разработчик может (и будет) выходить на более высокий уровень абстракции — чаще всего он занят конкретной узкой задачей и не соотносит её с остальными. Или делает это не сильно тщательно.

§ Решение

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

В ней можно описать:

  • действия пользователя (белые блоки);
  • действия системы на клиенте (серые блоки);
  • действия системы на сервере (синие блоки);
  • негативные события (красные блоки);
  • позитивные события (зелёные блоки);
  • условия перехода от действия к действию (жёлтые ромбы);

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

Отдельно укажем точки входа и выхода из сценариев. А мелким текстом над некоторыми блоками даже укажем названия и состояния относящихся к ним экранов!

Красота же, да?

Функциональная схема регистрации через e-mail, регистрации через соцсети, входа в аккаунт и восстановления доступа

Пока рисовали, вспомнили про что-то ещё, дополнили. Через два дня подошли, посмотрели, увидели прореху — залатали. В итоге сделали немного сложную, плохо читаемую, но полную и наглядную функциональную диаграмму логина, регистрации и восстановления доступа.

Тут у нас и путь пользователя, и логика поведения системы, и обработка всех негативных и спорных сценариев, и общие функции (например, запись в БД данных о входе и отработка успешной аутентификации), и указание конкретных экранов и их состояний.

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

§ Сценарии

Давайте пойдём дальше и сделаем нашу чудо-схему несколько более удобной для восприятия — ведь от того, насколько она будет читаемой, зависит качество её понимания и реализации программистами.

Для этого будет достаточно лишь подсветить конкретные сценарии — хвала богам, у нас их всего четыре:

  • обычная регистрация через e-mail;
  • регистрация через соцсети;
  • вход в аккаунт;
  • восстановление доступа.

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

§ Обычная регистрация

Функциональная схема регистрации через e-mail

§ Регистрация через соцсети

Функциональная схема регистрации через соцсети

§ Вход в аккаунт

Функциональная схема входа в аккаунт

§ Восстановление доступа

Функциональная схема восстановления доступа

§ Это не идеальная регистрация

И эту схему можно улучшать бесконечно.

Например, показывать подсказку про соцсеть ещё и при неудачном логине. Да объединить в общую функцию показ таких подсказок у всех сценариев: регистрации, логина и восстановления доступа (как и ошибок «e-mail уже используется» и «не удалось отправить письмо»). Или добавить проверку на срок действия ключа из письма с восстановлением доступа. Можно еще впилить капчу после пяти неудачных попыток входа. Вариантов тьма.

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

§ Исходники

Понятно, что ценность этой статьи была бы невысока, если б я не предоставил исходников диаграммы. Собственно, вот.

В архиве:

  1. исходник диаграммы (делал в draw.io, так как работал в Confluence);
  2. все диаграммы в SVG и JPG с подсветкой конкретных сценариев из этого поста.
file
Скачать: Функциональная схема регистрации
Файл: auth-scheme-all-in-one.zip, размер: 860.8 KB, дата загрузки: 17.08.2019

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

5/5 (72 голоса)
, Ваша оценка:

Поделиться:

Павел Шерер
Павел Шерер

Продюсер, аналитик, продуктовый дизайнер IT-решений

Комментарии (6)

Василий Туркин
Отличный материал, спасибо! А подскажите, почему все-таки не объединили похожие сообщения в единую общую функцию? Я про сообщения например "e-mail уже используется").
Павел Шерер
На этом проекте архитектурно модальные окна были отдельным программным компонентом. Связывать их едиными функциями было бы не очень семантично. Я вышел из ситуации иначе: в функциональной таблице сделал общую функцию "сообщения", в которую передавались текст, статус, коллбэк и тп. И задали правила поведения модалок при их вызове.
Василий Туркин
Ага, спасибо, понятно
Дмитриева Татияна
Спасибо огромное! Мегасхема!
Никита Блинков
Полезно! Хороший материал!

Добавить комментарий

Чтобы оставить комментарий, войдите:
Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.

Top