But it Works on my Computer

May 4, 2022

A bug report problem

Imagine you’re an eCommerce shoe company, and a user runs into a problem on your application while trying to order a pair of Purple Nikes. After floundering about in confusion, they realize they can’t solve this on their own. They contact support, who is trained to help users but not to solve problems in the software. So they have to move the problem down the chain; they try their best to translate what happened, cross their fingers and hope that they did enough to help engineering fix the issue.

When asked what went wrong, the user might have said something like:

“At 4:27pm on Tuesday, I tried to check out with a pair of purple size 10.5 running shoes, but when I clicked the Checkout button, it didn’t work. And then when I went to check out again, the shoes were gone!” 

This description does not lack detail, but unfortunately it’s the wrong type of detail. Whether the shoes were blue or size 11 or whether they were checking out at 5:50am on Saturday is quite unlikely to be responsible for the bug – but how is a user without a background in software development supposed to know what information is valuable? 

Once the issue hits the developer's desk, they try to replicate the user’s problem, attempting several different routes through the checkout to see if any of them would reproduce the issue. But everything works fine... They report back:

“Well, it works on my computer.”

Now everyone is exasperated. The dev feels like their time is being wasted hunting for bugs that seemingly don’t exist. Support is stuck between frustrated customers they can’t help and annoyed devs who aren’t able to solve the problem with the information they have. Users feel like no one is really trying to solve their problem.

Developers shouldn’t have to waste their time trying to reproduce bugs while relying on incomplete and inaccurate information about what caused the bugs. Debugging as it is currently done puts developers in the impossible situation where they have to fix problems without knowing what the problems are. 

PlayerZero’s solution: automate the bug reporting process

PlayerZero lets you avoid collection and curation frustrations by ensuring that developers get to see exactly what users did before encountering a problem. When a user reports a bug, developers can jump right into the specific PlayerZero user session – filled to the brim with metadata, cursor movements, committed actions, frustration signals, API calls and everything in-between. 

With PlayerZero, the details that the user provided is much more valuable; the fact that the user’s problem occurred at 4:27 on Tuesday while the user was looking for Purple running shoes helps the developer search (within PlayerZero) for the exact user session where the problem occurred. PlayerZero lets you use whatever your user tells you to help you debug, even if the information they give you isn’t remotely relevant to what might actually be causing the problem.

If something doesn’t work on the user’s computer, the dev can see exactly what happened by simulating that user journey in any environment. Imagine being able to deploy a robot clone of your user wherever and whenever you want. That’s PlayerZero.

The dev can see if the customer trying to order shoes had tried to pay with Paypal or had entered in a coupon before logging in, small details that a user could forget to mention but might be crucial for causing a bug. To see PlayerZero deploy your users, check it out here.

Conclusion 

With PlayerZero, developers don’t have to guess what happened and waste time fishing for a bug that, as far as they know, might not actually exist. Everyone saves the time normally spent going back and forth communicating and developers fix bugs quicker since they can see exactly what users do to cause them. Debugging becomes as easy as it should be.

Say goodbye to exasperation and disappointment. Devs can spend less time and energy putting out fires and more time building new things. Users can get a clean response experience that doesn't require multiple zoom meetings, loom videos or response emails. Support can deliver users and developers good news more often. 

If your product doesn’t work on someone’s computer, you can be confident that you can track down why. To try it out yourself, sign up and join our Beta

Written by:
Tim Schmitz
Additional Articles

But it Works on my Computer

May 4, 2022

A bug report problem

Imagine you’re an eCommerce shoe company, and a user runs into a problem on your application while trying to order a pair of Purple Nikes. After floundering about in confusion, they realize they can’t solve this on their own. They contact support, who is trained to help users but not to solve problems in the software. So they have to move the problem down the chain; they try their best to translate what happened, cross their fingers and hope that they did enough to help engineering fix the issue.

When asked what went wrong, the user might have said something like:

“At 4:27pm on Tuesday, I tried to check out with a pair of purple size 10.5 running shoes, but when I clicked the Checkout button, it didn’t work. And then when I went to check out again, the shoes were gone!” 

This description does not lack detail, but unfortunately it’s the wrong type of detail. Whether the shoes were blue or size 11 or whether they were checking out at 5:50am on Saturday is quite unlikely to be responsible for the bug – but how is a user without a background in software development supposed to know what information is valuable? 

Once the issue hits the developer's desk, they try to replicate the user’s problem, attempting several different routes through the checkout to see if any of them would reproduce the issue. But everything works fine... They report back:

“Well, it works on my computer.”

Now everyone is exasperated. The dev feels like their time is being wasted hunting for bugs that seemingly don’t exist. Support is stuck between frustrated customers they can’t help and annoyed devs who aren’t able to solve the problem with the information they have. Users feel like no one is really trying to solve their problem.

Developers shouldn’t have to waste their time trying to reproduce bugs while relying on incomplete and inaccurate information about what caused the bugs. Debugging as it is currently done puts developers in the impossible situation where they have to fix problems without knowing what the problems are. 

PlayerZero’s solution: automate the bug reporting process

PlayerZero lets you avoid collection and curation frustrations by ensuring that developers get to see exactly what users did before encountering a problem. When a user reports a bug, developers can jump right into the specific PlayerZero user session – filled to the brim with metadata, cursor movements, committed actions, frustration signals, API calls and everything in-between. 

With PlayerZero, the details that the user provided is much more valuable; the fact that the user’s problem occurred at 4:27 on Tuesday while the user was looking for Purple running shoes helps the developer search (within PlayerZero) for the exact user session where the problem occurred. PlayerZero lets you use whatever your user tells you to help you debug, even if the information they give you isn’t remotely relevant to what might actually be causing the problem.

If something doesn’t work on the user’s computer, the dev can see exactly what happened by simulating that user journey in any environment. Imagine being able to deploy a robot clone of your user wherever and whenever you want. That’s PlayerZero.

The dev can see if the customer trying to order shoes had tried to pay with Paypal or had entered in a coupon before logging in, small details that a user could forget to mention but might be crucial for causing a bug. To see PlayerZero deploy your users, check it out here.

Conclusion 

With PlayerZero, developers don’t have to guess what happened and waste time fishing for a bug that, as far as they know, might not actually exist. Everyone saves the time normally spent going back and forth communicating and developers fix bugs quicker since they can see exactly what users do to cause them. Debugging becomes as easy as it should be.

Say goodbye to exasperation and disappointment. Devs can spend less time and energy putting out fires and more time building new things. Users can get a clean response experience that doesn't require multiple zoom meetings, loom videos or response emails. Support can deliver users and developers good news more often. 

If your product doesn’t work on someone’s computer, you can be confident that you can track down why. To try it out yourself, sign up and join our Beta

Follow us on Twitter
Sign up for our newsletter.
Get the latest articles delivered straight to your inbox.
Share
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Additional Articles