What shall we do with the IT Apprentices?

I was recently asked at short notice if there was anything I had on which could be usefully shared with our group of IT apprentices - a group of young people who've been moving around different parts of the digital and technology services department where I work, getting a flavour for the different areas within the broad field which people like to call 'IT'.

Most of my development work is work which is hard to include other members of my own (current and historic) teams, never mind work which can be readily shared with people who are at the beginning of their careers of acquiring knowledge and skills. And of this group of apprentices, not all of them are actually even interested in development.

My immediate thought was maybe they could do something with Figma - when I first played with it it was relatively easy to just go straight in there and build basic wireframe designs and interactions without needing to spend time looking for a tutorial or reading a manual.

But what to actually have them do with Figma?

And then an idea came to me of a half-formed idea I'd had ages ago about a potential in-person exercise to do with a UX and Content Design team, should I ever in the future being in the position of needing to do an engaging team exercise which justifies the overhead of bringing everybody together for an in-person team meeting:

A kanban board with three columns - Settings, Scenarios, and Outcomes which win the game. Cards under Settings include Birmingham city centre, cards under Scenarios include The player is the custodian of a certain area, and cards under Outcomes include Ozzy comes to life

The half-formed idea I'd had ages ago was that creating some kind of Figma-based game set on the council website might be fun; the idea when I half formed it was the use of Figma was less about actually designing wireframes in a wireframe tool, and more about it being a way in which users new to Figma might get to grips with how it works outside of its usual context, together with having the members of the team go on a dérive through the site to give them a fresh perspective on the content they are responsible for.

But beyond 'making some kind of game' I'd not yet got any further in my thinking as to what kind of game, and how it might be a worthwhile activity.

Fast forward to a few days ago when I was asked if I had any ideas for something which could be useful for the apprentices to do, which acknowledges that their programming knowledge is probably limited and indeed what knowledge they will have is not necessarily shared across the group, and we know not all of them are even interested in development as a career, and I realised, I don't actually need to come up with a game to make this idea work, I can set coming up with the game as part of the task!

So, the assignment I set them in their morning stand-up on the Thursday was:

Create a Choose Your Own Adventure / interactive story.

First of all on Monday morning we'll brainstorm some settings and scenarios for an interactive online story you'll create - it could be set in Birmingham somewhere where you go from shop to shop, it could be a council adventure where one of the zookeepers at the Nature Centre is having a bit of a day, or it could be an entirely fictional setting. From overall location and setting you'll think about specific locations within the setting the the player might have to travel through during the game, and whether there might be objects you might need to pick up and use later. After that you'll create a map - a physical map of the locations and how the relate to each other, and a logical map of the decisions the player might make as they move from place to place, and what the consequences of those decisions might be.

You'll also create some kind of narrative for the story - what has the player been dropped into at the beginning of the game? What is the player's goal in getting to the end of the game? What does success look like for the player, what are the failures which might end the game unsuccessfully? Don't just build a world by telling the player eg that they have just got off the train at New Street Station, build the world by telling the player what the weather is like, how crowded the train was, whether the busker they just walked past was any good, etc. You will test your designs with potential players of the game and adapt to constructive feedback from them.

Once you've done that, you'll then build the adventure in Figma - Figma is one of the ubiquitous tools that User Experience and User Interface designers use to build interactive wireframes of digital products. The purpose of a wireframe is to enable the designer to design a screen layout and the interactions in what's called 'low fidelity' - ie, boring-looking - as plain simple boxes and buttons on the screen so that when the design is being iterated and tested, test subjects focus on the purity of the layout and whether it works or doesn't work, rather then being distracted by a banner being the wrong shade of green for their tastes or being offended by a picture of a building in the city which is their least favourite building. In the olden days designers would draw these as simple plain boxes on a piece of paper or in Photoshop, but the advantage of Figma is you can actually make the design interactive, you can build in buttons to click which will take you from screen to screen. It's also reasonably easy to pick up and learn how to use it.

After you've built your adventure in Figma, which will exist on the Figma website for other people to play with, there will then be the option for you to actually turn the working wireframe of the adventure into something rich and graphical with actual real html, css, and javascript code as well as finding and/or creating images to support the adventure.

The learning outcomes for this task are

  • learning how a real digital start-up company might conceive a product,
  • collaborate on fleshing out the features of the product,
  • creating the physical and logical designs of how the product might work,
  • having regular check-in meetings to track progress, and
  • building working prototypes of the product to test with potential users and making changes based on feedback.

You will also learn how to make changes based on how decisions you might make at the design stage turn out to be unhelpful when it comes to the implementation stage - this is where the design->build->test->feedback->design iteration loop of the iterative design process comes in.

You can create your own Figma account to start playing with the tool, and you can spend the weekend to be thinking about possible settings and scenarios in advance of the initial brainstorm on Monday.