Primary puts all the ‘detail’ that is attached to a step into an Element. As usual, there’s a few reasons for this.
- Keep the steps simple. By putting the detail into a separate Element, the step descriptions are kept very simple. The detail and its devils are still there, but their title becomes a placeholder for the nitty-gritty.
- Avoid duplication and conflict. By creating Elements once and re-using them you avoid creating conflicting versions of the same ‘thing’.
- Keep track of completeness. Viewing the Element lists will show you where elements have been created but are no longer used, and where Elements have been proposed but not defined.
Users
Users carry out the Flows. It is tempting to create a large number of fine-grained user types based on persona or intention. We recommend keeping your number of Users as low as possible. Users should represent different access right types, e.g. Public User, Member User and Administrator. It is fine to have additional user types to show intention or motivation, so long as you don’t end up with an unwieldy number of Users.
Use the ‘inherits’ property to show a User that has all the rights of another user, and some extra ones, for example the Member User may have all the rights of a Public User, and some additional rights as well.
Interfaces
Interfaces are the most obvious Element type. They are mostly what your user sees on their phone or computer screen. Interfaces are often the starting point for designers, particularly those coming from a graphics or interaction design background. We recommend starting at a very sketchy level, maybe even photographs of hand drawings. As your model develops, the Flows will reveal jobs that your Interfaces must do that you didn’t know about in the beginning. Leaving your beautiful pixel-perfect designs until later in the process will save many hours of re-work.
Rules
Rules are containers of logic. Wherever a Flow has to do calculations or present different information based on conditions, a Rule is the place to store that. A great technique for creating rules is to add them from the step where the Rule is applied, and give them a long descriptive name, e.g. “Calculation of reward points based on number of visits” or “Selection of membership verification method for account type”. This way you can keep going with the Flow modeling and return to add detail to the rule later on. It is not uncommon for Rules to change as the model progresses. Leaving the detail work until later on will avoid unnecessary rework.
Forms
Forms allow information to be provided by the User to the app. These might be presented as a traditional form with fields to fill out and check boxes to tick, or they may be some other kind of interaction. The main job of the Form element is to capture what is being input,and what the information is expected to be like. This will make the implementation team very happy later on. If you know your Account Code is 16 digits of 0-9, then define it during the design and avoid questions later.
Data
Data elements are maps of what we know about the ‘stuff’ and ‘things’ that the app deals with . They are not a database design. If your app is about ticketing, then we probably know a lot about what information is required to make a booking and to record on a ticket. Capturing that in a ‘Booking’ and ‘Ticket’ Data element will make life easier later on. Any Rules that refer to these properties, e.g. ‘Unconfirmed bookings last for 30 days.’ might talk about properties of a Booking. By defining these properties and giving them names, consistency can be maintained throughout the model.