CPAP.com Introduction to Flowcharts and Process Design
1. Introduction to Flowcharts
and Process Design
How to describe doing stuff, the right way, with symbols, arrows, and paint
2. 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.
3. Origin of the Method
This 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)
4. 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
5. When to avoid
● The process is only a few steps
● The process has no decisions or branches
6. 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
7. 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
8. Lets make one
Lets 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 go
Each 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.
9. User Stories
Systems can be described by their interactions with users
These unique perspectives form user stories
(Stories of how a user interacts with your system)
User stories are extremely useful for design
This makes ensuring positive user experience easy
Real example at http://grab.by/oi24
This is a swim lane of the actions in Donuts
10. 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