Prototyping is a very important tool when it comes to designing new digital systems. As non-profits, reliant on members’ contributions, unions have to be careful to get the best returns out of any digital spend. Yet the costs for new digital development can run into thousands of pounds.
Building a prototype – the most basic version of your solution that you can test with real users – lets you check if you’re on the right track, and reduces the risk of costly project failures.
Here are two prototypes we developed as part of our young workers’ research project.
We had been working with young non-members in the private sector, and had developed a pretty good idea of how we could provide them with useful training content around careers topics, which was a very common need they expressed to us in interviews.
We wanted to see if we could move them on to thinking about improving conditions in their current jobs, not just longer term career plans. To do that, we needed to establish that they actually had some rights at work, and that many of the things we’d heard them tell us about work were unfair or even illegal – too many of them just believed their employer could do as they pleased.
However we had a hunch that employment rights based content would possibly have a different usage context from careers coaching. The successful “social stories” type format we had developed might not be appropriate for something which was more about reference resources.
We had asked earlier what kinds of content they liked to use for finding out new things. Two examples that had come back were around quizzes and chatbots.
So we ran a three way test using some content around holiday rights (a universally popular topic from our research). We wanted to put a normal social story format piece up against a quiz and a chatbot to see which performed better.
However, we knew we’d end up discarding two of the three formats – if not all of them. So we didn’t want to build anything into our app that would be a waste of development time. We had to find a way to develop lightweight prototypes for features that we didn’t yet have.
The hardest part for the quiz prototype was in phrasing employment rights questions in a way that could give tangible answers – so much in employment rights is more a case of “it depends” than yes or no. This meant that we kept it narrow in topic, so we didn’t need to call on too much time with our policy staff in checking we’d got it right.
We made a template in Google Slides that looked a bit like our app, with some of the page buttons you’d expect to see on a normal app. We then laid out the quiz questions and answers onto different slides in the deck.
We set the slideshow running on a phone and gave it to participants in 1-1 interviews, asking them to talk us through using it as they went and explain in a stream-of-consciousness way why they were clicking where they did.
We knew it would be tricky to make a version that correctly scored people’s answers, so we didn’t even bother. Anywhere a user clicked on the page simply moved it on to the next slide in the deck. The buttons were just dummy pictures on the page and the next page showed the screen for a right or wrong answer regardless of what they’d clicked.
We owned up to this fakery at the start, but still asked the participants to click where they would expect to. After a slide or two, they’d got into the swing of pretending it was a functional app and we had useful conversations around what they were seeing.
The chatbot prototype would also have been a huge effort to develop as a properly working product, so we used a “no code” prototyping tool specifically for conversational interfaces, called Botsociety.
It was really easy. You develop prototype chats to test with users by writing a series of text cards that are chained together in a WYSIWYG interface. Branching works like the logic jumps in survey tools like Typeform or Surveymonkey. Where a choice happens, you create a fork that can link to any other part of the script, either broadening out into different options or narrowing back into an original path again.
The bot had no natural language or search capabilities, but we didn’t need it at this stage. Showing the user something that felt enough like a service allowed us to have useful conversations about other ways they would expect to interact with it.
An important lesson for me was in going with the user voice. I found the quiz the hardest version to create out of all three prototypes, due to the mismatch between the content and the normal rules of the quiz format. I really hated the idea of doing more of those.
But the verdict from our 6 user tests was pretty clear. They all thought the social story format was okay but that it dragged for this kind of content. Half of them liked the chatbot better (giving us useful feedback on what might be an appropriate tone of voice for it). But all 6 of them said they loved the quiz.
In having conversations about the quiz prototype, we learned a useful lesson. It wasn’t so much about gamifying it or getting validation by receiving a score, as we had expected to hear from our initial hunch. Several of our users clearly said that breaking the content up into questions that they had to pause and think about helped them to reset their attention on every other page, when they would otherwise have zoned out long before.
Of course, prototypes can be even more basic than this. Showing someone paper mock ups of screens (even asking them to click on the paper and showing them another sheet to reveal their result) can be enough to get users to better visualise how the idea you’re testing could be a real service for them. By giving them an example to work from, you can then talk to them about how they would expect the actual service to work.
And on the other side, there are also specialist tools designed to make this process smoother. MarvelApp, which lets you build interactive interface prototypes, and its feature POP app lets you photograph paper designs and link them together through hotspots to give the impression of a working application. If your union has a design team using Adobe, they might like to check out Adobe XD, which is another quick prototype building tool for paper or on screen testing.
The idea of prototyping is strongly related to a number of our digital design principles for unions, particularly starting from users and developing in small steps. You can check out the full list of 8 principles here.