Architecting the Management User Experience 

The architecture section is designed to help you identify how your management tool should be organized to provide a consistent management user experience.

After performing the steps in this section, you should have a list of:

• User types and scenarios.
• Object types to be managed and their associated actions.
• Activities in order of priority.

Identify the Types of Feature Users

Simpler features will likely have only a single user type. Complex features usually require support for more than one type of user. For example, support could be required for a server administrator who sets up the infrastructure of the feature as well as for a data administrator who maintains the objects contained in the feature.

Guideline 1 Collect a list of all user types for the feature.

Good sources of information about the types of users of the feature could be market research and the initial goals that were written into the specifications. If the feature is similar to another feature, try to collect information about the users of the similar feature, if appropriate. If new markets have been targeted, look for existing research on the intended users of the feature. The following are examples of features that support multiple user types (in addition to the first-time user, who must always be included):

• The DHCP role in Windows Server® is a set-and-forget type of feature that is not typically accessed on a regular operational basis. Support of a single user type for configuration, maintenance, and troubleshooting is reasonable.
• An IT system monitoring system, such as Microsoft Operations Manager (MOM), has at least two user types. The first user type is a person who is familiar with enterprise policy and security considerations, and with setting up and maintaining the product. The second user type is the operator who evaluates the daily reports and created the trouble tickets. There is very little overlap between the two user types.
• A database management tool, such as Microsoft SQL Server, has at least three user types. The first user type sets up and configures the product. The second user type is a database administrator who ensures that the data structures are up-to-date and consistent. The third user type analyses the data from the database, usually by creating scripts to ensure that the results are consistent and repeatable. Because the three SQL Server user types have few shared activities, each should be provided with a distinct user experience.

Create User Scenarios and Task Lists

Although you might have begun this design process with a technological solution in mind, it is important to put that aside at this point and to look at the feature solely through the eyes of the feature user. If you have several types of users, then you should create user scenarios and task lists for each user type. As you develop your scenarios, consider the steps that each user type would have to perform in a real-world situation.

Guideline 2 Collect a list of all user scenarios for each user type.

When building your scenarios and task lists, you should always consider the following cases:

• First-time or installation sequences, with attention to defaults so that even an unfamiliar user can get the feature up and running
• Infrequent and ad hoc use of the feature
• Frequent use of the feature by someone who specializes in your feature

Identify the Object Types and Associated Actions

Almost every tool interacts with the objects that are represented on a computer system (objects such as files and directories in a file system or programs that can be loaded and run from the Windows Start menu). Object types can be thought of as the “nouns” (such as files or programs) to be managed and are typically represented in the UI as containers for objects and other object types.

Guideline 3 Collect a list of object types managed by the feature, including all the actions that can be applied to each object type.

Actions can be thought of as the processes (such as Add, Copy, and Remove) that apply to the objects. You can think of actions as the “verbs” associated with an object type (noun). Therefore, when you define each object type, you must also identify the actions that will be displayed whenever that object is selected. For example, a directory of files (object type) will have associated actions such as New, Open, and Delete.

Identify the Feature Activities

Activities are a collection of actions that are applied to one or more objects managed within the feature. While the first design pass can generally use a technology-based language to describe the feature capabilities, activities should be described in terms of the user scenarios and task lists before the final terminology is selected. Examples of activities might include Create User, Apply Update, Perform Back-up, or Create a personal list of servers to manage. Actions are specific methods applied to a pre-selected object. For example, once the user has selected an install package the actions shown might include Remove, Install, Search for Recent Update, or Send to Another Server for Installation There, etc.

Guideline 4 Collect a list of all the activities that need to be performed by the users of the feature to cover all the user scenarios.

After you have a complete list of activities, you should group them in a way that makes them easily discoverable. Then, you should use the completed scenarios to create the best presentation of activities for the target user types.

Guideline 5 Collect a list of all the activities by importance and assign each to a user type.

After completing this analysis, you should have the data necessary to start designing and constructing your management tool. By understanding the user types and associated scenarios of your feature, you will be better able to organize and present the object types, actions, and activities that represent the management capabilities of your snap-in.

The Constructing Snap-ins section will show you how this is done within the MMC 3.0 framework.