Overview
The Forefront Security Suite is an Enteprise level solution which provides advanced computer and network protection for large organizations. It contains many UI surfaces, including a centralized management console, individual client applications, wizards, and other assorted pieces. Vastly different from my previous experience in the E-Commerce space, Forefront required me to ramp up on a technically advnced software, and deliver the best user solutions space in a very short amount of time. The following sections present various UI elements that I personally designed. I must give recognition to the teams that I worked with on this project - both the engineering and fellow PMs - as a project of this magnitude is not created in a vacuum by one person.

Microsoft Forefront
Branded Splash Screen

Design Process
I came onto the Forefront Security team as a User Experience Program Manager. Again I would be calling on my background as a User Interaction Designer, and Feature PM, to help define and drive towards a usable security administration experience. As with my previous projects I gathered the information I needed before proceeding with any design work:

Scenarios - User Personas - Use Cases - Focus Group and User Feedback

While there was a large amount of documentation, much of it was being redefined when I came on the team, and as such it was only partially helpful. This was going to have to be designed on the fly, with looming deadlines approaching fast. Particularly helpful was the prototype UI work that was built by several Developer teams. While functional, these prototypes needed major UI work to be even remotely usable.

Often there are existing UI Guidelines to rely upon for similar applications. However our sister project, System Center, was also in the process of completely revising their UI model and would not be finished in time for us to rely on their fine work. We took the only path available to us in the time alloted - aim towards the same design patterns as System Center, revising as we can along the way, and define our own model as best as we can. With this in mind, I began building our User Experience, and writing my design specifications.

Console Design
I needed to formalize general UI guidance on how the entire application should function. Up until now, nobody had taken on this task and each individual feature area was coming in hot. The first versions truly looked like five different products all in the same window. It was a usability nightmare. The core layout was there in a rudimentary sense, but my specifications began to pull it together in a more formal fashion, staring with the main "frame":

This frame also resembled the direction being taken with other server applications. A bonus to any of our users who may have learned how to use these tools. After defining the layout, I began working out how this should look in a typical environment (image from an early design specification):

Many discussions were held over how the navigation system was to work in our UI, and in previous versions this entire panel changed state depending on where the user was in the UI. We moved to a common model, as seen in the following image which shows our left-hand navigation screen and "Wunderbar"

Another area that presented itself in a different fashion throughout the UI was our standard list views. These views operated differently, like the navigation pane, depending on where the user was in the application. This was a huge usability issue, and one that was (at first) to be put on the back-burner as far as the design was concerned. Luckily a common solution was decided upon, one that brought many common elements into a more useful design:

Aside from simply presenting a list of data, with column headers that can be sorted by the user, I introduced a preview pane showing data on any selected item. Many of these lists were intended to present hundreds, if not thousands, of individual data elements - numbers that are far beyond what can be easily presented in a single screen with a paging function. To help users find what they're looking for, we introduced a filter/query mechanism to isolate individual items, making it easier to locate their targets:

And if there is ever a truism in UI Design it may be something like this - "the design concepts that you think are the simplest in nature, will be the ones that generate long, and contentious arguments". As was the case in our standed "edit dialog box":

Previously, all of our data editing occured within the main frame of the application itself. It was not in a modeless dialog box as I suggested in our later stages. A modeless dialog is one that can appear above the surface of a UI, but will not prevent the user from moving to other areas (like an email message in any standard email application). Moving to a modeless data editing model gave us vast improvements in the basic usability of the console. It provided a more sane surface to expose our unusually large policy settings, and a better way to navigate through the individual units. The modeless dialog also gave us the ability to compare the settings of multiple policies, something missing altogether in previous iterations.

Dashboard
The Forefront Dashboard is intended to be a real-time monitoring system, showing any administrator the condition of their deployment at a glance. It is made up of individual views of data, and each view is comprised of various charts, graphs, and lists which allow the user to drill into various conditions and assess the state of their Enterprise. My first task was to catalog and map the views, as planned, early in the project. The UI Map below (very large) is a sample of this mapping:

From there it was imperative that design patterns be defined for these views, and how the individual controls were to be shown to the user. The system architecture and code for this feature was mostly in place when I arrived on the team. My task become one of coalescing a UI plan which we followed through the next phases and onto our final release.

One of the more contentious issues was a control intended to show the user the ultimate condition of the system. This would take into account all of the various levels of criticality, good and bad, and would be present at the front end of the Dashboard. Visually this was a difficult concept to communicate - questions surrounding the meaning of these states were ongoing. In the end it was decided that four states would comprise this control, and then it became a question of how to visually show these states in a manner that would carry meaning.

I began by finding icons that were commonly used for similar severity - and using a color shift the user would get an instant view of what the state was at that time. But then you had to ask "what happens if the user is color-blind?" This led to two additions to the control - first, explicit text was added so the user could read what the condition was. Coupled with the icon shape (disregarding the color), the severity was still legible. An alternate design placed the icons in a specific order, which would help denote the level (also disregarding the color itself).

Usability Lab Testing
At three different stages in the project, we took our work to the usability labs for testing on unsuspecting users. Usability lab testing is one of my favorite parts of being a User Experience Designer. You really don't know what you're going to find when you put someone in front of your UI. What will they understand? What will they stumble on? What will they like? And most importantly, how long will it take before you hear even the most calm, cool, and collected subject lose their mind in frustration?

The labs themselves are pretty spectacular. Each lab is constructed with two rooms seperated by a one-way mirror. The subject is put in front of a computer that has been set up with the application in question. In our case, we used a combination of animated walkthroughs and prototypical UI that I helped create, and in several cases live code. Our findings were then brought back to the team to be corrected as the project progressed.

Client UI Revision
Along the way I was asked to tackle a revision of the Client UI - the piece of software that would reside on every computer in the organization. Functionality for this experience had already been defined, what I was tasked with was re-arranging the existing controls in a more readable fasion, plus add our new product branding.

Neither of these designs made it to the final version, due to further changes in the project. However my branding work remained, and I'm personally happy with the revisions above.

Branding, Color Palettes, and Iconography
My background as a designer and artist came in handy when it came the creation of our branded elements, color schemes, and iconography. Creating color palettes is a skill that I learned in Industrial Design school, and I used this heavily during my years as a Senior Artist at Bethesda Softworks. In the following examples, we needed specific color schemes to help communicate a variety of information through our dashboard.

It was critical to have both a color scheme that denoted a specific level of severity - many of the charts and graphs in the Dashboard were designed to be read and understood at a moment's notice by our end-users. In other cases, the charts were intended to simply compare information without denoting severity - this required a more sedate and generic color scheme.

The typical end-of-project tasks involve the integration of final Branding and logotypes, courtesy of our fine Marketing divsions. Like other server products at Microsoft, our Brand was crafted as a family by a centralized team who provided us with specific guidelines on how to use the various graphic elements: background gradients, grids, and logos. Each of these needed to be integrated into specific areas of the UI application, replacing existing (and functional) elements like Splash Screens and Dialog Boxes. In the examples below, my annotations of the functional (and at the time, existing) screens are shown next to the final version.

This dialog box is used by the user to connect to a specific server, and an excellent opportunity to showcase the product brand.

A typical "Help / About" Dialog box.

And our product splash screen.

External Teams
This was a very large organization, and part of my time was spent working on the User Experience of some of our partner teams. These teams were located as far away as New York, Israel, and China. The images below represent some of the early work I did for the Microsoft Exchange Protection application. This was to be a free-standing version of our protection technology, which would gracefully integrate with the rest of the suite as needed.

The User Experience differed slightly, as you can see in the image above. The navigation and edit model were more like the earlier versions of the Forefront UI Design, but I worked hard to merge it with our later efforts.

While challenging to coordinate efforts with teams in different timezones (and different continents!), I enjoyed the experience. Perhaps more so than my fellow co-workers realize, given the often stressfull circumstances found in a version one project of this magnitude.