Design Research in technical contexts

Some of the most impactful digital transformation happens in the invisible layers of government like back-end code and APIs. 

Research with APIs isn't just about code - it’s about understanding the relationships between systems, developers, their users and the citizens who are ultimately impacted. 

In this post, I’ll share some of our approaches to this type of technical research, when the user interface is a string of data.

Befriending tech colleagues

As much as in non-technical public sector service design, technical research focused on APIs needs to be a team sport.. 

We involve subject matter experts (SMEs), such as technical architects and developers in the entire research journey. We ask technical leads to sense check our research guides to ensure we’re using the right language or phrasing. SMEs are invited to sessions as observers, and are given space in the session for their follow-up questions. We set up debriefs after a session to reflect on what we heard, align around a shared understanding of technical insights and to review the discussion guide and make any improvements ahead of the next session. We also then involve technical SMEs in the analysis and sense-making of raw data, to make observations and technical expertise shape the final conclusions and recommendations.

In some circumstances, it might even be beneficial for technical SMEs to take more of a leading role in facilitating some sessions, with dedicated oversight, coaching and support from the research lead. For example, if it helps participants engage, or if the value lies in detailed probing questions that we wouldn't know to ask. 

Cultivating curiosity

Before technical research starts, we need to be curious about the APIs and the context they sit in. Having conversations and demos with subject matter experts is as important as desk research, as it helps us understand how an API functions in the specific user context or problem space we’re exploring. Collating and visualising information through mapping or glossaries to contextualise abstract concepts can help here.  

As researchers, we need to understand the why as much as the what. For example, if transitioning APIs from legacy SOAP to modern REST, getting familiar with the broader context and sentiment behind this type of technical shift is vital, so we can make sure we’re planning with awareness of the landscape, and asking the right questions through our research.

Planning research well

As with all types of user research, we take the time to figure out exactly which users we need to talk to, aligning closely with stakeholders and subject matter experts. We ensure discussion guides probe workflows, processes, and decision points. In research sessions, building in ‘show and tell’ elements helps contextualise and understand. Ideally we observe participants using the APIs or technical documentation directly to better understand their experience of the system.

Embracing a ‘novice mindset’

Technical research can be intimidating, but being new to a technical system can also have benefits. By asking developers and tech leads to "explain it like I’m six," we bypass the jargon and uncover mental models. 

As a practical tip: when you ask a developer to over-explain, you don’t just learn how the API works, you learn where it’s frustrating, and where they’ve had to build in hacks and workarounds just to get the job done. Ask to see their screens, their error messages, and their dashboards. Actively look for the manual fixes they’ve created where the current technology fails them.

Mapping the developer experience

Developers and other roles that work with APIs are not a homogeneous group - they have varied attitudes, motivations and pressures. Using tools like behavioural archetypes can help stakeholders understand this, as can mapping the end to end build process, identifying pain points and opportunities. In a recent transformational public sector programme, this helped us identify the sandbox as a necessary space to test and fail for developers, reducing the risk of errors in live public services. 

Bringing quantitative and qualitative data together can help us understand the developer experience even more thoroughly. We work with performance analysts to link research insights with real-world data such as rate monitoring and sandbox usage. 

As always, as researchers it’s important we zoom out. We are deliberate in looking at other potential users of the API documentation, and exploring how APIs impact developer’s colleagues, such as workflow managers or product leads, and the end-users they are building for.

Human storytelling to support technical change

It can be challenging to make the ‘invisible’ (like back-end code) compelling. Clear, inclusive storytelling is important for engaging less technical decision-makers, avoiding jargon and explaining technical terms or acronyms. For example, using journey mapping, storyboards, service blueprints and API landscape maps to visually describe users’ experiences of technical endpoints. If you can, show some examples of the front-end UI that the API feeds into. It’s powerful for an API team to see the ‘face’ of their data.  Linking the technical recommendations to user needs can show how a technical pain point could prevent a public service outcome. 

APIs are often hidden enablers of a modern, agile and secure digital public services. By pairing research rigour with technical expertise, we can ensure that this type of digital transformation remains fundamentally user-centred.