Bug Reporter Tool

Team 69 Project Writeup

Initial problem statement

We have an existing web widget called Bug Reporter Tool (BRT), that can be easily embedded onto government sites, and is currently being trialed on a small scale in HDB. The initial problem statement had been crafted when we conceptualised BRT.

Initial Problem Statement: How might we provide a fast and painless way for members of the public to report bugs on government websites, while also increasing the efficiency and effectiveness of bug fixers?

Refining the Problem Statement

We theorised that a lack of bug reporting / bug reports submitted with insufficient info was primarily due to limitations in the submission processes, e.g. a lack of screenshot functionality leading to users not being able to adequately describe the bug.

We thus designed BRT with the following functionalities:

1. File a report without leaving the page they encounter a bug on2. Allow user to input various details (e.g. name, contact info) and describe the issue they face3. Allow user to capture a screenshot of the page they encountered the bug on (desktop) / upload a screenshot of the bug (mobile)4. Auto-capture background information such as OS, browser version, etc useful for troubleshooting5. Send this the report alongside the screenshot and background information to bug fixers as an email

BRT produced good results in the trials, with bug fixers touting the more complete information and savings on time spent locating the correct audit logs for their users. Nonetheless, we wanted to enhance BRT to produce even higher quality bug reports / have a better bug reporting rate.

Instead of looking at how to enhance the functionalities for the bug fixers to better understand sub-standard bug reports, our team decided to further examine the source of lower quality reports instead - the website users.

We hypothesized various sources of friction for MOPs reporting bugs, and surveyed our peers and colleagues to test our hypothesis.

Determining the root causes

Our results were roughly in line with our expectations. For the 58% of respondents who were not willing to report bugs, ease of bug reporting emerged as the top 3 factors:

• Respondees were allowed to choose more than 1 option.

In line with the above, these respondents indicated the following measures would encourage them to report bugs:

• Respondees were allowed to choose more than 1 option.

From the above, s/n 2 was already addressed by BRT’s ability to be filed without leaving the existing page. Thus we decided to look into addressing the other factors.

Another question asked all the respondents regarding their concerns when reporting bugs, as we wanted to see the concerns of users regardless of whether they reported bugs or not.

• Respondees were allowed to choose more than 1 option.

Obviously, the same few culprits emerged - ease of describing the bug and reporting the bug. Another item struck our interest - many users were concerned that customer service did not understand what the bug was about.

We theorized that this was aligned with their earlier response in Qn 6 desiring minimal customer interaction, in that they did not want to deal with the back and forth with customer service to help them understand the issue.

We also noted another issue - 25% of respondents were concerned with their personal information being disclosed, something we thought would be a non-issue.

Addressing the root causes

BRT’s screenshotting function was designed to improve the ease of describing bugs. However, this also came with limitations - users could not screenshot more than once / upload more than one screenshot.

This meant that sometimes, users might not be able to adequately describe the bug they faced (e.g. via before and after comparisons). Being able to better describe the issue they faced would also help reduce back-and-forth with customer service / bug fixers.

Additionally, there was no functionality for users to edit screenshots to mask sensitive information. This would add to user apprehension as seen in the results, lowering report submission rates.

This lead us to the following 2 new hypotheses:

1. If users can upload multiple screenshots, developers will receive more complete information upfront, reducing follow-ups and time spent on clarifications.2. If users can edit/mask sensitive information on screenshots before submission, they will feel more comfortable reporting bugs, leading to higher report submission rates.

Refined Problem Statement

Consequently, our 2 hypotheses lead us to refine our problem statement such:

How might we enable members of the public to report website bugs while ensuring they can protect their sensitive information and provide complete visual context for developers, thereby reducing friction in the bug-fixing process?

Our solution

Our solution to address our refined problem statement would involve 4 enhancements:

1. Enable users to edit screenshots, including blurring / masking sensitive data.2. Enable multi-screenshot support for better bug context.3. Enable mobile screenshot capture, instead of current screenshot upload function4. Provide hover-based tooltips to reduce confusion and errors.

These enhancements would ultimately help developers receive more complete information upfront, and help improve submission rates.

Impact and outcomes analysis of our solution

Unfortunately, time demands on our main projects meant that we no longer had the time to develop the enhancements we had planned. As such, we can only estimate their potential impact:

1. 30-40% improvement in bug report completeness due to improved screenshot and form functionality.2. Enhanced privacy & trust for users, reducing hesitancy in bug reporting.3. Reduction in developer time spent on follow-ups for incomplete reports.

Future steps for your project

As mentioned above, we no longer have the time to develop our formulated enhancements due to the demands of our main project.

As such, we will be parking these enhancements in the parking lot until we have more time to continue development. In the meanwhile, we will continue gathering feedback and usage data from the existing trials with HDB, to see what other new functionalities might be needed. *