How User Research Can Improve Internal Communication?

It’s a powerful tool to better understand the market, the users, and their needs. It comes in handy with building actionable user stories in a very short period of time, helping you adjust the product to your audience. We leveraged it in one of Netguru’s internal projects, called Netguru Software Radar, so our team could take the most out of it. Here is how it went.

What is Netguru Software Radar?

Netguru Software Radar is an internal company service showing the tools, technologies, and methods that we deal with at Netguru. It distinguishes the ones that we use on an everyday basis, the ones we experiment with, and those which we find outdated. The radar helps tech leaders discover areas where we should invest and determine the direction the company should follow to stay on top of things.

The Radar was created a few years ago and in its first version the goal was very simple - to picture all the technologies in our stack on a map in the form of a radar, so that our team members could have a good visual overview of the technology that we work with as a company.

Why change it?

Over time, we have noticed that there was still loads of potential left in the tool. We knew that many team members, especially newcomers, did not know about its existence and that knowledge about new technologies (which changes dynamically) was scattered across different channels, mostly on Slack, instead of being shared within the Radar map. The team was basically looking for people who were experts in a particular technology stack and asking them questions. Because the questions were spread across different channels, the same ones were being asked over and over again and we felt this was not the most effective way to manage internal knowledge.

Our approach

With all these problems in mind, we felt that a good starting point would be to get a full picture and gather real data about why and how our team members use information regarding our technology stack. We were interested in how they obtain it and what are the most common obstacles they come across while doing so. We also wanted to find out to what extent the Radar was being used and whether it was considered useful by the team. We surely had many hunches and assumptions about the outcome , but the point was to start building a better product based not only on intuition but above all on facts.

The research issue

The first step was to structure the above research goals and put them into questions:

1. What tasks require information about the technology stack in order to be carried out properly?
2. In what situations and how often does the need for such information occur?
3. By what means is this information gathered?
4. What are the alternative actions when this information cannot be found?
5. What are the most common problems with gathering this information?
6. To what extent does the current version of the Radar meet the team’s needs and what could be improved?

The method

Apart from what had already been done (the observation of messages exchanged in public channels of our company chat, which captured a variety of situations regarding the knowledge about technology stack), the obvious method to answer the questions above was to conduct in-depth interviews (IDIs) with stakeholders from different teams within our company. Given the availability of our team members, it seemed like the most valuable source of first-hand insights we could get.

We were hoping to identify needs and goals underlying the use of technology stack knowledge and come across ideas for improvements stemming from the nature of the most commonly encountered problems.

User interviews

We wanted to keep the user research phase short and actionable, and so we conducted a total of 6 interviews with team members from different departments, with different tenure and scope of expertise, to get the widest perspective possible. The interviews lasted no longer than 45 minutes each, given that we did not want the respondents to be away from their everyday duties for too long.

Each interview consisted of

• an introduction,
• several open questions based on the research issue,
• and a wrap-up.

Because of each team member’s different background, every interview turned out to be a little different, as we let the conversation flow its own course depending on the respondent’s story. As the nature of the study was for an internal project, we did not feel that recording the interviews was necessary. However, we did keep detailed notes in order not to miss any important information.

Analysis of the results

After the interviews, we analysed the responses we got. The analysis was qualitative, so it was about categorising answers and looking for patterns in the different answers. We prepared a matrix with all the responses and labelled them with corresponding user needs or encountered problems so that it would be easier to aggregate them. We ranked the findings taking into account the frequency in which they came up, but also the emotional load that the respondents gave to them. As a result, we had a list of the most important needs and problems that the Radar should address.

The output

After the analysis, equipped with a list of tangible needs and problems related to the use of knowledge about different technology stacks, we proceeded to ideating how the Radar could meet the needs and relieve the pains of our target user group. We had a solid, fact-driven foundation to come up with solutions and enough data to prioritize those solutions. Instead of writing a full report (which we normally would have done when cooperating with an external client), we decided to write user stories, which allowed us to translate the ideas for solutions into software features. Some of those features included being able to:

• Identify the history of handling a given technology stack in our company,
• View previous projects and expert team members in particular technologies,
• Find sales information related to a technology stack,
• Share information with clients in an easy way,

...and many more.

Conclusion

Designing digital products based on research does not have to be time consuming, costly or complicated. It can be conducted in various ways and it always depends on the context of the idea for a product. It is never set in stone, but it always adds value to the product - it makes design and development decisions more user-centered and thus more likely to be successful. The investment of resources compared to the benefits is definitely worth it. Thanks to the user research we did for Netguru the Software Radar, by the time we started writing user stories we were fully convinced that we were heading in the right direction and planning a product which would be relevant and usable.

And now? After the round of user interviews we did at the beginning, and then further into the project, a working group among our team members gathered for regular meetings in order to track the performance of the Radar and talk about possible improvements. The group is cross-functional and new features are being implemented according to priorities agreed by the team. Stay tuned for the next news about our Radar!