Developers are users of Government as a Platform (GaaP) products. They’re the people who’ll integrate products with services to send text messages, process payments or host applications.
We want all our users to have a good experience with GaaP products and components.
Earlier this year we talked about how we’ve been improving our developer documentation. Just like the interface, the developer documentation is a crucial part of our product and needs to go through user research to ensure it’s easy to understand. Getting started should be quick and simple for everyone.
Research with technical users when you’re not technical yourself (like me) can be daunting. So I want to share some tips from three lab days and pop-up sessions we ran with developers across government.
Ask your team to plan with you
It doesn't matter if the user researcher isn't technical because user research is a team sport. Do you have a developer on your team? How about a designer and a product manager? A rich mix of experts can help you plan a great research session.
In our recent GOV.UK Notify user research sessions, we wanted to see how quickly and easily users could start sending messages.
To prepare for this, user researchers looked back at research questions, which were developed during our alpha. The questions were aimed to help us learn more about the developer user experience of integrating with GOV.UK Notify. We used these questions to map out some draft tasks.
We put the draft tasks on a board and ran a workshop with the product team to refine the plan. The most important thing we learned from this exercise is that some of our draft tasks were focused on testing the participant’s coding skills rather than testing how easy GOV.UK Notify was to use.
Originally we wanted to ask users to build a simple prototype service and then integrate with Notify, but we realised this task would take up most of the session and wouldn’t necessarily give us any insight about the product.
Instead, our own developers created the session materials by building 2 versions of a test app using the two most popular languages used by developers to integrate with Notify - Python and Java.
This first workshop was crucial. The team gave us ideas about how to make the tasks more relevant, they suggested new tasks and decided which ones to scrap.
Have the expert in the room
One thing that works really well is to have a pair programmer, as well as the moderator, in the room at every research session.
This has two advantages:
- it helps us avoid accidentally testing the participant’s programming knowledge
- it means we can quickly solve small technical issues, keeping the session focused
(Secret advantage number three: a pair programmer provides a non-technical researcher like me with some much-appreciated backup.)
Don't be afraid of an informal setup
On the first day of our user research, we narrowly avoided a disaster - the lab was double booked. With some inspired thinking from our lab manager we created a makeshift lab in a quiet area of the office. Participants brought their own laptops and hooked them up to a TV screen facing away from them. A small group of observers and note-takers were sitting unobtrusively on the other side, watching the screen.
This felt surprisingly good. It was more true to life than being in the lab and at the end of each session the team could have a chat with the participant rather than the researcher relaying questions from the ‘other room’.
Go where your users are (but still involve your team)
We’ve learned it’s tough to recruit developers outside of GDS for lab sessions at Aviation House. So I started asking people if I could come to them. I immediately got a lot more interest.
The potential downside to this is your team miss out on observing the research. That’s the valuable thing about lab testing: everyone can come along for a session and watch users use the product. So how can we replicate this with field research?
I’ve just finished a session with developers in Leeds where we streamed the action back to the lab in London. The tech setup for this was really simple:
- a phone
- a makeshift stand
- Blu-tak
- wifi access
We pointed the phone at the participant's screen and had a Google Hangout with our lab manager. The team came along to watch the big screen in the observation room and take notes as usual. This approach meant we were able to carry out contextual research but still involve everyone on the team.
It’s just like any other research
Technical user research doesn’t have to be scary. Youll probably have to iterate across several sessions until you find an approach that works for you.
For example, we used to sit quietly while participants figured out how to get the prototype service running on their machine but now we talk them through this setup bit to get them started quickly.
Your team will have lots of good ideas too, so ask them at playbacks what else they’d like to know from users.
And it’s worth taking the time to do this research. Because developers are users too.
If you’re a developer and would like to see how Notify works then we’d love to come and visit you so do get in touch.
Follow Katie on Twitter and don't forget to sign up for email alerts.
GDS is expanding, and we have a number of positions that need to be filled - especially on the Government as a Platform team. So we’re always on the lookout for talented people. Have a look at our videos describing how we work, our vacancies page, or drop us a line.