There is a sense of ownership and accountability to things that we deliver to others, especially in a professional setting. Maybe it’s a report to your boss, a draft to your cross-functional counterpart, or even something as a simple status update to your peer. When there is a name and intention attached to its existence, we all feel connected and responsible for the quality of the product. We want it to match the expectations of the person receiving it, while cutting down any additional time we spend on that specific item.
To date, bug reporting has been an area where only a particular subset of an organization is confident in the asset they deliver. Most members of an organization (if they are not trained or actually the ones fluent in technology) deliver reports that lack the context necessary to actually be helpful on the first attempt. This results in a back and forth that we like to call the “game of telephone”.
PlayerZero built session reports to address this specific communication issue. We gather all of the context a developer will need to actually solve the issue: steps to reproduce, screenshots/DOM snapshots, DevTools, and other metadata. It’s a big win for everyone! But we also realized that data is most helpful when it’s told with a story: “What was I trying to do when the issue happened? What was I expecting to happen?” When you deliver something to someone else, you expect it to represent you well, and, in some cases, you want an opportunity to tell a story to help provide clarity.
Ownership over a submitted issue
PlayerZero is giving the user the ability to tie their voice to an issue. What went wrong? What were they trying to achieve? Did they notice anything else fishy? etc, etc. By doing this, we believe bug reporters will deliver issues more confidently, and bug receivers will have everything they need – ranging from the human story, to the technical details to solve the problem and keep moving forward.
It all starts with that first moment of discovery. A page didn’t load, the data isn’t correct.. Something is broken. Now I need to tell someone.
We see the communication of this issue happening in four chunks:
- Initiating a issue report
- Providing a high-level written description of the problem
- (Optional) Including a video descriptor
- Passing all helpful information to PlayerZero
Initiating an issue report
Depending on who you are (a team member or a production level user), the form you use to deliver issues can be unique. We’ve built a variety of ways to bridge the gap between the person who feels the problem to the person that can fix the issue:
- “Upload Session” Widget: This widget lives at the bottom of the browser and mimics buttons that users are used to seeing with chat or issue reporting tools. This is a popular tool for internal use cases.
- Key command shortcut: If you do not want any distractions or buttons clogging up your UI, we totally get it! This is why we built out a quick command to kick-off the upload process. Internally, this can be used by anyone. For production, this is a great tool for account managers or customer success folk that work closely with users; the simple instruction would be “hey, hit command-k (or cntrl-k fpr PC users) and send that issue to our tech team”.
- Integrations: Ah yes, integrations. We’re constantly finding better ways to fit into how others set up user workflows in their application. Checkout our intercom integration already being used to connect our users to their users!
Providing a high-level written description of the problem
Once they’ve decided to report an issue, the first thing that users tend to want to do is provide a quick subject line, or short written description of the issue. This is how we are all conditioned to participate in the quality initiative, whether it’s through Jira tickets internally, or user support tickets in production. For this we build a simple description submission box.
Including a video descriptor
Some of the best bug reports developers receive include a video; depending on the person on the delivering end, a video can shed a ton of light on the issue at hand. Unfortunately, standalone videos often fall short when they are used to try and explain and show every aspect of the issue. That’s where the PlayerZero application makes perfect sense; add a video as an a la carte add-on to other, useful information.
Passing permission to your session information to PlayerZero
Now that we’ve added some “human” context, it’s time to dive into passing over the technical details. One of the core, differentiating features of PlayerZero is that all user data is private by default and is uploaded to our servers by user pass-off. This means that even though PlayerZero is always capturing information about every piece of context that could be useful, that data doesn’t leave the safety of the user’s local machine until they give the say so. On upload, all locally bundled information goes up to the PlayerZero servers, otherwise, the data naturally gets deleted, never leaving your computer.
Each of these additive submission experiences are streamlined to drop the context directly in the PlayerZero report without any extra work from the user. You can read more about how we’ve tactfully integrated them into the digestion experience here.
Our goal here at PlayerZero is to allow anyone to participate in quality initiatives to the best of their ability. We’ve automated almost every aspect of the bug report creation process in a way that elevates and levels the playing field; anyone can produce something great, regardless of their distance from the product. But there will always be a human element to this experience, and we have built a process that we believe gives users a voice where it is needed most, when the issue is most painful.
Try out this experience by downloading our chrome extension and signing up if you haven’t already!