Paper Prototyping a feature for Microsoft Teams
Following on from User Research and Usability testing on Microsoft Teams.
Initial Prototype Development
Now that we had agreed on a user statement, and thus the core focus of the design stage of our project, we decided that a good way to approach the problem would be for us to each come up with a solution, which we could compare and contrast as a group. This would allow for our solutions to be more varied, and again let us see if there were commonalities between them that might indicate a particularly obvious or simple final flow.
armed with our user statement we each created a paper prototype, and digitalized them, so that we could share them with each other and test users.
As a teacher I need to know if my students are engaged and need tools to keep them engaged, so I can effectively teach them and manage my class
Our user needs statement
here is my individual paper prototype.
The initial finding from our prototypes was that three of the four solutions had a lot in common: Some kind of polling tool that would allow a teacher to ask a multiple choice question of an entire class, and be clearly presented with collated results — our hope being that having students answer a question in this manner would both reassure the teacher that their class was engaged and also allow the students to feel more involved and thus engage more actively with class.
We proceeded with the prototype designed by Josh. This solution involved the teacher creating a poll (the common thread in our prototypes), but expanded on it with a follow up flow that would allow the teacher to randomly select a student who had answered to elaborate on their answer. We chose this flow to develop further as it referred back to the problem statement best — not just to gauge engagement but to actively engage them in discussion.
This is what the first iteration of the prototype looked like:
and here are the ‘as is’ and ‘to be’ task analyses of this flow, documenting what is currently offered by teams and how we built upon it.
We then developed a script as a group so that we could standardize our testing and gather comparable results that we could action and expand on for the next iteration of the prototype.
We each took the script and online clickable prototype and had the users we had conducted the interviews on test out the paper prototype, so that we could gauge their opinion.
Reflections
The main negative of this process, or our execution of it was the digitalisation of paper prototypes. A lot of the inherent benefits of paper prototyping comes from how fast they are to put together, modify and iterate over, but as we turned them into clickable prototypes the work involved rose rapidly, meaning that they were taking longer to make and iterate over than a low fi wireframe made entirely on a computer would have.
The reason we did this though was to maintain the low fidelity look and feel of paper prototypes, as this would encourage our users to be honest in their appraisals and more willing to be critical.
