At Usersnap we strongly believe that an improved feedback and communication process will save you (and your team) a lot of time spent on communication in your development process. Picking the right communication tools does not only directly result in better workflows but also affects the time needed to fix a bug which is particularly important if you are publishing your code continuously.
Phone calls, meetings, IM chats and screen sharing sessions are efficient ways to discuss bugs and planned improvements of every software development project. There are two stashed requirements here: two people need to communicate at the same time. This is not a roadblock if you are sharing a desk but it can be a challenge if you are working in a distributed team or if you simply don’t want to interrupt your colleagues.
On the downside, one-on-one communication is only effective if nobody else needs to be involved after the topics have been discussed. As the famous group intercommunication formula for a team of N people still is N*(N-1)/2, even small teams should focus on effective communication to reduce the communication overhead.
If you are working in a startup environment (e.g. a team of 10) and take into account that some issues will be reported by your customers (e.g. +10 people you should listen to) you easily end up with 190 possible combinations of one-on-one communications streams. Online SaaS productivity tools like bug trackers and project management tools are basically striving to solve this problem by enabling people to communicate in groups, asynchronously. Anyways, the root cause of misunderstandings lies somewhere else.
Well, crafted bug tracking tools help you to keep up with the communication challenge. However, in the end, clients will send bug reports and feature request by email which will lack the context of the perceived bug and might read as:
“The blue button does not work”
This is exactly what’s perceived but there is little help here for solving the bug as it requires to guess the context of this bug. Specifically, in web development, it is common to deal with browser-specific bugs (“It works in Chrome but not in Internet Explorer”). Also, the rise of responsive web design introduces another important information to reproduce perceived issues on web project: the current user’s browser size. Developers know what’s necessary to reproduce a bug but clients and users who want to report bugs may not understand why a good bug report necessarily needs some contextual information.
If you are exceptionally lucky those emails might contain a word document with the collected issue or even a PowerPoint presentation with sketches of your clients’ suggested UI improvements.
We believe that life is too short for puzzling bug reports, Usersnap speeds up your development process by helping developers, customers, and quality assurance engineers to communicate effectively about issues and share feedback. A bold claim you say? That’s why we crafted a case study to back it up with data!
In this case study, we are comparing bug reporting via email and the same process involving Usersnap.
We have selected three bugs which were reported by email over the last several years. The first one is only a design change request (“Move the logo from the top to the bottom”), the second one refers to an issue where a customer couldn’t find the CVV input field in on a checkout page (“Where is the CVV field for the credit card?”) and the third one is a bug which only occurs in a special environment (“I can’t read the state’s entry because it is too small”).
As all these three bugs are design bugs, we estimate that the fixing time for all of these issues is equal, assuming that they are handled by a skilled developer. Looking at past projects a typical design issue – including testing – takes about 45 minutes, so let’s assume it takes “only” 45 minutes to fix one of these bugs.
It’s common knowledge that reading emails are extremely time-consuming. Everyone who has worked at least with 3 different customers at the same time knows the dreaded emails with the subject “please can you fix this quickly?”. It’s even worse – reading emails takes time but switching between problems/projects/issues/people takes an average of 23 minutes and 15 seconds to switch back to another task.
Nothing can be done quickly! We have learned that reading an email and actually being able to understand it, reproduce it and decide if you can fix it now or not, takes (at least) 20 minutes.
If we only look at the time spent fixing a bug, adding an annotated screenshot to your bug report with Usersnap outperforms any email. And although roughly 180 vs 125 minutes is a vast improvement, there’s another time guzzler.
Communication Time. The evil of every process. As you can see in the chart below you will save more than half of the communication time when you are communicating issues visually. In our whitepaper, we found that developers lose a lot of time trying to reproduce a bug in different browsers (versions) and operating systems – and even on different devices. The amount of communication items is reduced to only half the size if you’re using Usersnap, as we attach these pointers in the meta-information.
Using annotated screenshots with this meta-information you recreate the visual context you have for the person on the receiving end of your conversation. Just think of all the emails you send back and forth, figuring out why and where a bug appeared exactly!
If you add time to spend on communication to the fixing/development time you get a whole different picture. We have multiplied the hours with a typical hourly rate for a medium qualified developer (100 USD/hour). This bug fixing thing can get very costly!
Working with annotated screenshots attached to bug tickets in your bug tracker saves you a lot of time, money and nerve-wracking experiences. Communication is a very expensive thing in a company and can easily be reduced by adding visual context to your bug report or feature request.
To round up we have created a chart where you can see that communicating visually, reduces your costs by about 48%. Reason enough to improve your process today!
You can try Usersnap for your development for 15 days for free and see whether it brings the same time efficiencies to your company. Try Usersnap for Free!
Selecting the right UX research tools transforms how product managers, CPOs, and product designers tackle…
Are you experiencing delays and setbacks in your product development process due to ineffective bug-reporting…
On a scale 1 to 10, how confident are you that your own website experience…
In today's market, product managers and CPOs can access a wide range of Enterprise Feedback…
In today's product management space, finding the right tools to navigate the complexities of the…
In the early days of personal computing, my generation used to spend a lot of…
