All of the designers at GDS can code or are learning to code. If you’re a designer who has used prototyping tools like Axure for a large part of your professional career, the idea of prototyping in code might be intimidating. Terrifying, even.

I’m a good example of that. When I joined GDS I felt intimidated by the idea of using Terminal and things like Git and GitHub, and just the perceived slowness of coding in HTML.

At first I felt my workflow had slowed down significantly, but the reason for that was the learning curve involved – I soon adapted and got much faster.

GDS has lots of tools (design patterns, code snippets, front-end toolkit) to speed things up. Sharing what I learned in the process felt like a good idea to help new designers get to grips with how we work.

A sketch for the Highway Code

Don't be scared. First, it’s hugely helpful for new designers to understand the rationale behind why we prototype in code, and to learn some shortcuts for getting started.

HTML prototypes look very close to the real GOV.UK. They tend to be higher-quality than those produced using other prototyping tools. This is good for several reasons:

user research participants are less likely to be distracted by visual fidelity

by visual fidelity it’s easy to share (no plugin required to view a web page, unlike Axure)

(no plugin required to view a web page, unlike Axure) the prototype works exactly like a web page. It looks and behaves like the real thing.

This post explains the original rationale for why we work this way.

A prototype does not mean code must be perfect. In fact, it shouldn’t be: the majority of time should be spent iterating the design, not making code beautiful. Prototypes are made to be tested and iterated (and if they fail, thrown away).

So it’s better if we can prototype fast. Once the design has been tested and is ready to go to production, front-end developers are there to make code efficient and secure, and to focus on things like performance.

Every project and design process is different. GDS isn’t prescriptive about what you use to validate design ideas.

A design process could be anything: it might begin with sketching on paper, or mocking up using graphics software (such as Sketch or Illustrator), or downloading a GOV.UK page to edit the content locally. Or just using the browser DOM inspector to see how changing something might look.

This is how we work at GDS, and these are some of the tools we use. None of this is revolutionary. As we’ve said before, we’re flexible and optimise our approach for meeting user needs and for delivery. But here’s how we work right now.

Start with sketching

It’s always quicker to work out ideas on paper than to jump into code. Sketching is non-committal and an important part of a good design process. For sketching, all you need is some paper and good pens. Also see Ben Terrett’s sketching templates which can help you get started.

Sketching kit

HTML and CSS

If you’re a designer with minimal HTML and CSS knowledge, it’s best to focus on getting your code working locally on a prototype kit. Once you’ve got your head around things – namely, running your prototype on a local server and using the front-end toolkit – you can move on to learning your way around Git and GitHub.

If you’re completely new to writing HTML and CSS, learn or revisit the basics on Codeacademy.

Once the prototype kit is set up, the majority of your coding at first is likely to be basic typography, so it’ll be useful to become familiar with the typographic styles on GOV.UK.

Prototype kits

Get set up with a prototype kit. A prototype kit is a set of tools that allows us to bring in GOV.UK styles, templating features, and server-side capabilities. It speeds up the prototyping process. Schedule time with a front-end developer who can help you get set up using a kit.

There are two kits (actually, there are more than two, but start with these) which are good for different things – if you’re not sure, ask to figure out what would work best for your project:

GOV.UK Prototype Kit

Good for rich, interactive prototypes, especially for designing transactions (for example). It’s worth noting that there’s a steep learning curve.

Static Prototype Kit

Good for very simple, static pages. This is a more limited prototyping kit.

Git and GitHub basics

GDS codes in the open. Even designers. GitHub which is a website where code is hosted and managed, with changes attributable to individuals. At GDS, everything possible to share is hosted on GitHub.

Git is a distributed revision control and source code management system. Don’t worry, you don’t need to know what that means.

The main benefit of using Git and GitHub is that every change (“commit”) is tracked and can be rolled back. No more FINAL_FINAL_FINAL_10_ACTUALFINAL.psds. Additionally, multiple people can contribute to a single prototype.

A friend's attempt to explain branching

Learning Git

There are lots of guides to Git.

Branching is a word that will come up when you read about Git. Branching is extremely useful and allows you to manage different versions of something within the same prototype. However, if you’re brand new to Git, don’t worry about the details of branching just yet, but for now think of it as a means of managing different versions of a prototype.

Hosting and sharing prototypes

You can share prototypes by hosting them on Heroku. The URL to your prototype can easily be shared and anyone can view it without having to install a plugin, because it's a website.

Here’s a guide to deploying a prototype to Heroku.

Consider whether password protecting your prototypes would be a good idea (and if in doubt, check).

Behaviour

Designers who have used prototyping tools will be familiar with tools for adding interactivity: for example, the ability to toggle a panel visibility when a button is clicked. This can done in jQuery using the same logic.

If you’ve been happy using conditional logic in prototyping software like Axure, jQuery can be used with relative ease, and the ceiling for learning is much higher. This is a good thing. The jQuery API documentation has many code examples you can use and modify, and Codeacademy has a JavaScript track.

Organising and managing versions of prototypes

If your prototype contains a lot of pages, it might be a good idea to create a contents page on the root index so your team can use it to find designs easily.

It might make sense to maintain copies of a prototype. For example, a stable version for build (rarely updated) and an experimental version for testing (constantly updated). Different prototype versions can be hosted and shared on Heroku.

A challenge is defining when a design migrates from an experimental version to a stable version that will be built, especially if you’re working on a bigger project. If you choose to work like this, make sure the process is defined well with your team.

Resources

I’m Rebecca, Interaction Designer at GDS. You can follow me on twitter @rivalee