We’re building a Platform as a Service (PaaS) to make it easier to host digital services in government. We’re doing this because we know hosting is one of the most time-consuming barriers for government service teams.
In this post, I’ll explain what we’ve learnt from user research over the past 6 months and how we’re improving the PaaS as a result.
Start with user needs
Our primary users are developers and web operations engineers in service teams. We’re running monthly user research sessions with them to build a PaaS that’s simple and intuitive to use, and based on user need.
What we've been testing
We've given participants from across government, industry suppliers and GDS tasks to test how easy it was to do things like:
- deploy an application and link it to a database
- integrate with continuous deployment processes
- set up new development environments
- use our documentation
Design for the command line experience
Unlike most things we make at GDS, there’s no graphical user interface (GUI) for the PaaS. Currently, the only interface is the Cloud Foundry command line client. This means the user experience of our PaaS is based on the user’s interaction with the command line and our documentation.
We observed that many developers split their attention between the command line and documentation. They put their browser and terminal windows side by side, so they can copy and paste commands and code snippets directly across. Users tend to scan the documentation from one code snippet to the next. So we’ve been careful to ensure all important steps are included as code snippets, to make it easier to follow.
But it’s not enough just creating good experiences within our documentation. Users frequently get confused by unfamiliar and unintuitive feedback in the Cloud Foundry command line client. As a result, we’re making recommendations to the Cloud Foundry community to change command line feedback based on our research.
Build it for everyone
We want the PaaS to be for everyone, regardless of skill level or experience. Users we’ve met can, for the most part, be divided into two groups: ‘readers’ and ‘experimentalists’.
The readers
This type of user tends to be less experienced with infrastructure. They're junior technologists, frontend developers and designers. They tend to read all of the documentation before starting. They follow the example tasks in our documentation word-for-word. Although they usually complete tasks successfully, we've heard them say they don’t have a clear mental model of how it all works.
Normally we hide information about how our products work from our users and say they shouldn't have to understand how it works in order to use it. But for our users, having an understanding of the underlying technology and how it all fits together, is useful when they want to do something more complex, or if they need to debug.
For these users, it’s important we design a journey through the documentation that teaches them how the platform works as they go. So to do this, we've been iterating the 'Quick set-up’ guide in our documentation and our technical overviews.
The experimentalists
This type of user is more familiar with cloud infrastructure. They are web operations engineers and experienced developers. From what we've observed they are less interested in reading documentation, and tend to jump straight to the command line and start playing around.
‘Experimentalist’ users rely on feedback in the command line tool to learn how the platform works. They use what they already know to guess potential commands and rely on feedback to signpost them to relevant Cloud Foundry commands. They read the output when they deploy an application, to build their understanding of the underlying technology.
These users face difficulty when the command line hasn't provided enough output. Similarly we've seen users have problems when the logs haven't provided enough detail about their application. We'll investigate these issues more in the coming months.
Make debugging easier
While testing the experience of linking an application to a PostgreSQL database, we found users want more control and visibility of the database.
Users frequently tell us they want to secure shell (SSH) onto the virtual machines which their applications run on. SSH allows users to login and execute commands directly onto a server.
We had disabled SSH functionality on our PaaS, but usability testing reinforced just how much developers rely on this for debugging. So we’ve switched it back on - as well as improving the ‘troubleshooting’ section in our documentation.
We need users to help with our research
We need more developers and web operations engineers to take part in user research on the PaaS. These sessions are an opportunity to try the PaaS and help inform how we shape the future of cloud hosting in government.
Usability research doesn’t have to take place in our lab in Aviation House - we’re willing to visit teams across the country too.
If you’re interested, get in touch.
Follow Holly 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. 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.