Children were not grouped in any way, making it difficult to see who was at home vs. removed from home, and which children were placed together
  When a user created a court hearing with an outcome of "Reunification," the system automatically changed the location for the child to whom the hearing applied to "At home." Unfortunately, it did not actually close out the child's previous location, nor did it give the user any obvious indication that this step was required.     Furthermore, many children listed as "At home" did not actually have a household on record — or  had multiple households — meaning that by listing the children as "At home" the system was masking the fact that we did not actually know the child's correct location.
  Vague language, inconsistent hierarchy, and opaque error indicators made it unclear what was really happening — and what information was incorrect or missing — when children were in temporary locations such as a stay at the hospital or summer camp. 
  Combined access point to "Edit" and "Add" functionality virtually invited overwrites. Users were unclear about the difference between "Editing" and "Adding" and did not know which to choose when a child's location was changing.
  Many users completely missed the "Add New Location" button and therefore used the "Edit" button for existing locations — accidentally overwriting old data with new. There was also some confusion as to what constituted a "New Location." A number of users thought that the "Add New Location" action was only for use if the Foster Family Home to which they were sending the child had never been licensed before.
  Users also missed this call to action. As a result, they created invalid location data by attempting to "return a child home" by either end-dating or simply deleting the child's last placement. 
prev / next