Carbon Login Pattern
UX Designer — IBM, Carbon Design System
As part of an overall goal to promote design excellence at IBM, the Carbon Design System team began an effort to write comprehensive design patterns. The team identified 30 common design patterns used across IBM products and then narrowed that list down to 8 patterns that were considered essential. Of these 8 essential patterns, some had existing guidance and some were brand new to Carbon.
I was tasked with writing two the patterns — Notifications and Login. This case study will focus on my process writing the Login pattern.
Note: Several of the artifacts from this project are confidential and cannot be shown.
The majority of IBM products and products that use Carbon have a login flow. These products span across industries from Cloud software to healthcare to AI applications and have vastly different use cases and user bases. While writing this pattern, I had to ensure the pattern was consistent while also being flexible enough for teams with different use cases to implement.
While writing this pattern, I worked closely with our Creative Director on the visual design and images, our Content Lead to ensure the pattern was clear and consistent with our other patterns, and developers to ensure the proposed guidance would be secure from a development perspective. I also incorporated continual feedback from designers and developers across IBM.
My first step in writing this pattern was to audit external design system guidance. Going through the existing login guidance gave me an understanding of login best practices and the mental models and expectations that users will have while using a login form.
In addition to auditing external design systems, I audited IBM login flows and met with designers and developers who would be using this pattern. This gave me an understanding of the requirements these teams were working with and requirements for the login pattern. This audit was an important artifact that I continually returned to while writing and iterating on the pattern to ensure it met the needs of our teams.
During my exploration, I learned that a team at IBM had conducted extensive research on the current ibm.com login flow. They ran a usability test during which they had 51 participants log in and complete a set of tasks.
The testing found that the majority of users’ attention went directly to the input fields and that users approached the login form with a “Type first, read later” mindset.
From this testing, I knew that the login form in the pattern needed to be straightforward, clear, and the input fields needed to follow users’ mental models.
Login Pattern — Version 1
The scope of the first published version was fairly limited. This version was intended to be a high-level starting place for teams that we could then use to gather feedback for refinement. The pattern covered four topics: overview, behavior, design types, and best practices.
Overview & Anatomy
An introduction to login flows. This section explained when and why to use a login form, defined some initial terms, and detailed the anatomy of a login form.
This section covered the ideal login flow for users using either a username and password or Single Sign-On (SSO).
Initially, we had only two visual design styles for login: a single-column layout and a split-screen layout.
General, unorganized guidelines for designers and developers to keep in mind while working on a login form.
At the start of the patterns effort, we identified 8 design leaders to be stakeholders and represent their design groups' interests while this pattern was being written. They gave continual feedback on the pattern and after the first version of the pattern was published, they took it back to their teams to get more thorough feedback for us.
The primary feedback we received from this period was that folks wanted more detail in the pattern, which we were expecting. We learned that teams were asking for more specific guidance on the visual design types we introduced and on individual interactions in the login flow. We also learned that some developers wanted the pattern to be more explicit about potential security issues. These issues included error messaging and the “remember me” options presented.
Login Pattern — Version 2
While writing the second version of the pattern, I refined it based on the feedback I’d received.
Overview & Anatomy
I expanded the anatomy section to include more optional pieces and more in-depth guidance about each piece. The new guidance is more actionable for folks using the pattern and helps them understand the intended interaction.
I reworked the flow of the behavior section to be both more approachable and more direct. I split out the separate authentication methods to make each flow clear. I also provided alternative guidance for products who could not follow the ideal interaction flow because of technical constraints.
I also added guidance about error handling to the behavior section. This guidance was primarily focused on error messaging for common errors, like incorrect usernames and passwords. While writing it, I worked with developers to balance making the error messaging as informative and helpful as possible with concerns about exposing too much information, like that a username is valid.
The Design Types section became Design and Layout and evolved quite significantly from the preliminary version. I worked with our Creative Director to create detailed visual design guidance. Most of the feedback we received about the Design Types section asked for us to be more prescriptive with the two layout types. To address this, I wrote guidance for different component types, positioning, and spacing and worked with our Creative Director to spec out some of the options.
Finally, the best practices section was removed entirely. Instead of giving this content it’s own section, I folded the guidelines into the rest of the pattern so they made contextual sense and were easier to understand and remember.
Login Pattern — Version 2
The login pattern has been implemented by IBM Cloud and several other teams. We continue to receive feedback about the pattern and are iterating on our guidance.
As part of the documentation push, I also wrote the Notifications pattern and expanded the documentation for several of our components. Below are other examples of my documentation.