Designing Complex Login Experiences
Kira, a Case Study
As a UX designer/developer at Kira Systems, one of the first pain points I noticed was Kira’s registration and login flow. Kira is an app that extracts information from contracts using machine learning, and is used primarily by lawyers for due diligence. When users can’t access their work on the app, we hear about it.
The Problems — Frustrated & Confused Users/Lawyers
We would get 5–7 support tickets per week with these types of issues:
Help, I can’t login! My activation/password reset email never arrived!
The link on the activation/password reset email you sent is broken!
I know my email address and password are correct, why can’t I login to Kira?
I just registered yesterday, why can’t I login to Kira?
How do I enable two-factor authentication for all our users?
That’s over 20 support emails per month that could be avoided. It is also 20+ frustrated lawyers having trouble accessing their accounts, often on tight deadlines, and losing money for every minute they can’t access Kira.
This was all exacerbated by:
- The app not being clear about which region-specific server users should log in to (A.K.A. an instance of Kira, we have multiples);
- Poorly written and unhelpful feedback on forms;
- No documentation of the current registration and login flow. This meant things got missed during QA and consequently caused (avoidable) trouble for our users.
The Solution — Redesigning the Flow
This user experience hadn’t been touched since the app launched in 2015, so I suggested redesigning it entirely. I’m a huge dork who loves flowcharts, so I thought clearly mapping a user’s registration and login journey would help everyone involved — product, design, systems, and development — be on the same page. It would also help uncover issues and edge cases we may not have solved for.
Based on our user research and support tickets, we agreed on these user stories:
As a regular user, I want to register and manage my account easily so I don’t have to contact support every time I need a change (e.g. a password reset).
As a regular user, I want to register and login to the right instance of Kira so I can start working and not have to contact support to troubleshoot.
As an admin, I want to be sure Kira is preserving the privacy of my firm and our user information, so our lawyers can use Kira securely.
The Biggest Challenges — Security & Privacy
Security is a Big Deal at Kira Systems as it is for most enterprise products. We have to bring doughnuts 🍩 to the office when we leave our laptops unattended and unlocked, and the dev and systems team have pgp keys for secure contact when needed. For this project, I had to make sure that:
- We did not disclose which users’ companies were using which servers (for confidentiality and privacy);
- Anyone registering or logging in couldn’t tell if their company already had an account with Kira (to prevent phishing), and;
- Activation and password reset emails did not go to the wrong email addresses.
When looking for design inspiration and solutions we typically look to Dribble or other successful apps for simple solutions and established patterns to build on. Ultimately we needed a solution that satisfied our specific security and privacy concerns, which was something we couldn’t find elsewhere.
A New Registration & Login Flow
One thing we agreed on was that we needed to make this process as simple and easy for users to navigate as possible. We started by solving each of our user stories:
User Story 1 — As a regular user, I want to register and manage my account easily so I don’t have to contact support every time I need a change (e.g. a password reset).
Solution — Approved. Provide clear and simple form error and success messages.
Solution — Approved. Provide clear confirmation when a form has been submitted, and information about what to expect and do next. Provide clarity on time-out for links so users know to take action on those emails.
User Story 2— As a regular user, I want to register and login to the right instance of Kira so I can start working and not have to contact support to troubleshoot registration or login.
Solution — Rejected. Allow users to login first and then direct them to the appropriate instance based on their email domain (which tells us what company they are from). This solution was rejected because some companies use multiple instances of Kira, and security constraints prevent us from disclosing this information explicitly.
Solution — Rejected. Track user locations and automatically send users to the instance of Kira that is hosted in a location closest to them. This would prevent users from picking the “wrong” instance to login to. Unfortunately, this solution was rejected once we realized that where a user was located did not always correlate to what instance of Kira someone may use (e.g. work in Brazil and access Kira’s Australian instance).
Solution — Approved. Allow users to pick an instance (even if it is the wrong one). When they provide their email Kira will evaluate if their firm has an account on this instance, and if they are registered for it. If not, a generic error message appears encouraging them to register or request a demo of the product.
User Story 3— As an admin, I want to be sure Kira is preserving the privacy of my firm and our user information, so our lawyers can use Kira securely.
Solution — Modified. Allow SAML to be detected as early as possible during login. After discussion with our systems team about security limitations, we were allowed to track browser sessions. This meant that we could direct users to their SAML login once they had chosen an instance of Kira they had previously logged into.
Solution — Approved. Allow admins to mandate use of 2fa for their users. Direct those users to directions for how to enable 2FA if they have not done so before they can input their passwords; previously those directions were only available after logging into the app.
The Final Round — Making Things Look Gooooood
I won’t lie — these flowcharts were pretty dry. They went through many rounds of review with our whole team, but this was only half the work.
I really wanted our users to have a pleasant visual experience logging in. A task like due diligence review isn’t exactly the most exciting. Lawyers deserve more than the sense of dread most folks feel when using an uninspiring enterprise product, like MS Word.
The login page is also users’ first contact with our app, so we wanted to make it memorable 🤗
Three major improvements:
- Having a more personalized registration and login page. Kira’s design team really loves lush photography (who doesn’t?), and this was a perfect opportunity to include some in our app. We were also really excited by Unsplash’s recent API launch. We landed on tracking users’ locations, plugging that info into the API, and using random nature photos from that location to populate the background of the login. We would then layer it with a css color blend mode to preserve consistency across images (below).
background-color: rgba(45, 56, 71, 0.80);
2. Making the actual form more accessible. I read many many articles about the ideal way to build a form, eventually landing on having both placeholder text and labels for accessibility. I used subtle transitions to keep the placeholder text visible while a user is typing to save space and prevent confusion. I also used the standard pattern of red and green highlighting on the form fields (and the notifications) to indicate error/success.
3. Finally, we chose a visual design with lots of white space to focus the user on the task. We also chose a split screen to easily transition to a mobile view. See below for our current, reject, and final designs.
If you work with a more complex enterprise app, please learn from our experiences:
- Putting the majority of the effort into designing the flow let us experiment and be more thoughtful during the visual design phase.
- Security concerns and technical constraints prevented easy solutions. This was for the best, considering how excited everyone at Kira Systems is about the final product.
- Having product, dev, and systems in the room while making design decisions was crucial. We could eliminate solutions that wouldn’t work from security, technical or user standpoints.
- It is never a bad decision to use Harry Potter references in your mockups.
~ fin and thanks for reading! ~