UPN Standard and Practice

UPN Standard and Practice

 

Universal Process Notation (UPN) is the best way to engineer manual business processes, and has been so for more than twenty years. This guide is my take on the UPN standard, based on using it since 2002 as a direct customer and as consultant, with dozens of clients.  Exploiting that practical experience I have:

  1. Provided a definition of each element of the standard
  2. Indicated whether each element is a Must Use   or Should Use
  3. Provided good practice tips
  4. Described practices to avoid

 

UPN Audience

UPN is a notation for business people that complements BPMNBPMN is a rich notation designed for technicians that claims to be accessible by business people. Unlike BPMN, UPN actually is accessible to business people.

If you want to know more about how UPN and BPMN relate to each other read my articles:

 

UPN Skills – Easy to learn, easy to retain

The simple notation makes creating UPN content easy.  Creating high quality UPN content is easy too.  This guide describes how to do that by applying some simple design practices.  These good habits are easy to learn and, because they are not complex, are easy to retain.

 

UPN Certification

There’s no need. Are you certified to use Word, Excel or PowerPoint?  Of course not.  UPN is as easy to use as any desktop app, and a darn sight easier than Visio.  Follow the practices in this guide and you’ll produce great UPN content.

The UPN apps have some stylistic differences. This guide uses illustrations from Elements.cloud

The 6-8 Rule

6-8: the maximum number of words to use on an activity or flow line. If there are more, review the text.  It’s too wordy or it’s trying to do more than is appropriate on one item. 

Be concise but precise.  Too few words can cause ambiguity.  e.g. Does order mean sales order, purchase order or customer order?

6-8: the maximum number of activities on a single diagram. Use more and you reduce the ability of the user to absorb the diagram at a glance.

The activity box describes the action that’s triggered by the input(s).  An activity transforms the inputs and adds value.

Some process methodologies make a distinction between activities and tasks.  UPN uses plain English in which activity and task have the same meaning.  Therefore we treat them as one.

Must Use: This feature is mandatory.

Activity text must use a present-tense verb followed by a noun. e.g. Process sales order

Good Practices:
  • Remember the 6-8 rule (see above)
  • Use sentence case

Practices to avoid:
  • The words and / or in an activity text warn us that there may be more than one action.  Unless the and / or is part of a completely seamless action, the separate actions should be placed in separate activities.

A flowline coming into an activity shows the trigger(s) for that activity.
  • There must be a minimum of one input or the activity will never be triggered.1
  • There can be multiple inputs.  UPN does not qualify them with AND / OR symbols.  People are able to resolve AND / OR conditions without explicit labels or symbols.
  • The line must be labelled so we know what the input is.

1Exception:  Support processes that are not directly involved in generating revenue are often represented on a high level diagram as a series of standalone activity boxes with no inputs and outputs.  These are added at the next level down. 

Must Use: This feature is mandatory.

Good Practices:
  • Label lines concisely.
  • Use Sentence case.
  • Make sure it’s clear which line the text applies to, by placing it appropriately on the canvas.

Practices to avoid:
  • Don’t let line text overlap the line.  This reduces readability.

A flowline going out of an activity shows a result for that activity.
  • The purpose of an activity is to transform an input.  Therefore there must be a minimum of one output or the activity adds no value1
  • There can be multiple output lines. 
  • The line must be labelled so we know what the output is.

1Exception: Support processes that are not directly involved in generating revenue are often represented on a high level diagram as a series of standalone activity boxes with no inputs and outputs. These are added at the next level down.

Must Use: This feature is mandatory.

Good Practices:
  • Label all lines concisely.
  • Use Sentence case
  • Make sure it’s clear which line the text applies to, by placing it appropriately on the canvas.

Practices to avoid:
  • Don’t place text over the line.  This reduces readability.
  • Don’t record the output as the past tense of the activity, because that is stating the obvious.  e.g. if the activity is “Get customer to sign contract,” then “Signed Contract” is not the best output text.  How about, “Ready to proceed with build?”  This tells us far more about the value that has been added.  Looking at the needs of the next activity is a good way to go.

A flowline between two activities combines the requirements of an input and an output.

Must Use: This feature is mandatory where one activity follows another.

Attachments enrich the process description.  The universal attachment icon – the paper clip – is used.  The range of attachments varies by UPN application but typically includes text notes, images and URL Links as a minimum.

Should Use: This feature is optional but any process map that does not have attachments at the appropriate points is a poor user experience that will not help with adoption of the process.

Practices to avoid:

“Note” attachments are a great way of adding further explanation about an activity but should not be used as a substitute for a drilldown

The resource tells us who is responsible for performing the activity.  At higher levels in a map the resource will be the person who is accountable for the process. 

Must Use: This feature is mandatory.

Every activity must have a one human resource.

Good Practices:
  1. An activity should have a maximum of one human resource.  Multiple human resources indicate a blurring of responsibility and accountability.
  2. Where an activity can be carried out by people with different job titles, then a generic resource (role) should be used. e.g. every employee has to submit their holiday requests in the same way but we can’t list every job title in the company.  To solve this we use a resource called Employee.  Another example is when a role is called by slightly different names in different countries or business units.  Agree a common name and use that as the resource.
  3. Optionally you can add resources to show WHAT system and / or facility is needed to perform a task.

Practices to avoid:
  • Never refer to a department.  We need to know specifically which role is responsible / accountable, otherwise there is no responsibility / accountability.  VP Marketing is acceptable, Marketing is not

In Elements the corner tab tells us there is a drill down that contains more information on how the activity is performed.  Other UPN apps use different symbols, such as and

 

Must Use: This feature is mandatory. 

You cannot describe a process properly without using drilldowns.  Drilldowns allow you to create additional levels of process explosion (decomposition).  Without drill downs diagrams would become large and difficult to absorb.  See 6-8 rule above.

Good Practices:

Complete and validate the current level before you create drilldowns. 

  • This ensures you will have the correct inputs and outputs on all the child diagrams, and the subsequent designs will be correct.

Practices to avoid:
  • The 6-8 rule sets the maximum number of activities on a diagram. 
  • But you must also avoid having too few activities.  A drill down that has only two or three activities creates additional user navigation, between levels. If possible, try to accommodate the child activities on the parent
    • If that makes it difficult to follow the 6-8 rule on the parent, you need to examine the distribution of the parental activities to see if different groupings suggest themselves.  It’s also possible that problem is caused by the grandparent diagram activity being too broad in scope.  e.g. Does that grandparent activity contain an and or an or?

A Connector provides an off-page link to where we came from.  This could be a peer diagram or anywhere in the process.  A connector at the arrow end of a flow line tells us where we are going to.   Connectors are useful navigation aids because they allow us to do a one-click “previous / next diagram” action.  They remove the need to go back up to the parent, across and down – the green compared to the red route in the diagram below:
Should Use: This feature is recommended but is not mandatory.

Good Practices:
  • Use this  capability to link peer diagrams, so that a user can easily move between adjacent diagrams of the same level.
  • Avoid multiple destinations on a single connector as this can cause user confusion.

Practices to avoid:
  • Don’t create connector points until you are able to make the connections, because it’s easy to forget to return to make them.  A dead connection is a poor user experience.

A terminator tells us that the process finishes at this point. Placing a terminator at the non-arrow end of a flow line indicates the start point.  

Must Use: This feature is mandatory.

Good Practices:
  • Make sure you terminate every floating line that has no  preceding or succeeding activities on another diagram. This makes it easy for process designers to see which floating lines need to have connectors attached to them.
  • It is also a good visual prompt for end users that there may be a preceding or succeeding process that the designer has not yet connected

Following the notation standards and practices above will result in good diagrams.  This section includes other good practices.

When you document process you need three critical components before you can start:
  1. Subject (Diagram Title)
  2. Start point(s) (Inputs)
  3. End point(s) (Outputs)

I call this the Process Triangle.

This happens when:
  1. A high level process has been  developed vertically down through one or two activities but many of its peers remain undeveloped.

  2. Activities on the same diagram lack parity.  e.g box one says “Apply project code” and box two  says “Design, develop and deliver a nuclear power station.”  The first takes a clerk five minutes and costs a few dollars; the second takes thousands of people years, and costs billions.

These are usually easy to distinguish from each other.  Case 2 is easy to fix by absorbing the minor activities into the major.

Case 1 is more problematic.  The danger of deep diving on isolated activities is that they become process islands that don’t take proper account of what is happening up- and down-stream.  When the rest of the processes are eventually developed these process islands don’t hand off correctly, because the inputs and outputs are incompatible.  The result is a process that does not work, and has to be redesigned. 

Good Practices:
  • Develop activities at one level
  • Then develop every diagram across the next level.
  • Once you have got several higher levels nailed it is then normally safe to drill vertically, because sufficient context has been set to guide us safely through the lower levels.
  • But you must be continually aware of the potential for disconnect with peer processes.

Good Practice:

More inputs on drilldown than on parent activity

As drilldowns are added, finer levels of detail emerge that make it necessary to add new inputs and outputs. They are not sufficiently important to appear on the parent activity. Omitting them from the parent is standard practice. If we were to roll-up every input and output from the lower levels, the parent diagrams would be an increasingly complicated spaghetti of connections. They would be factually correct but incomprehensible.

Fewer inputs on drilldown than on parent activity

The reverse of the previous paragraph is not true. An input or output on the parent activity must appear on the child, or the child diagram will not meet the needs of its parent’s up- and down-stream activities.

Mapping the drilldown reveals an input/output that should be on the parent

When creating a child process it sometimes happens that a missing input or output is discovered – one that should have been on the parent. If that is the case, do not ignore it.

  • Stop all development of the child
  • Go back up to the parent
  • Fix the issue at source, because it probably has affected:
    • the overall design of the parent diagram
    • other drilldowns that have already been mapped.

All boxes on one diagram should be the same size – matching the one with the longest text. Truncated text should never be permitted:

If this means that many of the boxes are much too big for their content, or the diagram layout is severely impacted, then the activity with the long text needs to be edited.

aka “Happy Path” or “Sunny Day Scenario.”

Avoid getting bogged down in exceptions before you have completed the “If It Works” path.  Understanding “If It Works” properly will let you see the exceptions in a new light. Often, exceptions can be avoided simply by better IIW design, so why waste time documenting them?

A diagram is more appealing to users when the activities are laid out on a grid (as far as possible) with the boxes aligned in rows and columns As a starting point, using the 6-8 rule, you should consider 2 rows of 4 activities.
 This works well because it uses a concept from photography – the Rule of Thirds – which says that an image has more impact when the subjects are placed on or near the lines formed when the image is divided into thirds, vertically and horizontally, as seen here:

Normal Flowline Direction

Mandatory: All languages have a direction in which people are accustomed to read. Your process flow must follow that norm.

Most European originating languages use LTRTTB (left to right, top to bottom).  Therefore the if-it-works scenario should always follow a horizontal row, wrapping to a further row if needed.

Don’t forget the 6-8 rule

Flow lines should adhere to the same principle.  Do not construct diagrams where the first row is LTR and the second is RTL.

Exception Flowline Direction

Wherever possible, exceptions should be routed out of the main flow in a vertical direction, up or down. Users will then intuitively learn that horizontal is the normal path and vertical means an exceptional event has occurred. Therefore, where possible, avoid using vertical flow lines for if-it-works flows.

Floating flow lines alignment

Try to align flow line ends across the page so that all those on left and right hand margins terminate on the same vertical axes, and those at the top and bottom on the same horizontal axes.  But do not apply this rule rigidly if the result is very long flow lines that look wrong.  Do what looks best.

Flow line text

Text on vertical flow lines is best presented with tight text wrapping (although you have to do it manually because flow text doesn’t auto-wrap.

Merging Multiple Flow Lines

There are two cases where you need to think about whether to merge flow line ends:

  1. When an activity has multiple outputs that branch into different activities.
  2. When multiple activities converge onto a single activity.

If the flowline text is the same on all lines, merge the end points; if it is different, do not.

Don’t attempt to use merging / non merging end points to depict AND / OR gateways. 
  • You won’t be able to construct a meaningful metaphor for users
  • They don’t need it because they will easily deduce the dependencies from the line text.

Crossing Flow Lines

Flow lines must not cross, because that creates confusing navigation for the end user.

In the vast majority of cases. crossing lines can be eliminated by changing the diagram layout. Lines should only cross when there is absolutely no other choice.

There’s a whole science and a fair bit of legislation on this topic. But for starters:

Readability

Mandatory: There must be sufficient contrast between text and backgrounds colours,

Font Style

Use sans-serif fonts.
  • They are better for screen-based reading.
  • Use a minimum 12 px font size as standard. 
    • 10 px is OK in limited use.
    • 9 px or less should be avoided.

Colour Blindness

Mandatory: Approx 5% of the population has some form of colour blindness and red/green is the most common type.  If the Readability guidelines above are followed there will not be an issue but be aware that colour schemes that have any red or green components may cause problems.

You can find a more information on this topic in the article Colour in Process Diagrams

There are several on-line services where you can submit samples for compliance checking.  A search for colour blindness simulator gives sites where you can upload a sample image and view it through filters for different colour blindness, while accessibility colour checker gives sites where you can check your intended colour combinations meet the Web Content Accessibility Guidelines

UPN is jargon free and the terminology uses plain English.  Definitions of these terms are located in the BPM Dictionary

The principles behind UPN were first published back in 2004 in a book called Common Approach UnCommon Results by Ian Gotts  ISBN 0-9548309-0-3.  Nimbus released this as an open standard in 2008 which is when it was given the name UPN (Universal Process Notation).

Other sources include:

Universal Process Notation: A simple solution for complex process diagrams

Open all sections