Hold on to your hat as you run to buy the great new release from Microsoft Press, Inside Microsoft Dynamics AX 2012, by the Microsoft Dynamics AX Team! If you didn’t see the RTM post a couple weeks ago, you’ll want to know that this book is the result of a collaboration of 20+ authors and just as many reviewers from the Microsoft Dynamics AX Team. After many months of hard work and determined cooperation, Microsoft Press is glad to have a strong and in-depth offering from a group of writers and developers who are passionate about their product.
Dig into the architecture and internals of Microsoft Dynamics AX 2012—with firsthand insights from the team that designed and developed it. Targeted for solution developers and system implementers, this guide focuses on programming and customization capabilities—including key architectural principles, the application model, framework, and tools.
You can purchase the book from here and here.
Please enjoy this excerpt from Chapter 5, Designing the user experience.
In this chapter: Introduction A role-tailored design approach User experience components Role Center pages Area pages List pages Details forms Transaction details forms Enterprise Portal web client user experience Design for your users
Microsoft Dynamics AX 2012 has been marketed as “Powerfully Simple.” Making this a reality was not just a marketing slogan, but instead was a key design goal for the release.
As an enterprise resource planning (ERP) solution, Microsoft Dynamics AX must provide the many powerful, built-in capabilities that are required to run a thriving company in the twenty-first century. The needs of organizations are becoming more complex. Companies are trying to organize themselves in new and unique ways to become more efficient. Leaders of these organizations are asking their people to achieve more with less. Governments want more transparency in the business operations of a company. Combined, all these things increase the complexity of running a business and the demands on an ERP system.
The challenge for Microsoft Dynamics AX 2012 was to harness these powerful capabilities in a way that users would find simple to use. There is a natural tension between these goals, but that tension is far from irreconcilable.
At Microsoft, simplicity is defined as the reduction or elimination of an attribute of the design that target users are aware of or consider unessential. The easiest way to simplify a design is by removing elements from that design. For example, if you want to simplify the experience of creating a new customer, you can do so easily by reducing the number fields that the user needs to complete on the new customer form. With fewer fields, the user can complete the form in fewer keystrokes, which also minimizes the chance that the user will make a mistake. The problem is that fields can’t simply be removed from the new customer form because those fields are required to support the powerful capabilities that customers need.
So to have a simple and powerful user experience, Microsoft Dynamics AX 2012 has been designed for the probable, not the possible. To design for the probable means that you need to truly understand what the user is most likely to do and not assume that all actions are equally possible. You can focus your designs on what is likely, and then reduce, hide, or remove what is unlikely.
For example, Microsoft Dynamics AX contains approximately 100 fields that contain information about a customer. In the prior release, when the user created a new customer, the Customer Details form presented all 100 fields. The user had to look through all these possible fields to determine what to enter. Microsoft Dynamics AX 2012 introduced a new dialog box (Figure 5-1) that appears when a user creates a new customer. This dialog box displays the 25 fields that users are most likely to use. The user can simply enter data in these fields, and then click Save And Close to create the new customer. If the user needs to enter more detailed information about the customer, he or she can click Save And Open to go to the full Customer Details form to enter data in the other 75 fields.
FIGURE 5-1 Simplified Customer dialog box.
This chapter describes the key concepts of the Microsoft Dynamics AX user experience and explains how you can extend the capabilities of the product while maintaining a focus on simplicity.
This chapter supplements the Microsoft Dynamics AX 2012 User Experience Guidelines on MSDN (http://msdn.microsoft.com/en-us/library/gg886610.aspx). For more detailed information, refer to these guidelines.
Designing an ERP system that is simple for all users is challenging because many types of users use the product. The pool of users encompasses more than 86 roles, and those roles use Microsoft Dynamics AX for many different scenarios. These scenarios range from picking and packing items in a warehouse to processing payments from a customer in the finance department. It is not surprising that users in these various roles have different mental models for how the system should work for them. Designing the user experience for specific roles provides a much better experience than providing the same experience for all users.
Historically, ERP systems were designed as a thin wrapper around the tables in the database. If the database table had 20 fields, the user interface would display those 20 fields on a single form, similar to how they were stored in the database. When a new feature was needed, new fields were added to the table and those fields were displayed on the form. Over time, ERP systems became very complex because more and more fields were added without regard to who would be using them. This led to user experiences that were designed for everyone but optimized for no one. The end goal of a role-tailored user experience in Microsoft Dynamics AX is to make the user feel as if the system was designed for him or her.
In Microsoft Dynamics AX 2012, the user experience is tailored for the various roles that the product targets. The security system includes 86 roles that system administrators can assign to specific groups of users. The user experience is tailored automatically based on the roles and shows only the content that is needed by a user who belongs to a given role. Based on the user’s role, actions on the Action pane, fields, field groups, or entire tabs might be removed from certain forms. With each field or button that is hidden, the product becomes easier to use. The menu structure is also tailored so that each user sees only the areas or the content in these areas that pertain to the user’s role. Users feel like they are using a smaller application tailored to their needs, as opposed to a large, monolithic ERP system. For more information about working with roles, see Chapter 11, “Security, licensing, and configuration.”
To illustrate this concept, look at the navigational structure for Microsoft Dynamics AX 2012. The product contains 20 area pages targeting the various activities needed to run a business. While a system administrator sees all these areas, a specific role such as a Shipping Clerk, Purchasing Agent, or Order Processor sees only the four to six areas that relate to the role, as shown in Figure 5-2.
FIGURE 5-2 Role-tailored navigation
In Microsoft Dynamics AX, user experience components are divided into two conceptual layers: ■ The navigation layer consists of top-level pages that serve as a starting point for user as he or she navigates through the application. Area pages, Role Centers, and list pages are navigation-layer elements. ■ The work layer consists of the forms in which users perform their daily work, such as creating and editing record and entering and processing transactions. Details forms and transaction details forms are work-layer elements. Figure 5-3 illustrates how the user navigates through the primary elements that make up the Microsoft Dynamics AX 2012 user experience. The following sections describe these elements in detail.
FIGURE 5-3 Navigation paths through Microsoft Dynamics AX 2012.
Navigation layer forms such as the Role Centers, area pages, and list pages are displayed within the Microsoft Dynamics AX Windows client in a flat navigation model. This model is similar to that of a website, in that pages are displayed within the content region of the page, replacing each other as the user progresses from one form to the next. The client workspace consists of the following components, as illustrated in Figure 5-4: ■ Address bar Provides an alternate method of navigating through the application. A user can type a path or click the arrow icon next to each entry in the path to select the next location. The address bar has buttons that allow navigation backward and forward between the recently displayed pages. The address bar also provides a mechanism for the user to switch companies because the current company is the first entry in the address path. ■ Search bar Lets users search for data, menu items, or help content. The user can use the search bar as an alternate method of navigation if he or she doesn’t know how to find a particular form. The search bar is an optional component that must be configured as part of setup. For more information, see “Enterprise Search” at http://technet.microsoft.com/en-us/library/gg731850.aspx. ■ Navigation pane Appears on the left edge of the client workspace and is used for navigating to the various areas within the application or the user’s list of favorite forms. Optionally, this pane can be collapsed or hidden through the View menu. ■ Content pane Appears to the right of the navigation pane and displays top-level pages, such as area pages, Role Centers, and list pages. ■ FactBox pane Appears at the right of the workspace and provides related information about a specific record in a grid. The FactBox pane appears only on list pages. Users can personalize the contents of the FactBox pane by using the View menu. ■ Status bar Appears at the bottom of the workspace and displays additional information in a consistent location, such as user name, company, or notifications. The user can personalize the contents of the status bar by using the Options form (Click File > Tools > Options).
FIGURE 5-4 Client workspace components.
The remaining forms in Microsoft Dynamics AX are where the user performs work such as configuring the system, creating new transactions, or entering information into journals. These forms open in a new window that is separate from the client workspace. The work layer pages are described in detail in the upcoming sections.
A Role Center page is the user’s home page in the application. A Role Center provides a dashboard of information that pertains to a user’s job function in the business or organization. This information includes transaction data, alerts, links, and common tasks that are associated with the user’s role in the company. Microsoft Dynamics AX 2012 provides different Role Center content for the various roles. Each Role Center provides the information that the users who belong to that role need to monitor their work. A Role Center also provides shortcuts to frequently used data and forms. Each user can personalize the content that appears in his or her Role Center.
A cue is a visual representation of a query that appears as a stack of paper. A cue represents the activities that the user needs to perform. The stack grows and shrinks as the results of the query change. Cues are an excellent way for users to monitor their work. For example, an Accounts Payable clerk can monitor a cue of pending invoices, invoices due today, or invoices past due, as shown in Figure 5-5. Clicking a cue opens the appropriate list page with the same query applied. When the clerk wants to act on the invoices, the clerk clicks the cue.
FIGURE 5-5 Activity cues.
While Microsoft Dynamics AX includes great Role Centers for the various roles, they must be customized to meet the needs of the people who will be using them. It is highly recommended that partners and system administrators take the time to customize the Role Centers for the various users within the organization.
Designing a great Role Center requires a deep understanding of the user. Here are a few techniques that you can use to help understand your customers: ■ Survey people in the various roles to understand the top 10 questions they have related to their job. Then, explore ways that you can provide answers to as many of those questions as possible with a Role Center. ■ Show users the content of their default Role Center on a piece of paper. Then, ask them to circle the content that they find useful and to cross out the content that they don’t find useful. You can also give them a blank piece of paper to sketch out additional content that they would like to see. Users typically get excited with these types of exercises because they feel empowered describing what they want from their ERP system. ■ Observe users performing their daily tasks. Often, users cannot articulate what they need to become more efficient, but it may be obvious if you observe them performing their jobs. As you are observing them, watch for the patterns that emerge in their work. ■ Find out which forms users open frequently, and consider adding links to those forms to the Role Center QuickLink on their Role Center or a favorite in their navigation pane. A QuickLink is a part on the Role Center that provides quick access to any form within Microsoft Dynamics AX. ■ Find out if users frequently go to a list page and filter the content to see a particular group of records. If so, you can make them more efficient by adding a cue to the Role Center that is configured to provide direct access to this list with the appropriate filter applied. For some users, we’ve seen Role Centers that have been customized to include a page full of cues that were needed by the user. ■ Summarize frequently viewed reports as a chart or graph.
Here are a few other things to consider when you design a new Role Center or extend an existing Role Center: ■ Remove any parts that users don’t need. ■ Place the most important content toward the top of the page. ■ Ensure that the page loads quickly, within 2 to 5 seconds. This may require you to optimize the queries and cubes that display the information within these parts. For more information about optimizing queries, see Chapter 13, “Performance.”