Suggested Order vs Obligatory Order

I was reviewing some old readings and came across an interesting concept.  In a report called "Application Design Showcase" by Nielsen Norman Group (citation listed below), an interesting concept was eluded to, but not really fleshed out (and it won't be fleshed out here either because I don't have the time!).  That concept is: 'suggested order' vs. 'obligatory order'.

The idea is that order is something that's often necessary.  Frequently when we are building, creating, editing, uploading, or adding something, we have to do sub-tasks in a certain order.  Cooking is often like this, where a specific recipe is a procedure that needs to be followed for the meal to come out correctly.

OBLIGATORY ORDER (think wizards...)

I want to describe 'obligatory order' first because I that the pattern is more well known.  When using an interface we sometimes come across a 'wizard', which is a pre-prescribed order of screens (usually in a modal dialog) where you have to go in that order to complete the task.  This is good for situations where each step is likely to end with a conclusive decision about what ought to happen on that step (and the need to go backward is less common).  In other words, the user is unlikely to be iterative or uncertain about each step in the process.

SUGGESTED ORDER (think, a UI with a multi-page flow, where it's easy to go back...)

The 'suggested order' construct isn't talked about as often as wizards, yet it certainly exists.  This is when an interface structurally supports that a certain order of operations makes sense, without enforcing that order.  The user is free to flow back and forth.  To the user, the flow is implied but not necessary.  Although there is a suggested direction, traveling to and from previous steps is made to be easy.  This is good for tasks that are creative in nature and don't have bad consequences for not following a pre-prescribed sequence.

Nielsen, J., Nodder, C., & Berger, J. M. (2008.). Application Design Showcase: 10 Best Application UIs (1st ed.). Fremont, CA: Nielsen Norman Group. (p.97)