Prototyping in government is a really big deal. We use prototypes to test and research ideas so we can learn what our users need.
Interaction designers are pretty experienced with coding and prototyping, but a lot of new designers and non-design colleagues wanted to code and make their own prototypes, but had no idea where to start. There was a desire to learn, but people felt intimidated and didn’t have the confidence to try.
We knew we could help, so we got to work – quickly putting together a rough training plan and inviting people to sign up. There were 15 people in the first class. We’ve since held 5 more, teaching at least 50 people the basics of prototyping.
Here are some of the things we’ve learnt in the process.
Go slow
Teaching prototyping and code to people with no experience is an interesting problem. It’s often an alien concept, so pacing is vital. We could cover everything in 1 session, but the content is so technical it could easily be overwhelming.
Instead, we split the training into 3 classes, each lasting 2 hours.
The first class is an introduction to the development environment. This is often the toughest thing to get your head around, but it’s the foundation of prototyping.
We then cover GitHub, version control and HTML. Just as important is what we leave out – the actual prototyping kit, command line and hosting. Just becoming comfortable with what you're doing and how it interacts with the web is enough at this stage.
We get to grips with the prototyping kit in the second class: how to run it and how to upload work and host it on Heroku, behind a username and password.
The third class is all about writing HTML and CSS. These are mentioned in the other classes, but participants told us they’d like a session dedicated to them.
Use common language and explain it
One of the main reasons we’re teaching prototyping is to reduce barriers between user centred design teams and developers. Developers use loads of language that’s sometimes hard to understand without context. We give people the context and also make a point of using the same language as developers, explaining terms as we go.
Create an environment for learning
When you’ve been doing something for a long time, it becomes second nature. It’s really easy to forget how daunting it can be for someone who’s trying something completely new.
Prototyping can be overwhelming if you’re new to it. We try to get the basics right – using the right language, at the right pace and making sure learning is accessible – and to create a supportive environment for learning. Without this, people are going to find it even harder to understand and learn new things.
Get the class size right and oversubscribe
This is a general training rule, but learn your optimal class size. After you’ve run training once, you should have a good idea. If the optimal class size is 10, make 15 places available. As a general rule of thumb, a third will cancel or not show up.
Final admin tip: doing this only in calendars quickly becomes unmanageable. Use something like Eventbrite to manage attendance. It makes life much easier.
Don't forget to practise
The first time we ran the training, we came up with a plan but hadn’t gone through it step by step before the session. This was a mistake. We found some things were out of order and that we weren’t quite as confident in certain areas as we thought.
Run your training through before you give it, step by step. This helps you identify any problems you might have, and which steps might be more difficult to understand.
Leave a comment