ONS Digital

My talk at Product People West & South 14 Nov 2018

Rob Chambers, Product manager, ONS website and APIs

As part of CMD (Customise my data) I was given the opportunity to choose which of out two teams I wanted to lead. I chose to focus on the APIs as this was the area I felt my knowledge was weakest. This post/presentations share my experiences as someone new to this and where things seemed to differ from my previous experience working on UI/web products. Some of these I think I would have a better approach for next time. With some there is more to learn!

Make ONS data part of the web

CMD aims to improve the way users can find and use the data ONS produces. We are doing this by taking data from Excel and making available through a new filter my dataset product and via our new API. We are also directly linking geography and statistics for the first time on the ONS website to allow users to see what data we have for any location.

Fewer and different voices

I have been used to a number of different voices in the mix when building web products, UX, UR and developers all bring different viewpoints on the best way to meet user needs. One of the first things I found was that these voices are missing when we look to build an API with the team we had working on it only being the developers and myself.

This lack of diversity of opinions is something I would want to look at next time round about how we can get more involvement from these teams and encourage them to step out of their comfort zone as well.

Understanding compromises

We balance compromises constantly whilst prioritising, this is no different when building APIs.

Whilst some of these work in the same way a lot will be made in the detailed technical discussions when we make the choice between A and B. I think because my understanding was much lower I found I need to be a lot closer to the conversations to understand the compromises we are making and make sure we were building the product I wanted an users needed. I think it proved useful the other way round though as I was able to bring to the discussions ideas for future plans and direction that gave everyone a fuller picture.

Server-side iceberg

One of my biggest takeaways of working on the API side exclusively was just how much of the development work goes on under the surface and out of side of anything a user will see: Authentication; Audit; Encryption; Graceful shutdown; Logging…

This is all good stuff and things you want from a production, or near-production, system but can make prioritisation difficult. Balancing the ones you need to do upfront and the ones you can add in later was the area we didn’t get right with CMD and where I think I learnt a lot for when I do this next.

User research

We deliberately planned for our internal and external API to be the same thing so we had one set of users close to us in the form of the web team. This approach comes with a risk that you build to meet the user interface and ending up with a product too tightly coupled with this and not fit for direct users of the API. To counter this we were keen to follow our normally user research approach, but how do you usability test an API?

Users don’t interact with APIs the same way as websites so our normal testing tools don’t work, there didn’t seem to be a sensible way to give users a task and watch how they completed it. We knew from previous testing and from the experiences of our own developers that having time to familiarise themselves with the docs and some trial and error tended to be how users would approach a new API.  We gave users ‘homework’ and the combination of the developer site and a link to the API and then had much more informal sessions where users showed us what they made and what they struggled with.

Tools and testing

This was another example where I am used to there being more specialisms. On a web change I will have the sign off but when it comes to checking the detail of UX changes I rely on the UX team. This also becomes more difficult with APIs and there is no UI you can have validate looks right. Thankfully there are a lot of tools out there that help with this and I took to using Postman to check our API and sign things off.

We also made heave use of swagger specs – a way of describing and documenting APIs – for a number of uses. Primarily they gave the web team a reference for what we were building but also went on to be automatically built into the API reference part of our developer site.

Being more hands on with the testing in this way gave me a greater understanding of the product as a whole and ultimately made my life a lot easier when looking at future sprints.

Asking questions

And finally. Unless you have come from this background there will be a lot you don’t know and I had to become comfortably asking question I knew everyone else in the room knew the answer too. Also learning how to ask questions in a way where you will understand the response was an interesting challenge!

My slides