The Overlooked Craft of Flowcharting

While everyone knows what a flowchart is, I’ve sensed a lack of love. Flowcharts elegantly communicate processes, are a powerful design language, can be applied strategically to guide architecture and not least, should often be the first step before coding. Flowcharting is such a Zen exercise, why wouldn’t you? Product managers shouldn’t be without them either, for some ideas are best communicated as flow charts. Here are my lessons learned from years of connecting boxes with arrows. <ul> <li>Start with “Start”, end with “End”.</li> <li>Lines that cross are inelegant. They make me crazy.</li> <li>Branches should be binary, i.e., answerable by “yes” and “no” or other equally clear alternatives. They can also be tertiary.</li> <li>If people read from left to right in your culture, flowchart paths also should terminate on the right, except when it is impractical to do so.</li> <li>Try not to duplicate any artifacts, instead drawing arrows into a common one. This being said…</li> <li>Do duplicate an artifact like a data store when it’s more elegant to do so. For example, if you are interacting with the same data store at far ends of your flowchart, copy the data store icon so that you don’t have a mess of arrows going across the flowchart.</li> </ul> <a href="https://productcoalition.com/the-overlooked-craft-of-flowcharting-10a34c849930">Click Here</a>