Steps for running an internal workshop for designers prototyping in code
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:
- Nunjucks, templating for HTML markup
- sass, what is used to generate the CSS
- gulp, task runner
- gov_uk modules (toolkit, elements, template)
- git, version control
- heroku, hosting
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:
- session storage
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:
- bit of theory on the topic
- task around the topic
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
- overview of everything (with examples)
- small group exercise to build a thing
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.