Ana səhifə

Software Designed For Your People


Yüklə 268.36 Kb.
səhifə3/10
tarix18.07.2016
ölçüsü268.36 Kb.
1   2   3   4   5   6   7   8   9   10

Reflecting the Model in Software


The customer model is ultimately being used to design user experience that directly supports the specific work a person does.
Based on an individual’s role there are three possible primary experiences:

  • Microsoft Dynamics Client – Some people spend most of their day working within the Microsoft Dynamics client and really have no need or interest in leaving it. They would like information from other systems and applications such as Office to be surfaced directly in their Microsoft Dynamics client.

  • Microsoft Office – Some people spend all day in Office applications but on occasion need information from backend systems. They would prefer this to be available to them in Office directly so they do not need to learn additional applications.

  • Business Portal – Some people only interface with backend systems in the context of a specific process. They would like an experience specific to that process that leads and focuses them in an optimal manner. For these people we can combine all the elements they need in a set of simple web based screens.

Microsoft Dynamics Client


The user interface (UI) in Microsoft Dynamics products will be based on the customer model in a number of ways:

  • The information architecture of the UI (how information and tasks are organized) will be based on the customer model. The goal is to organize the UI so that it matches each individual’s work.

  • The information and tasks presented to users in the UI will be based on the customer model.

  • Although current products are based on the customer model ,we are working toward shipping a configurable customer model within the product with a goal of letting customers maintain their specific customer model which in turn drives the UI



Figure 4: The relationship of the Customer Model to User Interface design.

The industry a company operates in and the complexity of the department in question are key influencing factors in what specific roles an individual holds and therefore the processes they will participate in. It also determines how intricate a process is - which parts of the theoretical maximum process are used and how the process breaks down into activities and tasks. We will ship a default definition of this based on department complexity and partners and customers can customize this and modify it over time for their specific industries.

Here is a more detailed view of how we do this:



Figure 5: Detailed view of processes and roles surfacing into User interface design

To the far right of this diagram you can see how the navigation structure in the application itself is derived from the model:

At the highest level, the combination of roles a user has translates into a Home page - with links to the processes they participate in. Within the navigation structure on the home page, a user can access a variety of “Activity Centers” with all the tasks the user performs in a specific process. Finally the tasks for each process step are available in a Task Page.

For example if you looked at the work that an accounts payable clerk (April4) typically does and apply the methodology above to the customer model definition of April, her full experience will look like this:





Figure 6: Microsoft Dynamics home screen for April, the accounts payable clerk
In the main pane of the screen we see a number of key user interface elements or “parts” that are used to define the user experience. These parts are consistent across different roles, but the information they expose varies for each person depending on the set of roles they hold and processes they participate in. In this case we see:

  • Activities – The activities part gives April a visual representation of the key work she does. The stacks of paper in the different categories easily allow her to see how much is outstanding and she can set alerts and notifications if certain thresholds are reached as you see in the case of Due Invoices.

  • Outlook – As April typically spends all day in the Microsoft Dynamics client, we are surfacing key office information from Outlook here so April can see it without having to switch context.

  • Contextual Business Intelligence – April has key information she needs to see to be able to make informed decisions in her work. In this case she is interested in balancing the discount she can get by paying different invoices versus keeping sufficient cash on hand. Rather than being required to hunt out a variety of reports she is presented with the information she needs most on her home page.

  • Alerts – This part shows April the exceptions to the standard processes and workflows she participates in that need her immediate attention.

On the left hand side navigation bar you can see links to one Activity Center for each process April is involved in. These are surfaced based on the processes and tasks her role works on as defined by the customer model in the following manner:



Figure 7: Designing April’s Navigation
Here is a another example using the persona of someone who works in the warehouse in shipping and receiving: “Sammy the Shipper.”
You will see in this case there are a number of consistent parts such as Alerts and Activities but the content is specific to what Sammy works on in the warehouse. Although not shown in this case, the experience for Sammy was also defined as shown above based on the definition of Sammy in the customer model.



Figure 8: Sammy in shipping and receiving’s home screen

1   2   3   4   5   6   7   8   9   10


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©atelim.com 2016
rəhbərliyinə müraciət