Employer Juniper Networks
Dates 2000 - 2008
Roles Designer, Developer

Secure Access was the category-defining, award-winning SSL-VPN developed by Neoteris, a startup acquired by Juniper Networks in 2004. The product line, along with other enterprise-focused security products was sold off in 2015 as part of Juniper’s re-focus on their core routing business.

As the first UI guy...

I worked primarily with product managers, tech marketing, and engineers to specify functionality, and maintained a high-fidelity interactive prototype to explore design concepts and complement specifications. Much of the code and assets developed for the prototype went straight into the product itself.


Dashboard: The dashboard page was the first page an admin would see upon logging in. The graphs were just images, updated on a regular interval, showing current and historical activity on a variety of measures. Nowadays, Ajax would be the obvious way to go here.

Dealing With Complexity

Over time, the sheer number of features and flexible configurability was reflected in the increasing complexity of the UI. Although the product supported a wide range of customer needs (and thereby had great market share), usability for administrators was becoming a concern. The following screenshots show some of the ways we tried dealing with that compexity.


Menus: As features piled up, the information architecture became more and more complex. We sometimes refactored screens, but there were still a lot of clicks involved. So we added hierarchical menus to the navigation bar, to allow one-click access to more parts of the system. Despite the anticipated Fitts’ Law problems, this addition was well-received by the field.

The following version added most-recently used (MRU) lists to some of the menus, allowing admins to drill down even further into the configuration. This screenshot shows a user drilling down to the Session Options page for the "employees" role. Without MRU, getting to this page would take 4 clicks. Now it can take a single click (albeit with careful mousing).


Configuration overview: This screen makes clear there are 3 major types of objects to manage (Realms, Roles, and Resources). Further, it allows users to explore the relationships between these objects, highlights potential problems, and provides allows creating and editing the objects right from here.

In short, it provides a single, powerful view of key parts of the configuration. There are other areas in the UI that would benefit from similar, big-picture views. If I was to do this sort of product again, one with many interrelated parts, I would probably try to make screens like this the backbone of the UI.


Task guides: When the UI does not support a given task very well, a common request is "we need a wizard." Wizards have their place, but all too often, they are a crutch. If the UI has a problem, the UI should be fixed, not covered with a band-aid.

At the same time, the system's navigation was organized by function, and some tasks required users to visit multiple pages scattered throughout the product. Task guides provide a way to not only explain the steps in a task, but to also provide links to the relevant pages.


Dependencies: Finding yourself in the middle of creating one type of object that depends on another that you haven't created yet was a problem. Having to back out and go somewhere else to create the other object, and then have to go back and start over with the first object is understandably frustrating.

We addressed this by making it possible to create the related object without losing the context. In some cases, dialog worked well, but frequently the forms involved are too complex. Thus, the screen might change, but after creating the subordinate object, the user is returned to their previous context.


Progressive disclosure. When a section of UI is not relevant, that portion would be hidden to reduce visual clutter.


Inline editing. In some cases, smaller forms were converted to an inline form that was directly editable.

Network Connect: A Not-So-Simple Login Screen

As originally conceived, Secure Access was a browser-based solution. Richer client-based elements were inevitably added into the system. Network Connect was one example, essentially leveraging the Secure Access gateway as a replacement for IPSec VPNs.

Unfortunately, the initial implementation presented a terribly awkward user experience:

  1. Launch Network Connect
  2. Type in a login URL
  3. Click a button labeled “Fetch Realms” *
  4. Wait for a connection
  5. Select from a list of available realms
  6. Click a button labeled “OK”
  7. Type login credentials
  8. Click a button labeled “Login” (finally!)

This is mostly based on how things worked in the browser (although even the browser was less clunky). This clearly wasn’t appropriate for a desktop UX. After much discussion, debate, and compromise, the UX became:


1. When Network Connect is launched, it automatically connects to the last known gateway and gets the list of available realms. (This replaces steps 1-4 above. The gateway is typically pre-configured, and typically doesn't change, so user needn’t care about this.)


2. Enter login credentials. This is reasonable enough. (This replaces steps 5-8. If there is only one available realm, as would typically be the case for most users, the realm credential does not even appear.)

The design itself isn’t particularly exciting. But it’s simple. Boring. As it should be. It’s a good example of how good UX doesn’t just happen. It requires work, persistence, and persuasion to make it happen.