Code prototyping

Roll your own UI kit

Ahead of my talk at UX Edinburgh on 5 October 2020 - a quick guide to assembling your own accesible UI kit for making prototypes.

There are times when graphics-based prototyping tools like Invision just won't do. If you're designing a form you need your users to be able to enter real data - possibly showing them real error messages as well. To test Search and Filtering functions you also need to use real HTML and CSS.

On the other hand, frontend development kits like Bootstrap can help you build a huge range of web projects. The downside is they tend to be big, complex and opinionated - you're going to have to work with CSS that has been written in a certain way. If you're truly committed to delivering accessible websites and apps, it's a good idea to use accessible HTML and CSS from the start. Achieve this by picking accessible design patterns and assembling your own prototyping kit.

I've made Shoestring UI as an example of a kit you can use to make your own HTML prototypes.

How to use it

Shoestring UI can be used with any text editor and browser. It consists of an HTML file and a CSS file. Copy and paste the code snippets you need to create your prototype.

Mobile first, content first

There's only one breakpoint in Shoestring UI at a width of 500 px. I've styled six elements so that they are appear differently on wider screens. In other words, this is a mobile-first kit. Mobile-first layouts force discipline on to designers and content creators.

	  
@media only screen and (min-width: 500px) {
/* For larger screens: */

header {
padding: 0.5em 3em
}

#pageTitle {
background-color: #00645d;
color: #fff;
font-size: 1.3rem;
margin: 0;
padding: 1em 1em 1em 2.5em;
width: 100%;
position: fixed;
top: 3em;
z-index: 1
}

main {
left: 2em;
top: 7em;
margin: 0
}

#footer {
background: #000;
color: #fff;
padding: 1em 0 1em 2em;
width: 100%;
margin: 5em 0 0 0;
padding-left: 3em;
height: 5em
}

}

    
  

I've shown labels above input controls, followed by hint text. I avoid using placeholder text which disappears on input.

Here's a hint

What I left out

My philosophy is: if content is important, show it on the page. For that reason I didn't include the following patterns:

Great artists steal

Nothing in Shoestring UI is original. I've taken accessible design patterns and combined them into one kit. There are plenty of great design resources like the A11y style guide to pick from.

If you're looking for some sweet interactivity for a prototype the W3C website offers some sophisticated design patterns. I personally wouldn't know how to code the following advanced data table where you can sort the columns and edit some cells:

Putting your prototype online

My assumption is you can put interactive prototypes online on a service like Heroku without that much effort. Doing this using the GDS prototyping kit is fairly straightforward thanks to the great set of instructions they've written. Their kit is built using nunjucks and express.js so it goes beyond my ultra-simple kit which only uses HTML and CSS. The most important aspect is probably making your prototype password-protected, which might require the help of javascript.

What's wrong with Bootstrap, then?

I personally haven't used the ubiquitous frontend development kit Bootstrap to make prototypes more than a couple of times. It's free and comes with lots of UI patterns as well as icons; plus it has its own javascript library from version 5. However, it's also big, complex and opinionated: it has a Bootstrap approach to doing things. Instead, focus on HTML and keep the CSS as simple as you need for your project.

I have to confess I've prejudiced against Bootstrap after the time I was hired to build prototypes for a set of Google Sprints. One afternoon I'd spent all day building what I thought was a pretty good Bootstrap prototype. By four o'clock I was burned out and had a pushy tech lead standing over me demanding I push it to Github.

And there's the risk of code prototypes - your team can mistake you for a developer. To mitigate this I'd suggest emphasising that prototypes are disposable, you're not writing production code. All you're trying to do is build more realistic experiences for testing your design on real people.

Further reading

We had a spirited debate at UX Edinburgh at bout whether designers need to code. My tuppence worth for designers starting out: learn enough HTML to understand the W3C article HTML accessibility.

Neil Scott found a survey about companies that use design systems - it turns out they have a high maintenance overhead, so start off by researching what you really need at your organisation - 2020 Design Systems Survey.

I dug out the original GDS post from 2014 about why their designers were all learning code. They made the decision in order to avoid the practice of designing in Photoshop then throwing the designs over the wall to a dev team. One important caveat: they encouraged designers to find their own way of getting user feedback rather than obliging them to use HTML prototypes, so paper or Axure was still options for designers - How designers prototype at GDS.

It's relatively rare for designers to prototype in code. The most popular prototyping tools were Sketch, Figma and XD. Material Design was the most popular design system and Bootstrap wasn't really mentioned in the chat. Some tools like Zepelin.io enable designers to turn Sketch prototypes into CSS files but one designer said the quality of the outputs were inconsistent.

Webflow is becoming increasingly popuplar - a visual design tool which you can turn into a live website - Webflow.

I'd urge designers to use the WAVE toolbar to assess if design tools create assessible websites. I note that the Webflow website has accessibility errors as well as all the websites it produced, based on its showcase of sites build with webflow - get the WAVE toolbar at WAVE web accessibility evaluation tool.