Productivity Bot

Making group video calls more productive and dynamic



Role: Interaction Designer & User Researcher
Duration: November–December 2020 (1 month)
Team: Thomas BruhnEleanora ToscanoAnqi Yang
Link: Web prototype, Git repo


The Problem 😓

How might we encourage students to be more productive and proactive in group video calls?


We employed the design thinking process to quickly deliver an MVP in just one month. Given that our time constraints also included development time, we chose to focus on one to two key design methods for each phase.


The Empathise Phase 🤔



We devised a user research plan that involved identifying our target users as well as eight hour-long story interviews. We interviewed five male and three female Master students ranging from 20 to 28 whom were studying remotely due to Covid-19.

After our interviews, we noted down and grouped numerous observations and findings so as to map a positioning matrix of our interviewees’ teamwork profiles based on:

  • Organisational passiveness/activeness: How (in)active the interviewee is regarding organising the team and the project in group meetings.

  • Social/work-oriented: How much the interviewee prioritises working or socialising in group meetings.


The Define Phase 📉


After positioning our interviewees, we were able to identify three personas. In response to this project’s particular time constraints, we decided to create condensed personas; we listed nine characteristics per persona, as well as established demographic information such as age, gender and occupation.



We noted down various aspects of the breakdowns we individually identified in the story interviews we each performed. After discussing them and grouping them together, we were able to identify several sub-research questions that helped us further refine the scope of the problem for ideation.


The Ideate Phase 🤔



We individually and collectively brainstormed potential solutions  overall several sessions. Afterwards, we voted for the idea we thought best answered the overall and sub-research questions, allowing us to narrow our scope to something more feasible. We then individually sketched our ideas on paper.



The Prototype Phase 💭


Upon coming together and discussing the ideas we came up with, we created a barebones conceptual model of a Wizard of Oz prototype. This prototype simply consisted of a background image with instructions that users could invoke in the video conference chat.

During this phase, we also simultaneously started to plan the web-based prototype, its functionality, and interface for the sake of time.


The Wizard of Oz Test Phase 💡


We conducted two Wizard of Oz tests: one with a “moving” robot and one without. We sat in on two real group meetings of students in our university who were unaffiliated with the class. We decided to conduct these so as to test which functionalities were used by users and how.

For both tests, we had one team member introduce the bot, one to observe and write notes, and finally myself as the robot handler. For the test with the webcam, I acted as the robot, anonymised by placing a paper bag over my head.

Our tests helped us identify the key flaws in our conceptual model, enabling us to redesign it for the web-based prototype. Changes included moving from text-based input to button-based input and introducing a jingle to announce that the robot was about to speak, rather than abruptly cut conversation.


The Develop Phase 🤖



Thomas and Eleanora developed a web app using Node.js, JavaScript and HTML/CSS. It uses a server/client structure, whereby a user (client) invokes a command that is sent to the bot (server), which in turn sends a message back to all the users.

I prerecorded audio and names according to the concept video we created to demonstrate the functionality of our MVP. Finally, I compiled and edited all of the footage to develop the video.


The Three Takeaways 🌟
  1. When constrained on time, it’s better to employ one or two design methods well, than to do many poorly.

  2. Knowing when to diverge and converge workload among the team (as individuals, as pairs or as a whole team) can save time, encourage diverse ideas and balance stress.

  3. An initial prototype doesn’t have to take a lot of time or effort to produce invaluable results!