Design Rationale for the Self-Enrollment Portal

My second design project after moving to a new team was for a “self-enrollment portal.” Instead of an organization having a central IT person provision a new smart card (used for identity, computer sign-on and access control) for a new or temporary employee, the idea was that employee could do it themselves through a web application.

Use Case

The project was for a working, web-based prototype. Even at this early stage, however, it was worth looking at it from a proper product perspective. It was something that Sales wanted to see so they could pitch it to prospective customers. It was something people would imagine using and form opinions on. It was not a one-off demo: it was a first look at a possible future and what was would be shown would influence every salesperson, potential customer and decision maker moving forward. It was, therefore, a product and must be treated as one. This was why my first and most important question to the executive requesting the engineering time was “who is going to use this?”

The demo that was requested was from the perspective of an employee who has been requested to enroll their own smart card. The demo was to perform certificate enrollment, provide PKCS#11 information and demonstrate remote unblocking, again, all from a user's perspective. The administrative perspective was not requested, and all certificate and card lifecycle management features were specifically cautioned against. Lastly, as a Sales demo, the interface needed to demonstrate different brandings.

The only additional requirement was “Google-like” simplicity, which, if the interface was designed properly, would be inherent.

Therefore, I had a whole scenario to design against:

Erin Enroller gets a temporary username and password from IT so she can log into her new PC, and gets handed a smart card and a URL and is told to enroll it herself. This card is usually, but not always, the same as your employee badge. These are used at all levels of an organization, so we can make no assumptions of Erin's technical expertise; she may be the new CTO or the new administrative assistant to the CTO. The only other aspect of the scenario is that at some future time, Erin forgets her PIN, gets locked out and has to have it unblocked.

The only scenario items are two things that Erin may only perform once each in her entire time with the company. These are not things that she would be doing every day, nor that she might have done every day in the past, so there is no intrinsic familiarity in these actions. I had to assume that these were new and unknown tasks and design appropriately.

On People and Time

Products do not exist in a vacuum. They may be paid for by clients, but they must be used by people. I designed first for a person to use and only second for the requirement list.

A person's time is the most valuable thing they possess. People don't read the screen, don't read manuals and don’t think about what they're doing. They don't want to “use the computer,” they want to “get their work done so they can go home.” They don't want to “enroll their certificates,” they want to “do this thing that IT told them.” In no instance should an interface ever waste a user's time.

Giving the prospective user a name, a description, an identity, goals and tasks allows us to focus on what is necessary for that person to use that product for the use cases described, and strip everything else away, leaving the most efficient interface possible.

Initial Design

Having defined the requirements (from the executive's original email and a subsequent meeting), the use scenario (also from the meeting) and the composite user (Erin), I evaluated what was necessary for the design to function.

Erin logs into her PC, opens a web browser and navigates to the URL provided by IT.

The programmer on the project made the assumption that this would be a portal or home page, but this would not be the most effective use of Erin's time. Portal pages serve no direct purpose; no actual work is accomplished at one. Ideally, the unenrolled card state would be automatically determined and the “home” page would route Erin to the enrollment section.

As this was not technically feasible, I had to fall back to the less-efficient portal model anyway.

Looking at the scenario and requirements, the point of the portal or home page was to allow Erin to enroll her card and later to unblock it; two choices, no more (although, later, a “change your PIN” option was added). The “branding” requirement means that a company logo of some sort should be present, and the fact that this was a Gemalto product meant Sales would likely want the Gemalto logo on the page as well.

The new question, then, was what was the most efficient way to present two logos and two choices? In addition, what additional information was necessary for Erin to make the appropriate choice? As a new and unusual action for Erin, she should be walked through the process as simply and as friendly as possible, making each aspect clear and obvious.

The most important part of any interface, of any page, is the sense of where you are. People get distracted by co-workers and phones, people get called into meetings just as they're starting something. For a web page, the sense of where you are is often provided by the page title, the copy is equally important as placement. The original project title, “Cryptographic Smart Card Enrollment Portal,” was not plain English; those are all technical terms. “Corporate badge self-service” was a little better: your corporate badge is your ID, your pass, but the term is usually company-specific so this was fine as-is. “Self-service” is the same as what you do at a gas station when you pump your own gas, so it was an appropriate term to reuse here.

The first place a Westernized, left-to-right language-reading person looks on a page is the upper left, and then trails down to the lower right in a reducing, zig-zag, “Z” or “F” shape. Therefore, I placed the most important part of the page (where you are) in the most prominent part of the page (the upper left). The company logo doesn't go there; Erin already knows where she works. Nor does the product name; Erin does not care what the name is of the software that enrolls her card. Erin only needs to know where she is.

The far right of the page is substantially less important for readers, but for someone who is not actively using the page (Sales), being at the top appears to be visually prominent; it is safe to put the company logo there. The bottom right of the page is the least important, so the Gemalto logo could be placed there. With the corporate branding requirements physically out of Erin's way, the links can be placed.

People don't read pages, they skim. I needed to visually delineate the different pieces of information on the screen to draw the eye, so I used lots of white space, larger fonts and as few words as possible so that even when skimming, the user is getting all the information.

I started with a plain English greeting and brief explanation. This would give Erin additional context should she get distracted or not completely understand the page title. I treat Erin like a human being and have a conversation with her through the copy. I provided the different options in plain English, describing the specific task she may be here for, and the entire sentence is a link as to maximize the area Erin can click on, meaning she can use a faster, gross muscle movement instead of a slower, fine one.

I put the whole thing on a plain white background with black text and blue links, which is the web-based presentation style with the most inherent affordances. In this way, Erin won't have to figure out a new interaction style, as is so often the case with “AJAX” sites that do not duplicate an existing interaction style.

Semantically, in case Erin is vision-impaired, the site is two headings, a descriptive paragraph and three links. It can be easily navigated with a screen reader, without CSS, at large text sizes or with a keyboard.

This was all that was provided, because this was all that was necessary for Erin's needs on the home page. I didn't provide the product name, I didn't put links in sidebars with large areas of unused page content, I didn't use unusual color schemes and I didn't link to administrative functions. Erin needed none of these things.

Primary Use Case

The primary use case is the initial card enrollment.

Erin clicks on “I need to set up my corporate badge for the first time.”

As no page of this application would be used more than any other (which is not the typical case in a web site or application), it was safe to duplicate the structure and presentation from the home page in order to preserve as much of the interaction style as possible. The more consistent I kept things, the faster Erin would be able to proceed.

The subtitle on this page, “Download certificates,” is slightly technical, but I hoped the brief explanation would give it a little more context. I used “Download” instead of “Enroll” because the latter term is more generally understood, but preserved “certificates” because I couldn't think of a more understandable, less technical term.

The new UI piece in this page is the “Steps” progress bar along the top. Particularly in new or unfamiliar situations, it is helpful to provide a “Wizard” or otherwise staged interface that provides a beginning and an end, with progress clearly delineated.

One (unsourced) criticism of the Gemalto NIM Reference UI was that I placed the steps in a horizontal progress bar style, as opposed to writing out “Step 1 of 3.” Both are valid approaches, but there are two reasons to prefer the horizontal progress bar style. The first is that the progress bar style provides a faster way to understand the information. You do not have to actually read the words, you can interpret the visual position as you would a traditional progress bar or slider. The second is that I have previously defined “where you are” as the current step; the rest of the process is tangential. The current step number is purely extra information and, if written out, should be less prominent on the screen than being immediately under the page title. However, if it is less prominent, it is less useful and might be ignored, making it simply a waste of space. Therefore, I argued to keep the horizontal style in the NIM demo, and so it remained.

Finally, on this page, it is clear that Erin must insert her card (if she has not already done so) to proceed; no other possible action is provided to her and it makes no sense to allow Erin to do anything else until the card is present.

Selecting a PIN

After the card is inserted and the certificates are downloaded, the second step is presented automatically, to choose a PIN.

I manufactured the process here, splitting PIN entry into two steps, instead of providing two text entry boxes on the same page. This does not come at an efficiency cost: entering four digits, hitting enter, entering four digits and hitting enter again is the same number of keystrokes as entering four digits, hitting tab, entering four digits and hitting enter. It may even be more efficient if Erin is habituated to using the mouse: by only providing a single text entry box on the page, she must hit Enter instead of reaching for the mouse to navigate to the next form field, saving time.

The most significant reason for the manufactured process is the original assumption that these are new and unfamiliar tasks. I am a friend walking Erin through a new process, and breaking new processes down into their fundamental, underlying elements provides greater understanding and associates them in Erin's memory more strongly. Erin is more likely to remember her PIN and associate it with her card if she has to enter it the second time after a page transition or other pause, recalling it from short-term memory, than if she enters it twice quickly, in a monotonous fashion.

At the time, it was argued that since “all” “change password” boxes used two form fields in a column, so should the PIN setting and changing process. However, it is not a given that Erin associates “changing a password” with setting her smart card PIN for the first time. Second, it cannot be assumed that Erin has used a smart card before. Most people have never used a smart card, and out of all smart card users, most have never set their password through a self-service web page. Third, even if the associations were present, users do not change passwords with any sort of regularity such that these actions are habituated into a mental pattern. Changing a password is always an infrequent affair.

Completing the Task

As described above, the third step is the same as the second. When the process is complete, a page is displayed indicating in plain English that Erin has accomplished all she set out to. No other navigation options are presented, as there is nothing else to do.

Unblocking the PIN

This exact same rationale is followed to design the PIN unblock pages.

Vista

I believed this design rationale was well-reasoned and efficient enough to bypass the previously unmentioned, 11th original requirement, that the UI be in the Microsoft Vista style. The design rationale does not preclude using a Vista font, background gradient and color scheme, but unless there is a Vista enrollment or walkthrough process that Erin is likely to have experience using, it would be ill-advised to mimic a traditional web page or desktop application UI for such a simple set of tasks and waste Erin's time with something that looks like Vista, but acts like something else, requiring her to figure out a new interaction method.

Changing the PIN

After the original requirements were set out and an initial draft of this design was presented, the requirement to support changing the PIN was added.

Implementation

This design was discarded in favor of the generic ASP.NET AJAX web site template.

I later implemented a variation on the design for the Gemalto NIM Demo Self-Service application, which had a similar usage scenario of salespersons setting up demonstration smart cards.