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 in, never mind work which can be readily shared with people who are at the beginning of their careers of acquiring knowledge and skills.
My immediate thought was maybe they could do something with Figma - when I first played with the tool I found it 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 exercise which might be done with a UX and Content Design team, which might be an engaging team exercise which justifies the overhead of bringing everybody together for an in-person team meeting:
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 I half had back then with using 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! And also, the task itself is about using transportable skills of planning, research, design, implementation, and iteration which are valuable across the wide gamut of IT, not just Development.
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 shall brainstorm some settings and scenarios for an interactive online story you'll create - it could be set in Birmingham, it could be 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.
Setting and Scenario
From overall location and scenario you'll think about specific locations within the setting that 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 they 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.
Narrative and Outcomes
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. You will also conduct research about your setting, eg speaking to any Subject Matter Experts related to the game you're building.
Initial build
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.
Further iterations
You'll then do further iterative testing and refining with potential players, adapting the game according to their feedback, and indeed adapting to change any decisions you made early on which don't work so well on actually starting to bring it to life.
Deployment to production
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.
Learning outcomes
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
- learning how to use Figma to build 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".
The finished work
You can see their finished work at Pigeon Park: Last Roost and Cyber Punks.
