Lessons from a technical documentation discovery
Things won't always go to plan and that is okay
Hi there! My name is Tolani and I’m a user researcher currently investigating how to improve the experience of using HMRC’s technical reference guide (TRG). This is the internal technical documentation their Platform teams provide to the service delivery teams (the teams who build the tax services the public use). The project started off as a discovery and now we are in the alpha phase building an MVP. Today I will be sharing the key lessons I have learnt so far.
Focus on target audience more as they are not always equal to your users
The technical reference guide was created for service teams, yet we discovered that many people actually did not use the documentation. This prompted us to conduct some research with “non-users” too, where we discovered that some teams were not informed about the TRG during their onboarding. It also helped to identify which roles were not being considered in the content and the alternative resources employees turned to.
Add screening questions to publicly distributed surveys for quality control
We distributed a survey on TRG usage on Slack to collect some quantitative data on how service teams use the TRG. In the results we found that 19% of the participants were not our target audience. So had I not added in a question asking participants what type of team they worked in (e.g. service or platform team) then we would have ended up with an incorrect view on the usage of the TRG by service teams.
It’s okay to run workshops with a blank slate
As part of the discovery, we wanted to find out the process of building a tax service so I created a lovely table in Miro with column headings such as “create a microservice” all the way down to “decommission microservice”, only to conduct the workshop and find out that the participants actually viewed the service lifecycle completely differently to what we had thought.
So I gave participants freedom over the board where they created a map which reflected the stages of the GDS lifecycle e.g. Discovery, Alpha, Beta, then they listed out the activities under each stage (which included some of the activities which I had originally created as headings). The map created by the participants gave us an insight into the full end to end journey and taught us that Platform teams need to incorporate a ‘‘bigger picture’ perspective when providing documentation as the TRG only covered a few of the activities.
To summarise, it is great to plan research but one should always be adaptable and remember that the goal is to collect the information you need and not follow a perfect research plan. That does not mean you should throw away the plan but adapt it as you gather new information to ensure you are using the best methods to meet your objectives.