Back to articles

Steps for running an internal workshop for designers prototyping in code

Slide from “Advanced prototyping” presentation on branching.

One of the things I love most about working in Government is that the designers I get to work with code using the prototype toolkit.

This is an Express app that allows a person to build a high fidelity prototype or demo of something to go into user research.

With this work been done upfront — often by the time it goes to development a lot of the problems will already have been ironed out.

Building prototypes like this allow us to try out content, new patterns or different journeys — all as quickly possible and relatively cheaply.

One of the reasons I thought it would be good to run a workshop on it was to give designers more knowledge on how to utilise some of the more advanced features, or even get them more comfortable with some of the fundamentals.

The toolkit itself is made up of the following:

You can use the prototype kit to write normal HTML, CSS, and JavaScript but with the above, you can use more features.

The above will create a barrier to some people to use, there is a great community around it (slack/mailing list/training) but there always seems to be a set of common features that people would like more details on.

Step 1 — work out what the gaps are

I had no idea what people would generally say the gaps are, so I sent around a survey this was open to anyone in the design team (front-end, design, and content). in the end only designers filled it in, but the feedback had some clear themes to work on, which where:

Step 2 — write the actual workshop, and workout how to deliver it

Next stage was to work out how to deliver it. I’ve run a couple of none code workshops but a programming one would be very different.

I’ve attended a few that were very different but both seemed to work well.

I decided the format would be:

Each topic comes with an example, technical description an example in a repo GitHub.

This seems to be the right level of detail though I may have gone a bit too technical in places.

Step 3 — running it

The first time I planned to run it I allowed 2 hours, this was an underestimated how long it would take, it took me the best part of 30 minutes to give the introduction.

I did a couple of dummy run-throughs to help settle the content and make sure it was too technical.

Step 4 — reflections and improving it

The first time I ran the workshop it was terrible and didn’t flow at all.

So I decided the format would be changed to the following

The second time I ran the workshop this worked and flowed a lot better. It allowed attendees to see how they could put it into practice rather than following exercises.

The second time I allowed a full afternoon (with time for one-on-one questions) and had removed a lot of the content so there was more time working together.

One of the things I didn’t think about was what level of support different people would need.

Some people took to it straight away — but others needed a little more guidance I was glad another front-end developer was also on hand to help support — as this meant we could spend a little more time on topics.

This was a much better format for a workshop (for both for me, and the attendees).

Step 5 — adding new stuff, nothing is ever done

Both times I’ve run this workshop — I added new examples based on what was being asked. I also added a couple of examples of automatic session stores, better validation examples and how to use macros in nunjucks.

orginally published on medium