U.S.A.

Contact T.B.L. Solutions: 1607-330-0881   

HOME | PRODUCTS | ABOUT US |  SUPPORT | TRAINING & INSTALLATION | CONTACT US | PRICING

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.


 


Coming Soon


Coming Soon


(RIS)


(CIC)


(LIS)

 

Copyright ©  2005 by Thin Blue Line Solutions  All Rights Reserved.

Home

| Products | About Us | Support | Training & Installation | Contact Us | Pricing