Strategy 9. List the most important Business Decisions

Make a list of the Business Decisions which must be made during the usage of a system. Again try to rank the list and identify the 5 to 10 most important. Make a secondary list with the remainder.

A clue to finding the Business Decisions in the system. Look at the output from Strategy 4. (b), nouns and verbs categorised by Archetype, Moment in Time e.g. Sale, Order, Application. If a Moment in time was important enough to be in the requirement then it probably reflects that a key business decision is being made.

Our list might look like

• Approve Credit Limit
• Cancel Credit Limit
• Initiate Debt Recovery
• Approve Refund
• Accept returned goods

9.(a) Categorize Business Decisions by User Role

Identify the User Roles which are involved in each Business Decision. Group business decisions by User Role.

9.(b)Prioritise Business Decisions

Identify what is most important. Often the most important Business Decision for a system will be contained in the original statement of purpose, e.g. "Ambulance Management System", control the dispatch and allocation of ambulances across the city. Clearly this would indicate that a key Business Decision is "Dispatch Ambulance". This is a good clue as to where the main effort should be placed when developing the UI Design.

At DDD Co, the key decision is

• Approve Credit Limit

with these next two taking a secondary importance due to the regularity of occurrence

• Approve Refund
• Accept returned goods

The other two would not rank as important (for UI focus) because they happen so seldom.

Note: From the introduction to Strategy 9, we haven't looked further at Moments of time such as Sale or Order. This is because these are actually on-going business tasks, they do not represent business decisions as such.

Strategy10. List things which affect a Business Decision

For each Business Decision list the 5 to 10 most important things, tasks or actions which affect that decision. Put additional items on a secondary list.

10.(a) Sort the list into verbs & nouns.

Classify the things which affect a Business Decision into verbs and nouns. This will affect shape and navigation in the UI. The nouns which affect the business decision probably have to be displayed together. The verbs are the actions which must be taken either before, after or during the making of the decision. These will give an indication of the actions or navigations which must be presented when the business decision is made.

10.(b) Rate the known verbs and nouns

From the primary and secondary list of verbs and nouns gleaned from strategies 1 through 3, use what you have learned about Business Decision to rate all the verbs and nouns by Business Decision. Use the grading of Business Decisions from Strategy 9.(b) to refine the list.

10. (c) Identify Collections affecting a Business Decision

From the list of nouns, identify those which are actually collections of data, from Strategies 6 & 7. You already have a collection - the list of nouns associated with this one business decision. If those nouns, in turn, are themselves collections then you have another instance of Shape Pressure.

Example: Financial Statements

Financial Statements is a collection over time. We collect them from the Customers each year. Do we need?

• the latest financial statement
• the collection of financial statements
• the comparative data across financial statements
• some combination of the above 3

10. (d) Rate each Business Decision by its constituent parts

For each Business Decision, assess the rating of the User Roles, the verbs and nouns from the original Core Strategies. Do they fall in the first 3 to 5 on the list? If so, then you have identified an instance of Business Pressure. If you only have one of these, then you have identified the main purpose for the system and the area where the UI Design must concentrate. If you have many of these then you have a real design problem on your hands.

Strategy 11. List Process Steps

Take the list of key artifacts from step three, e.g Credit Application Form, and identify the process steps involved in its life cycle. Draw up a list of the process steps and order them.

11. (a) Categorise the Process Steps by Verbs and Nouns

Classify the things which affect a each Process step into verbs and nouns. This will affect shape and navigation in the UI. The nouns which affect the process steps probably have to be displayed together or in sequence or according to the current "state" of the process. The verbs are the actions which must be taken at each step in the process or at unique steps in the process. These will give an indication of the actions or navigations which must be presented as the process executes.

11. (b) Separate out process by Synchronous and A-synchronous

For each series of steps, identify whether the steps must be performed in a given order or can be performed and completed in any order at any time.

11.(c) Challenge the Business Process

If you feel that the process requirements are leading to a difficult and perhaps unusable design, then challenge the processes. Ask the Users to examine how they work and how they might simplify the tasks or steps involved. For example, it may be easy to persuade them that an a-synchronous task can be done synchronously. You may already know that 90% of Users perform the task synchronously because you have already interviewed them.

Be prepared to produce other evidence such as User Interview scripts, to back up your suggestions.

11. (d) Separate out Process Steps by User Role

For each User Role, list the Process Steps you have identified.

Across the User Roles are the Process Steps similar or different?

Do we need a single design that suits all Users, or one for each User Role or set of User Roles?

This analysis will help you identify areas of co-operative and collaborative work. From Strategy 11. (a) you have a list of Process Steps which involve actions on the one Object, in our example above. This clearly shows a pattern of co-operative working. The Salesman, the Order Processing Clerk, the Credit Clerk must all co-operate together to get the task complete. Co-operative working patterns tend to come from Process Steps as series of actions - performed by different User Roles - or from Process Steps which happen synchronously - performed by different User Roles

We can also look for areas of Collaborative working. These will tend to come from Process Steps as a series of Objects and/or from a-synchronous process steps. From the earlier example

Here the Salesman and the Credit Clerk working collaboratively, compile together (assembling) the final product which then leads to a key Business Decision or Event.

Strategy 12. Identify Arbitration Systems

From Strategy 11 (d) you have idetified a number of Co-operative and Collaborative operations within the system requirement. Any form of co-operative work and some forms of collaborative work, implies that there must be an arbitration mechanism when things start to break down.

e.g. The Salesman asks "Approve this order", the Credit Clerk replies "Reject - insufficient credit", the Salesman says "Increase Credit Limit", the Credit Clerk replies "No - bad credit rating". This could go on for some time back and forward without resolution.

In the example above the Arbitration Mechanism is probably to escalate to the Chief Accountant who makes the final decision.

For User Interface Design purposes, it is important to identify these arbitration mechanisms and identify who and what is involved.

12. (a) For each Arbitration System, identify the Business Decisions involved.

Make a list of all the Business Decisions which are affected by an Arbitration System. In our example, we have

• Award Customer Credit Limit,
• Extend Customer Credit,
• Make Sale,
• Deliver Goods,
• Continue Business Relationship with Customer ( perhaps biggest of all)

12. (b) For each Arbitration System, identify the User Roles involved.

Make a list of all the User Roles involved, in creating the arbitration scenario and in resolving it.

12. (c) For each Arbitration System, identify the tasks or actions involved.

Make a list of actions, e.g. Accept, Reject, Overruled, Appeal. If it's a long list then follow the basic strategy and reduce the list to the 5 to 10 most important actions. Put the rest on a secondary list. It is unlikely that Arbitration will have so many actions.

12. (d) For each action identified in 12. (c), categorise by User Role from 12. (b)

List the actions against User Roles. Are they the same or different? Almost certainly different, though several User Roles may have the power to act as an arbitrator. Perhaps Arbitrator is a User Role?

12. (e) For each Arbitration System, identify all the artifacts/things involved.

Make a list of all the nouns which must be available in order for the Arbitration Process to be completed.

For the example of a disputed credit limit for a customer order

• Order Form (order details)
• Current Credit Limit
• Account History
• Current Financial Statements
• Credit Rating Report
• Comments

12. (f) For each artifact/thing identified in 12 (e), categorise User Role from 12. (b).

Against each User Role involved, list the nouns against the Role.

Are they the same or different?

Must we present different information to different people involved?

Assuming that we have got it right then this example shows that the data required by each User is the same.

Strategy 13. List the Workflow paths

With the results from Strategy 11, relook at the Process Steps list and pay particular attention to loops, in the life cycle. Can a form be rejected? What happens then? Does it get modified and represented? We need to identify the key workflow scenarios and any exceptional cases.

Loops in a workflow tend to complicate the User Interaction. They create scenarios where a conversation has to take place with the User, e.g. "The order placed has been rejected by Accounts due to insufficient customer credit. Please modify and try again." Requirements like this highlight problems such as

• how do we inform the User?
• what can the User do next?

13 (a). Make a list of the most popular workflows

Again, we're after the 20% of workflows which will cover the 80% of cases. If we're lucky, we may have hit a business requirement where 99% of cases follow the same flow. Obviating where the User Interface needs to be focusing.

13.(b) Make a list of the exception cases

Exception cases are important. Make a list of those, which must be accomodated and perhaps highlighted in the User Interface - due to business critical risk. For an extreme example, Meltdown of a nuclear reactor is not a normal process flow but it is a flow which must be highlighted early and extremely visibly in a User Interface. Another example might be the process flow in the event of a customer bankruptcy. The Accounts outstanding are not handled by the usual Accounts Clerks but by a Debt Recovery section. The User Interface must accomodate these important exceptions.

13. (c) Loops in Workflow tend to create Collections

A loop in a workflow will tend to create a collection of data or requests over time. Take another look at the Business Decisions from Strategy 9 and the collections over time from Strategy 7. Cross reference and compile a superset list. It is likely that the collection of Business Decision related workflow iterations, over time, was missed in the earlier analysis. This is simply because they are not immediately obvious whilst you are looking at a static view of the requirements.

Now examine the impact to our Analysis from Strategy 10. It appears that what we first considered was data relevant to the decision Cancel a Credit Limit, is actually required when we re-evaluate a Credit Limit Application. Without examining Workflow loops, we might have missed this and the result would have been rejection in User Acceptance Testing and a difficult requirement to find space for previously overlooked data.

We need to redo the table from Strategy 10.(a) to correct the earlier error