Why use Flows?
There are number of surprisingly good reasons to model your application with flows.
- You are wired for it. Primary is all about communicating complex ideas. The first one is that the human brain is really good at understanding and remembering stories. Ancient cultures, without writing, used stories to contain knowledge. Flows are really just little stories and keeping this in mind will help you model better flows.
- You can see the missing pieces. Many modelling techniques are good at showing you the bits of the app that you have thought about, but they tend not to reveal, the parts that haven’t been considered. Flows reveal the missing parts. A collection of flows in a Group tells a complete story at a higher level than the individual flows. When an effectively named group of flows is reviewed, any omissions become immediately obvious.
Sizing Flows
A common stumbling block that new users encounter, is the question of flow size. Questions like ‘how do I know how much goes into one flow?’ and ‘how much detail do I need to put in?’ are typical. This basic issue causes a lot of angst for first-time modelers. The answer is simple, but hard to understand until you have spent some time actually creating a few flows. So, read this explanation of flow sizing, then go and try it. You will remain unconvinced and skeptical before you actually do the work.
Flows should achieve one useful goal for a user. A flow that only involves some interaction with no benefit to the user is almost certainly too small. A flow that achieves many goals will usually become too complex with too many alternate paths (we will deal with Alternate Flows below). When you become experienced you can play with this concept a bit more. Sometimes large multi-goal flows can be useful, you will know when the time is right to start breaking the rules.
Don’t expect your first one or two attempts to be optimal. Keep going and you will get over the ‘hump’ pretty quickly.
Name
The name of your flow is important. It is the starting point where you are building in comprehensibility to your flow. Your name should be short and concise. It should be ‘active’ and tell that your user is doing something, e.g. ‘Boil an egg’ is much better than ‘Prepare breakfast’ because ‘prepare’ could be all sorts of things, where as ‘boil’ is pretty self-explanatory. Likewise wishy washy verbs like ‘Manage’ and ‘Administer’ are to be avoided. Your name should create an expectation in the reader of what is about to happen.
Steps and Chronology
Each flow is created as a set of steps, and these steps describe the User’s action and the app’s response. Keep this in mind, your protagonist, the User, starts each step (and so starts the flow) and the app responds. The response is modeled in Primary as the use of one or more Elements, particularly an Interface, and a description if necessary (which is usually not necessary). Flows will normally start with the User navigating a browser to a certain URL, or opening the app, the stage is then set for you to define what they see, and what logic and data are involved in that experience (more of that later).
Happy path
Your flow documents the ‘Happy Path’. This is the path where it all goes according to plan. Clearly exceptions must be handled, we will talk about that next, but for the moment let’s stick to the main thread of the story. Keep your step descriptions as neutral as possible, with regard to the data or logic that is being used in the system response. Here are the two things to absolutely avoid:
- Never include conditions in step action descriptions. Statements like ‘The User does X unless Y is happening and then they will do Z.’ totally destroys the narrative arc. Suddenly your reader is dealing with two stories instead of one, and this really messes up comprehension. Of course flows have conditions, and these need to be dealt with, but in the right way (we will talk about that when we discuss Rules). What is important in drafting the text for the step, is that it remains agnostic about conditional logic. If that’s just not possible, then it’s likely we have two flows not one.
- Don’t put complex logic in step action descriptions. For much the same reason as the ban on conditions above, putting logic in the step description just messes up the story. There’s a good place for logic, and again, that is in Rules.
Alternate Flows
Where ‘things go wrong’ in a flow, we can deal with them in an Alternate Flow. Avoid the trap of making a flow with too many goals and creating multiple alternate flows. This is very tempting, but really, you just end up with modeling spaghetti. The result is hard to follow. It does not have the same sanity-check built-in that a Group of succinct, self-contained, single-goal Flows will have. We can’t stress this one too much. New users are attracted to complex flows with lots of Alternate Flows like moths to a light. We find that Flows with more than one Alternate Flow are very rare. Probably in the order of 5% of your flows will have more than one Alternate Flow.