The Intended end users of our products are the staff at the CRD, particularly the Watershed Protection Division. Within the described end users, there are two main user categories we are focusing on, “Staff” and “Admin”. Most Watershed Protection Division staff, like patrollers and gatekeepers, will fall into the “Staff” group, while managers and authorized individuals would be considered “Admin”. These categories ensure we have the opportunity to implement a variety of role-dependent features in our solution to meet the diverse needs of each user category. The biggest difference between the two user groups is that “Admin”, in addition to all “Staff” privileges, has user management-based privileges like adding, deleting, or updating staff access and general information. This ensures the privacy and security of our solution as those administrative tasks can only be done by certain people and are therefore more “traceable” for the company as well.
Using design thinking steps, we have been able to adjust our project based on feedback from our community partner. We have had to go back to brainstorming sessions after some meetings with our community partner, taking notes of their feedback and making the necessary adjustments. Our process was never linear, but we learned throughout the process. It was important that we understood each other’s strengths and delegated tasks based on that. We also made sure that communication was done properly where everyone’s opinion was voiced, and we understood each other.
An additional feature that could be added to our application would be a “Generate Report” functionality. This would provide the staff with an exported version of the information displayed on the Alert and Event History pages. Our community partners have voiced their interest in this functionality, as they would like to have a permanent record of certain activities in locations of interest for their future reference. While we are putting more resources into finishing other aspects of our application, because of how interested our Community Partners are we are doing our best to ensure it is completed as well.
After showing an earlier version of our lo-fi prototype to our community partners, they provided us with valuable feedback on our idea. A large problem the Capital Regional District currently has is too many notifications of alerts being delivered to them, which they felt wouldn’t be solved with our current solution. With a clear goal in mind, minimizing the number of alerts received, we were able to brainstorm with them some options and settled on an idea. We designed two separate tables in our database: alerts and events. If an object other than fire such as people, animals, or trucks is detected during work hours, it will be written into the event data table and no alarm/notification will be triggered. This provides the CRD with a history of detections for their backlog purposes if needed. However, if a fire has been detected or any activity during off-hours, it will be written into the alert database, trigger an email notification, and update our current alert page of the website.