ALERT: Early (discounted) registration deadline for Helsinki Media Innovation Week is today

User research on internal developer platforms helps Schibsted build better tools

By Bhawna Gulati


Stockholm, Sweden


Empowering developers with the tools they require to create a positive developer experience (DX) is the primary catalyst for the majority of internal developer platforms.

While many companies tend to focus their efforts on external user-facing products, prioritising discovery and user research, the same doesn’t always hold true for products catering to internal users, specifically developers. Neglecting this aspect can result in subpar products, missed opportunities, and decreased development velocity.

Researching internal developer platforms at Schibsted follows three steps.
Researching internal developer platforms at Schibsted follows three steps.

Importance of user research for internal developer platforms

User research is an important part of the design process, bearing remarkable significance in the realm of internal developer platforms. It helps unveil needs and pain points of platform users (i.e., developers), enhance usability, and elevate their productivity.

One common pitfall encountered by platform product teams is the presumption of understanding their users’ needs. You might hear statements like, “We’re developers too, so we inherently grasp what fellow developers require.”

That’s a mistake in plain sight. A human doesn’t know another human being. How can you know what problems the user developer is facing while using the platform?

When is the right time to do user research?

Continuously! Yes, you read it right! Just like continuous discovery is important for end user-facing products, it is important for internal developer platforms as well. Digital products are never done and can always be improved and iterated upon.

Imagine if Netflix, Salesforce, or Amazon created the first version and stopped there. We must identify obstacles regularly and tap into the power of research.

Unlocking developer happiness: a case study in improving styling

Does this mean we research for every capability of the platform? No!

It really depends on the scope and impact of the feature/capability/outcome.

At my current workplace, we conduct yearly developer satisfaction surveys to identify obstacles that diminish developers’ overall satisfaction. That is often the first place for us to pick up on problem areas.

One such area was how developers used our platform to do styling of the Web pages. We picked it, validated it with our users, and prioritised creating a great developer experience by improving styling.

Once we have made satisfactory changes there, we will pick up the next obstacle, research, and find our way through users’ happiness.

How we did it

We pretty much followed the discovery segment of our product development framework at Schibsted.

The first step for us was to get the stakeholders onboard with the idea of involving some of their developers and user experience (UX) designers by interviewing them. This is like recruiting users for a B2C product. And, we were gladly surprised that everyone appreciated us doing this research.

Next, we collaborated with our UX research partner and created a research plan that covered the research objectives, themes, and research questions. Since we had two user segments — UX designers and developers — we created two different sets of questions for them.

The set for UX designers was more focussed on their process, and the set for developers involved questions on their collaboration with UX designers and the technical challenges with styling.

It was surprising to know that most UX designers thought the collaboration had scope for improvement while the developers thought it worked perfectly.

Then it was showtime!

We (the UX research partner, a developer from my team, and myself) interviewed about six designers and nine developers. This was certainly our first time as interviewers and we did not want to miss anything our users said, so we recorded these interviews with their consent. Then we transcribed them using our in-house speech-to-text tool called Jojo.

We wanted to make it a team experience, so we then involved the rest of our team to review those interviews and gathered important insights from them.

The final exercise before we started implementing a solution was to prioritise the problems to focus on first. We did this by identifying related outcomes from the analysis and insights process, and then assigned each outcome a priority.

Finally, we voted on what outcomes we believed had the highest user signal and the highest impact.

The highlight from this activity for me was that we all agreed there are areas where there is little user signal. However, as a platform team, we know from our experience with the platform that certain areas will have a high impact, and the users are simply unaware of the technical benefits it can bring.

The challenges and learnings

It’s not all rosy, and there were challenges. Obviously! A few of those have been:

  • Coordinating calendars: Trying to invite four people to a meeting and barely finding a common slot has been tough. We had to do a lot of balancing by splitting up and sometimes taking interviews without the UX research partner. It worked great in the end!
  • Recording conversations: Everyone said yes to having their conversations recorded, but it felt they were uptight and not themselves so we had to chat about some bits off the record.
  • Getting buy-in from team members: This was the toughest part. Getting people excited about spending time on user research was difficult at first. But, with some discussions about what value it can bring for us, we got them onboard. Well, most of them.

While we learned a lot about what areas to focus on, our learnings were not limited to that. Here are a few other things we took away from the experience:

  • Users want to be heard: More than anything else, the most important learning was that users want to be heard. Just talking to the users gave them the confidence we are invested in solving their problems.
  • Empathy is the foundation for understanding users: Because we involved the entire team in reading the interviews and then building insights, they could resonate with the users’ problems. And they were eager to start solving those.
  • Validation is equally valuable: Research is not always for new findings. Sometimes it is important to just validate that we are moving in the right direction. It is equally important to know we are solving the right problem.
  • Research projects need investment: Research projects can require a substantial investment of time. Conducting frequent, targeted research projects with a smaller group of participants can yield greater insights and value, while larger user research projects can have diminishing returns.

In conclusion, research done right for the internal developer platform can help teams get closer to the user and solve the right problems at the right time.

About Bhawna Gulati

By continuing to browse or by clicking “ACCEPT,” you agree to the storing of cookies on your device to enhance your site experience. To learn more about how we use cookies, please see our privacy policy.