Making it Happen- from Idea to Implementation and Beyond
Our need-based approach lets the functional requirements of the users guide the design at all
stages, by focusing on processes: how are the data gathered, input, stored, retrieved,
manipulated, and output to meet the needs of the users? If the relationships among these
processes are clearly understood by the development team, the resulting application will seem
organic to existing workflows. This approach works extremely well for specific solutions, but
several challenges are faced when applying this method to the development of a product that will
appeal to a wide audience. Not all users will have the same functional needs; the processes that
evolve to meet those needs may differ; and the results desired from those processes will vary.
Given these differences, our design team had to pay careful attention to needs that could be
identified as common to the majority of prospective users. Once again, having an experienced
highway supervisor on our team proved to be an invaluable asset as we strove to identify these
essential elements.
Client-Specific Biases
Because our design methodology shifted in mid-project, we had to deal with the legacy of our
early deductive approach throughout the rest of the development process. This challenge gave us
an opportunity to evaluate how our early assumptions affected later stages of the process. We
found that most of the problems we encountered as we tried to generalize eroads for wider
distribution could be traced to a circumstance specific to White County. These client-specific
biases influenced early design choices that became inappropriate when our project focus shifted
to a wider audience. An example will illustrate the peril of letting client-specific biases persist
through the development process.
In our prototype application, we defined two related tables to contain employee data. The first
table contained the employee’s ID number, name, hire date, sick time balance, and vacation time
balance. The second table contained each employee’s regular and overtime pay rates. The
records in the second table were related to the first table using the employee’s ID number. The
tables were initially structured this way so that during data entry, our client could select the
appropriate pay rate from a drop-down list on the user interface.
When our development focus shifted to a wider audience, we decided that eroads should
calculate the appropriate pay rate for each activity based on the type of work being performed,
the employee’s length of employment (longevity), and the total hours worked by an employee in
each week. In most highway departments, each work category is assigned a corresponding base
pay rate. For example, a truck driver’s base pay might be $12 per hour, while an equipment
operator’s base rate may be $17, and a laborer’s base rate may only be $10. Employees tend to
perform one type of work most of the time, so each is assigned a default work category. If an
employee works more than half a day in a category with a higher base rate, the employee is
customarily paid the higher rate for the entire day. Hourly longevity rates are commonly added
to these base rates as well. The employee’s regular pay rate is determined by adding the base
rate for their work category to their longevity rate. The employee’s overtime rate is 1.5 times
their regular pay rate. We decided that eroads should calculate these rates “on the fly” and apply
the overtime rate to any hours worked in excess of 40 per week. In complying with this decision,
our programmer had to restructure several of our data tables, re-code how pay rates are assigned,
and modify the form that allows users to enter and edit employee information.
