Introduction to Flowcharts and Process Design

How to describe doing stuff, the right way, with symbols, arrows, and paint

What is a flowchart (according to wikipedia)

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. This diagrammatic representation illustrates a solution to a given problem.

Alternatively, a way to describe or document a process or structure with the minimum amount of complexity at any given time.

Origin of the MethodThis method is based loosely on UML. (Unified Modelling Language)

● Required in most computer science curriculums

● Helps to manage complexity

● We will be using a simplified version of UML because it takes a long time to properly learn UML and it can be overkill in many situations. (checkout the wiki article if you want to see how deep the rabbit hole really is)

When to use

● When the problem is too complex to envision completely● When you need to describe complex usage scenarios (such

as all the possible outcomes of a CSR call)● When trying to describe a new tool for a developer● When trying to track down edge cases

When to avoid● The process is only a few steps● The process has no decisions or branches

Benefits of Flow● Quickly understandable● Can "see" problems in process● Can accurately describe a process to another person● Can "walk" decision trees and quickly notice vague areas or problems that weren't considered● Orphan states● Will allow you to stop mentally "running in circles", get what you know onto paper, and allow you

to focus on what you don't● Easy to edit and collaborate with others

The Beef Components of a basic flowchart

● Symbols● Circle [or rounded square] (state)● Square (process)● Rhombus (data)● Diamond (decision)

● Connectors● Used to show direction

● Swimlanes● Used to relate processes in time

For example: A CSR placing an order for a phone customer Phone transaction versus a web server transaction.

A CSR could perform multiple call actions per action taken by the server.

The CSR is verifying identity, collecting payment info, confirming order contents. The web server just sees a single post request

Lets make oneLets flowchart a new user being created by IT

Quick tips for building a diagram:

Define your starting point, input and desired results (output)Start the process and move towards your result, drawing as you goEach time you reach a decision point, make branches all possible outcomes first, then follow one. This makes it more clear when outcomes still need to be mapped.At each endpoint, you should have transformed or consumed your inputs or have recognized a problem.

User StoriesSystems can be described by their interactions with usersThese unique perspectives form user stories(Stories of how a user interacts with your system)User stories are extremely useful for designThis makes ensuring positive user experience easyReal example at http://grab.by/oi24This is a swim lane of the actions in Donuts

Refining the Diagram● Its too big

● Move "up"● scope creep is a common problem experienced during flowcharting. When you start putting in

every detail, you end up with too many symbols. Pull back on the detail and abstract your processes. Do you need to describe the process for sending an email here or can you just say notify?

● Its too involved● Make another diagram

● Sometimes scope creep is unavoidable, a smaller part of your flowchart requires detail that makes the larger chart unwieldy. Break that smaller process into its own chart and link to it with a process symbol.

● http://www.lucidchart.com/invitations/accept/51dee260-224c-41ba-97e2-27c50a004235