Bug Reporting Flow
(the end result)
The problem: I am in a scenario where the EHAS / Everyone Has A Story storytelling and networking platform has a responsive website, however, there are glitches with the website and app. I need to create intuitive, accessible and simple features and methods people can use to report bugs while being cognizant of the fact that most people don't report bugs when they encounter them on a variety of different apps and websites. If I don't include a way to report problems, I will be less informed as to why I am losing users.
The solution: People have different preferences on how to report bugs. Some like to send direct messages to the company. Others want to see if there is a comment section. And others want to communicate with a company employee in a chat. Despite the different preferences, one feature tended to be the most requested by users during discovery research: a feature that would allow users to send images. I decided to include each of these methods as a way to report bugs.
My role: Lead UX researcher and designer
Interface ideation, sketches and wireframes: Here's how I put my users' needs first. The process begins with my initial ideas and wireframes, then moves to a low-fidelity prototype, after which, I design mockups, eventually adding interactions with mockups to create a high-fidelity prototype.
1
In these simple wireframes, you can see how I approach the solutions to the problem. There is a hamburger icon that reveals navigation options. If the user wants to report a bug, they would have to select the option that allows them to report a problem. By doing so, they will come across a bug reporting tool that would allow them to send a message and a photo. In addition, this tool also contains a link that allows users to visit a help center, where they can search for information to see if they can solve their issue without reporting a problem. The help center also contains two other ways users can report a bug: either by putting a message in a comment section or by using a chat to communicate with a company representative.
2
Revisions: I created a low-fidelity prototype and conducted usability tests which revealed that users were having a challenging time trying to find the Visit Bug Help Center link. In order to make the text more visible, I revised the design by shifting the content in the box upward, increasing the text size for the Visit Bug Help Center link, changing its text to blue, and shifting the link slightly upward and to the left so that it would be closer to the very visible send button. I also added another wireframe during the second round to show what the page would look like if users were to write a message during the bug reporting process.
Refining the solution: Now the design really begins to take shape: more text is used, colors are applied and images are added. These mockups show visuals that give a better idea of the final design.
3
The final design: I added interactions between frames to create the high-fidelity prototype, which gives a full picture of the complete design. It addresses the user’s needs for a simple, yet engaging and uncluttered design that would allow them to report bugs easily and quickly. The wording “How can we make EHAS better?” let's the user know that if something is wrong, it's a problem on our end, not their end, which helps relieve any tension the user is experiencing.
The outcome: A functional design for a bug reporting flow.
What I learned: During the design process, I decided to include blue text for the Visit Bug Help Center link, however, the pop-up box on the desktop site had a previously darker brand shade of blue that did not provide enough contrast with the link. This hindered visibility and accessibility. To fix this problem, I changed the fill of the pop-up box to a lighter shade of blue. I think it would also worth checking to see if there would be a better design for the navigation of the website.