I’m a designer and I prototype in code, the kind you put together to test ideas quickly and iterate continuously to meet user needs. Home Office Forms (HOF) is a tool created by developers to help them rapidly build the real service with robust code. So I wondered, could I, a designer with limited development skills, use HOF to build prototypes?
Let the challenge begin
I started with the HOF guide, which explains how to build your first form. It states that I should have working knowledge of software such as JavaScript, Node.js and Git.
I have a good understanding of Git, some awareness of JavaScript and not much knowledge of Node.
From a non-techy point of view, reading the guide was like trying to crack the Enigma code. Everything sounded so cryptic, from 'installing the HOF cli' to ‘customising configurable behaviours’.
I managed to follow the step-by-step instructions to create a folder and initialise, or run the set-up of HOF, within it so I could see the beginning of my form in a local browser. So far so good.
Then the instructions became increasingly complex and I found it hard to keep track of the folder structure and remember where key files were located. Things were in different places and, sure enough, became lost. I knew I would struggle to remember where everything was. How can I make this easier to understand?
Deciphering HOF
I wanted to understand better the relationships between the files and their effect. So, taking a design-led approach, I created a diagram.
I mapped where key files were and annotated them. Then, on a screenshot of a finished page, I related the files and their functions to what they affected. This really helped me understand where everything sat and how everything was connected.
I then started to realise how efficient HOF is. Rather than having to create and manage multiple files to create a prototype, those files were reduced to ‘steps’ within a master file.
Similarly, all error messages are stored in another file. HOF is already programmed to flag up errors – I just need to provide rules on when and how they should be shown.
Another benefit to HOF is it’s coded in such a way that any information a user puts in during testing gets dynamically pulled through to mimic a live service. This makes the form even more realistic when it comes to testing.
I’ve still got a lot to learn, but given my limitations with some of the software, I managed to get by. Some of the instructions are fairly straightforward, but I recommend you make friends with the developers in your team so they can help out when you get stuck (like I did a few times).
In return, I gave the developers feedback on improving the guidance to make it more user friendly. When something is complex, I recommend simplifying it or translating it into a visual diagram to make it easier to understand.
I still have a long way to go with cracking the HOF code, but I was pleased that I managed to make a working version and learn a lot about alternative ways to build prototypes.
There’s an active community on GitHub and a #hof channel in the UK Government Digital slack channel.
Leave a comment