|
Design Philosophy
Most companies take
what we consider to be a backwards approach to their design philosophy.
Due to lack of
vision and the inability to understand their clientele, they design
their products based on the industry standard. This standard assumes
that the personnel utilizing the product have fluent computer skills.
Little attention is paid to interface and design philosophy. When the
Client’s skills fall short of this standard, the common answer is “Train
them. Make them into Computer Experts.”
Unfortunately, this
approach attempts to turn Emergency Service Professionals into Computer
Technicians.
Simply put, it
doesn’t work.
Here at TBL, we
have a different philosophy. Design the product to fit the Client,
instead of forcing the Client to fit the product. This philosophy allows
us to create software which actually “makes sense” to the people who
utilize it.
We take a
“Forms-Based” approach which utilizes the Client’s own forms. This all
but eliminates the “fear factor” which is routinely encountered by
Emergency Services Personnel who are forced into an unfamiliar
“electronic environment”. We give our Client’s what they NEED, not what
we THINK they need.
Design Structure
In addition, we use
a “Bottom-To-Top” Design Structure Philosophy.
All too often,
Emergency Services Software Developers take their design cues from the
people who matter most to them. To be frank, this means the people who
sign the checks, the Senior Staff.
While we understand
the needs of Emergency Services Administrators, we also realize that
this design approach is inherently flawed.
The Foundation of a
Records-Information Software Package is the data which is placed into
it. Therefore, the design of such a package should focus on the people
who PUT THE DATA IN, not the people who need to get the data back out.
All too often, a
Software Developer will start at the top and develop their package based
on the needs of the Senior Staff. By the time the Developer reaches the
lowest level (i.e. the people who actually put the data in) the package
is pretty much set-in-stone.
The Developer then
attempts to force the package to fit the needs of the data-entry
personnel (pretty much trying to make a square peg fit in a round hole).
The outcome is inevitably a package which provides the functionality
required by the Senior Staff, but which makes little sense to, and which
actually DECREASES the productivity of the personnel tasked to utilize
it.
This can quickly
result in a chaotic environment for any Organization. Personnel required
to enter data are forced to utilize a package which was not designed to
meet their needs, and Senior Staff Members are left pondering the
complaints and decreased productivity of the personnel in their charge.
THERE IS A BETTER
WAY!
Instead of
designing from the Top-Down, we design from the Bottom-Up.
This design
philosophy allows for the development of a Software Package which is
tailored to meet the needs of the personnel who use it the most, and
which also provides the functionality which Senior Administrators
require (i.e. Statistical Analysis, Data-Reporting, Event Tracking,
Asset Management, etc.).
Let’s put it
another way. Which philosophy would you utilize if you were building a
house?
Here is our
Competitor’s preferred approach:
Call us crazy
but this philosophy doesn’t make much sense to us. We mean no disrespect
to all the Chiefs and Senior Staff out there, but if you want to develop
software for use by field personnel, it makes sense to go to them for
the answers on what it is they need and want.

Several things happen when you design the software around the
individuals who are going to use it.
-
If
you tailor it to the User’s needs, they will try it
-
If
you make it simple and fast, they will use it
-
If
you make it help instead of hinder, they will keep using it
-
If
you design it based on what is familiar to them, they wont fear using
it
-
If
it is going to be USED by street cops, then it should be MADE by
street cops!
-
Senior personnel will see higher productivity and efficiency
Because
we are Cops, we understand that there are other needs to be considered
in designing software. |