```json
{
    "title": "Регистрация и логин на стероидах",
    "url": "https://sherer.pro/blog/registracija-i-login-na-steroidah/",
    "datePublished": "2019-08-18",
    "dateModified": "2026-07-03",
    "language": "ru-RU",
    "description": "Часто ли вы сталкивались с тем, что не помните, через какую соцсеть логинились на сайте? Или что разработчики не очень точно реализовали логику придуманной вами регистрации? Этим постом я начинаю выкладывать свои проектные решения в паблик - и первое будет посвящено подробной диаграмме логина, регистрации (обычной и через соцсети) и восстановления доступа.",
    "author": "Павел Шерер",
    "publisher": "Павел Шерер"
}
```

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

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

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

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

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

## UPD: спустя год (09.2020)

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

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

Но при этом хотелось дать более гибкий инструмент, однозначно подсветить сложные и не самые очевидные технические и сценарные решения. В общем, ловите новую [статью](https://vc.ru/dev/156552-instrukciya-kak-napisat-idealnuyu-registraciyu) про идеальные логин, регистрацию и восстановление доступа. Немножко лонгрид, конечно, но вам наверняка понравится.

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

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

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

### Проблема

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

И почему именно регистрация и сопутствующая функциональность отнимают столько сил и времени у разработчиков и тестировщиков? Неужели они настолько тупые, что не могут быстро реализовать простой сценарий? Нет, они не тупые, они умные. Просто сценарий не такой простой, каким кажется. А ещё они вынуждены решать проблемы, которые должен был до них закрыть [дизайнер](https://sherer.pro/blog/dizajn-vs-proektirovanie/). Вот навскидку шесть вопросов, связанных с одной лишь регистрацией через социальные сети:

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

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

### Не решение

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

Учитывал ли он, кто именно будет *[пользователем](https://sherer.pro/blog/uchim-proektnuju-komandu-chitat/)* этого описания? Может быть, разработчикам будет не очень удобно вычёсывать логику из тридцати листов текстовой документации? И даже если их не избежать, может, стоило сделать погружение более плавным?

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

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

### Решение

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

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

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

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

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

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

![Полная функциональная схема регистрации, входа и восстановления доступа](https://sherer.pro/content/uploads/2019/08/auth-scheme-1.svg)

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

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

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

## Сценарии

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

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

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

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

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

![Функциональная схема регистрации через e-mail](https://sherer.pro/content/uploads/2019/08/auth-scheme-registration-focus-1.svg)

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

![Функциональная схема регистрации через e-mail, регистрации через соцсети, входа в аккаунт и восстановления доступа](https://sherer.pro/content/uploads/2019/08/auth-scheme-social-focus-1.svg)

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

![Функциональная схема входа в аккаунт](https://sherer.pro/content/uploads/2019/08/auth-scheme-login-focus-1.svg)

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

![Функциональная схема восстановления доступа](https://sherer.pro/content/uploads/2019/08/auth-scheme-restore-focus-1.svg)

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

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

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

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

## Исходники

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

В архиве:

1. исходник диаграммы (делал в [draw.io](https://about.draw.io/), так как работал в Confluence);
2. все диаграммы в SVG и JPG с подсветкой конкретных сценариев из этого поста.

[Функциональная схема регистрации](https://sherer.pro/content/uploads/2019/08/auth-scheme-all-in-one.zip)[Скачать](https://sherer.pro/content/uploads/2019/08/auth-scheme-all-in-one.zip)

*Видимо, из-за специфического содержания архива хром иногда ругается, что файл скачивают редко и он может быть вредоносным. Не верьте, всё там [нормально](https://www.virustotal.com/gui/url/aa2394e331a00b19eb8b0cf17ff298d11f94d1738dd920d83901692bd4db6695/detection).*