Это третья часть моих регулярных сообщений в блоге, описывающих создание нашего нового веб-приложения, HR Partner. Предыдущие посты доступны здесь и здесь.
В первой части я рассказал об используемой методологии входа, а именно о том, как мы отделим систему аутентификации пользователей от баз данных компании. Это было сделано для того, чтобы один пользователь мог легко работать в нескольких компаниях.
Этот рабочий процесс также означал, что если пользователь Боб хотел работать с компанией Acme Industries, то Боб должен был запросить приглашение присоединиться к Acme Industries в качестве пользователя. Для этого Боб просто щелкает ссылку на экране входа и вводит свое имя и адрес электронной почты.
Затем эта информация отправляется администратору компании Acme Industries. Затем они могут войти в систему HR Partner и двумя щелчками мыши одобрить заявку Боба на присоединение (или проигнорировать ее).
В нашем раннем альфа-тестировании всякий раз, когда администратор компании одобрял запрос пользователя, запрашивающий пользователь (в данном случае Боб) автоматически создавал для себя учетную запись, и ему возвращалось обычное поздравительное электронное письмо с сообщением что теперь они могут войти в систему и начать работать с Acme Industries.
Но подождите — у нас есть пограничный случай, который нужно рассмотреть более внимательно.
Мы должны учитывать, является ли Боб новым пользователем экосистемы HR Partner или же он существует уже какое-то время и уже имеет активную учетную запись для входа.
Если у него уже есть учетная запись, ему не нужно ничего делать, кроме как щелкнуть URL-адрес пользовательской компании HR Partner, чтобы немедленно войти в систему.
Если он НОВЫЙ пользователь, то его учетная запись была бы создана автоматически, когда он был одобрен, и теперь ему нужно создать свой пароль, прежде чем он сможет войти в систему.
ДВА различных пути действия, в зависимости от их начального статуса. Однако в нашей первоначальной версии процесса приглашения приглашенному было отправлено только ОДНО общее электронное письмо с просьбой либо войти в систему, либо пройти процесс сброса пароля.
На самом деле, если честно, первоначальная версия была более неуклюжей. На самом деле мы отправили обратно поздравительное письмо и добавили оговорку, что, если они будут новым пользователем, им вскоре следует ожидать ВТОРОЕ электронное письмо с инструкциями по сбросу пароля, после чего мы создадим и отправим им электронное письмо для сброса пароля (тот же пароль повторно отправить электронное письмо, как если бы пользователь запросил его на сайте).
Я подумал, что это смешно — получать от нас одно, а иногда и два письма в зависимости от их статуса. Я решил сделать это проще, отправив пользователю только ОДНО электронное письмо и изменив содержимое в соответствии с его первоначальным статусом.
Итак, теперь пользователь получает приятное поздравительное электронное письмо, и в электронном письме ему ЛИБО показывается ссылка на страницу регистрации компании, ЛИБО ему предоставляется ссылка на страницу сброса пароля (теперь наше приложение генерирует токен сброса пароля перед отправкой электронное письмо, если это новый пользователь).
Конечным результатом является гораздо меньше беспорядка в электронной почте и (надеюсь) меньше путаницы для конечного пользователя в рамках его или ее процесса адаптации.
NB: после дальнейшего рассмотрения мы теперь немного больше работаем над экраном смены пароля. Мы хотим немного изменить этот экран, чтобы, когда приложение обнаруживает, что новый пользователь впервые меняет свой пароль, оно также показывало небольшое приветственное сообщение — просто чтобы сделать экран немного более дружелюбным. чем обычная строгая форма сброса пароля.
Оба вышеприведенных экрана на самом деле одинаковы — это просто формулировка, которая была изменена в зависимости от контекста — будь то новый пользователь или существующий пользователь, желающий сбросить настройки.
Люблю получать отзывы от других дизайнеров или программистов о том, на правильном ли мы пути.
Примечание: Первоначально опубликовано в моем личном блоге.
