Designing Session Recording feature for Requestly
BACKGROUND
I worked as UX Design Intern at Requestly for about 2 months and this was the project I worked on, under the guidance and with help from the CEO Sachin Jain.
Timeline : 4 weeks
Requestly is a SaaS based devtool available as a browser extension for Chrome, Firefox, Edge and desktop app available for MacOS and Linux. It mainly focuses on modifying Headers, redirecting URLs, switching Hosts, Mock API Response, delaying Network requests, inserting Custom Scripts, etc.
WHAT TO SOLVE FOR
Session recordings can help to share debug sessions to the developers or QAs with video, network logs, etc. As Requestly was aiming to remove user painpoints with respect to developers and QAs, session recording feature was a great step in that direction.
So the problem statement was to : Design the first version of screen recording feature for Requestly.
VALUABLE INSIGHTS
Reaching out and talking to various developers and QAs over Linkedin, twitter, mail, etc, I got some valuable insights about the communication between the developers and QAs, also their frustration and pain points. Some of them are listed below -
“I need to reproduce bugs in order to understand them, but bug reports don’t give me enough information to deduce what’s going on”.
“I can’t figure out when my app/site is having errors”.
“I need to know who's been affected by a bug”.
“I need a way to prioritize bugs by impact”.
COMPETITIVE ANALYSIS
As part of my goal of making the user experience as smooth as possible, I went to explore what was currently successful and could be improved.
TARGET USERS
The primary users of the feature were targeted to be developers and QAs. Variations in devices, OS, browsers, screen sizes and resolutions, all introduce elements that can make QA and software testing tedious, error prone, and inevitably limited in scope.
When the developer encounters a bug, he/she wants to provide detailed reports to QA engineers. They need an easy way to demonstrate the bug in action. They will most likely also need some comprehensive documentation to have well documented reporting.
The QA’s primary goal is to identify and report bugs effectively. They need an easy way to demonstrate complex defects and provide a visual representation of the issues they encounter. They need to communicate issues clearly to the developers. They need an efficient way to showcase the behavior of the software before and after changes, highlighting any unexpected discrepancies.
USE CASE
Although Screen recording feature can be used for many use cases, in this project we mainly focused on the use case of reproducing and solving bugs faster.
With session replay tools that capture all sessions, QA and software testing don’t stop at launch. Indeed, session replay can be used alongside product launches, allowing product developers to observe as users engage with a new feature or interface to make sure it's working correctly.
Session replay is a powerful analytics tool that can dramatically reduce the time it takes to understand and eliminate software glitches, coding errors, and other pesky bugs on websites and web applications.
BRAINSTORMING AND IDEA SESSION
We brainstormed various ideas on how might we optimize session recording features to empower developers and QA teams in efficiently identifying, reproducing, and resolving issues, while also facilitating performance improvements, compliance, and collaboration. Then we arranged them on a NOW-WOW-HOW matrix to judge feasibility of each idea.
ROUGH USER FLOW
To ensure that the there was a smooth user flow, I sketched out a rough flow to keep myself abreast of how my user might proceed through the product.
1ST ITERATION
The screen was designed and tested with some users. There were some major insights that were provided -
The main attention of the user was going towards the stats rather than the primary action of the product which was to record sessions or view the saved recordings from the table.
If the user had a large number of saved items, there has to be an option to filter out his required content.
Although the user could ultimately figure out how to view the saved recordings, it still left an iota of doubt in his/her mind.
2ND ITERATION
Building upon the feedback received, we made changes in the design and made sure it was suited to user needs-
The stats cards were removed as they were taking a lot of attention of the user away from the primary action.
A filter function was added to counter the problem of viewing selective data in case of large sample data.
A play button was added in each row of the data so as to guide the user on what action to take or what interaction to expect on clicking that row.
TRADE-OFF
Although almost all the elements were covered in the testing, there was one element we wanted to particularly focus on the slide-out panel.
After much brainstorming and a small A/B testing, we finalized on the right variant of design because although the left had less cognitive load on the user by partitioning the FAQs and the comments sections, the right one reduced the number of clicks.
The decision was also influenced by the number of FAQs we were going to have initially, and it was decided to iterate further if the number of FAQs needed to be increased in the future.
FINAL DESIGN
Session Recording home screen
This screen would be the first to guide the user to experience the feature of session recording. It was made sure that all the functions that the user might need like sharing a video, deleting it as well as visibility were clearly defined on the table.
The primary button of Configure was placed as per it’s importance in the feature and to prompt the user to act on it.
Recorded video playing screen
This screen would come up as soon as the user clicks one of the recorded sessions. All the info necessary like the console logs, network logs, etc were clearly demonstrated through tabs view.
A message icon was placed to make the user aware of the time-stamped comments feature, as well as saving space at the same time.
Slide-out messaging panel
This screen would come up as soon as the user clicks on the messages icon the screen. A messaging panel slides in where we can see the already existing time-stamped comments, as well as space to add more comments as well.
Some common FAQs were also added about the messaging feature so that the user can easily access them in case they have any problem in the adding or viewing any message in the slide out panel.
DESIGN HAND-OFF AND DISCUSSION
The screens were showcased to other members of the team and their approval and feedback was sought, before proceeding with the handoff process.
Script notes were provided alongside each design to convey the important points. This ensures that the engineers can always refer to the notes and be sure about how it’s intended to be.
IF I COULD GO BACK
I would try and test this feature with other types of secondary users such as project managers, or even UX researches who might be keen on observing the user’s behavior on the site. This would introduce another usability angle to the session recording feature, and also expand the user base. (This wasn’t possible due to multiple constraints)
LEARNINGS
It’s important to have all the ideas from start till the end even if some are discarded. We never know when we might need to revert back to one of those.
While working on the designs it is important to collect and properly analyze any feedback. We can’t always expect the feedback in any particular intended phase, it can come any time and has to be analyzed.
