HCI 590 - Embodied Interaction
Many software development teams following the agile scrum method also hold daily "stand-up meetings." These meetings are meant to provide a short recap of everyone's current work tasks to the rest of the team. Although beneficial, many of these meetings lose effectiveness due to logistical mishaps and participant distraction.
To address these issues, I designed a ball-like "stand-up meeting timer" device that can be used to facilitate stand-up meetings. Its primary functions are to alert the team when stand-up is scheduled to begin and keep track of each participant's time limit. Initial prototypes, including a 3D-printed model, were evaluated with my coworkers. Initial usability and appropriateness of such a device proved to be extremely positive. Additional opportunities may include developing a companion app and fully functional prototypes. I believe this embodied interaction approach would be very beneficial in amplifying the effectiveness of daily stand-up meetings.
This project was launched with the purpose of solving a personal need at work. I've been a user experience designer at Rent Dynamics for almost 4 years. As part of the software development team, I've had the opportunity to participate very closely with the developers. Part of the team's agile scrum process includes a daily stand-up meeting. This meeting is meant to provide a short recap of everyone's current work tasks to the rest of the team. During this meeting, team members stand in a circle and take turns answering the following questions:
As our team's original plan, we decided to start the stand-up meeting at 10:00am every morning, regardless of how many people show up. We also decided to limit each person's turn to 30 seconds to create a sense of urgency and require succinctness in the discussion. This original plan, however, has degraded over time.
Correspondence takes place between a single person and the rest of the individuals in the group. At several points of the standup meeting, the transducers (eye contact, direction of speech, body language, hand signals) break down and create entanglement during the group interaction. In my personal experience and initial observations, these entanglements include:
I believe there to be a great opportunity for an embodied interaction solution for these pain points. This problem space guided my work on the final design of my project.
Jobs-to-be-Done
Enter the "Stand-Up Meeting Timer"
The stand-up meeting timer is a ball-like device that is meant to be used to facilitate meeting. Using a companion app, the user can program the start time of the meeting, the length of each person's turn, and any other appropriate settings. Five minutes before the start time (e.g. 9:55am), users will hear short alarm tone from the device to remind them to start preparing for stand-up. When stand-up is scheduled to start (e.g. 10:00am), the alarm will start playing. One person picks up the device and presses the "start" button. That person now has a set time limit (e.g. 30 seconds) to complete their turn of answering the three questions from above. The remaining time is displayed on the timer, with a sound being played if their time is exceeded. When they have finished, they will press the "next" button, and pass or toss it to the next person in the circle. When everyone has had a turn, the last person presses the "stop" button.
I believe this design addresses the most common problems identified above:
Prototype Iteration #1
When planning how to prototype my ideas, I originally intended to complete several medium-fidelity iterations before a high-fidelity model. However, I elected to develop a very low-fidelity model first as a proof-of-concept before doing further work. For this prototype, I taped my phone to a ball with the timer app loaded on the screen. This was intended to test functionality and the interaction of tossing/passing an object during the stand-up meeting, which my team has done on frequent occasions.
Prototype Iteration #2
Based on the feedback I received during the evaluation of my first prototype iteration, I sketched and later developed a 3D-printed model of the device. This was to test out the ergonomics of the device in a "Wizard-of-Oz" evaluation setting. At this point in the process, I was more concerned with people's interactions than I was with making the device functional. For the 3D model, I used Fusion 360 to design the parts in a manner that would be feasible to print on a 3D printer. I then used Cura to "slice" the model layers into a printer-readable format. My Ultimaker 2+ printer completed the print in a combined time of roughly 8 hours. It required four separate prints, with three color changes. I had to redesign the buttons and display so they would fit better into the model. I then super-glued the six pieces together to create a very nice and very sturdy model.
Evaluation of Prototype Iteration #1
To evaluate my first prototype iteration (phone taped to ball), I recruited two coworkers to test the product. I first explained the scenario of using such a device and asked them to use the timer app to keep track of their time. Although I received initial verbal feedback supporting the need of such a solution, the design and functionality of the low-fidelity prototype proved to be very troublesome. I believe my instructions made it difficult for the participants to accurately test the prototype. I attribute this to the prototype being "too low-fidelity." This led to my creation of the second high-fidelity prototype.
Evaluation of Prototype Iteration #2
My evaluation with the 3D-printed prototype went much better than the first evaluation. In this test, I recruited a couple of my coworkers. I was especially interested in the participants' interaction of handling the device. I used a "Wizard-of-Oz" setting to simulate the time limits and alarms. I believe the participants found it a lot easier to imagine the functionality in their minds compared to the first prototype iteration. Two of the participants stated how "awesome" it would be to have such a device in real-life. One of them was even willing to create a Kickstarter campaign to make it available to other development teams. The biggest qualitative feedback points were how the device could keep people within their time limit and keep them engaged in the meeting. The participants being able to hold a high-fidelity model in their hands played a significant role in the quality of the evaluation feedback.
Used as a method to review previous and current work tasks, the daily stand-up meeting is an integral part of many software development teams, as well as many other types of teams. A typical stand-up meeting includes gathering team members in a circle and giving each person a chance to answer a set of questions within a specific time limit. These questions include:
Just as any other meeting, the stand-up meeting format doesn't go without its own flaws. In my experience and initial observations, the success of stand-up meetings is faced with team members being late, distracted, interrupted, or all the above. Solving these issues is what guided my work on the development of this project.
To create a device that was meaningful and useful, I also needed to create something that wouldn't take away from the meeting or provide a further distraction. Taking an embodied interaction approach proved to be very beneficial to the experience.
First, to solve the issue of stand-up starting late, I included an alarm that would activate at the scheduled time. Second, to solve the issue of people going over their time limits, I included a display with remaining time and an alarm when that time is exceeded. Third, to help people know when it's their turn and encourage engaged listening, I designed the device in the form of a ball with a "next" button that could be passed or tossed to the next person.
To first test the concept of a passing/tossing interaction, I created a low-fidelity prototype as a phone attached to a ball. Initial evaluations with several coworkers showed promise in the "idea" of the product, but the execution of the first prototype proved to be flawed.
In my second prototype evaluation, I went the route of developing a high-fidelity model. I created a custom-designed 3D model and printed it using 3D-printing hardware. I then tested the prototype in a "Wizard-of-Oz" evaluation, and received very positive feedback on the ergonomics, purpose, and appropriateness of the device.
After initial impressions of the prototype, I'm more optimistic than ever that a stand-up meeting timer would not only be very useful, but also be a very lucrative business opportunity. I truly believe that the embodied interaction approach of this design solution makes it far superior to other methods.
I would love to continue work on this project to develop a complete, viable product. During this course, I did not have the opportunity to build out a fully-functional and fully-independent device. Additional work could include developing the internal electronics of the device, such as display, buttons, logic board, and speaker. The design of a companion app to manage the settings via Bluetooth would also need to be developed. Additional testing in real-world stand-up meetings would also be very beneficial to understanding the usability of the device and any recommended changes.
What was the greatest project challenge you needed to overcome?
What was the most surprising thing you discovered by doing the project?
What was the most enjoyable part of the project? The least enjoyable?
What is the most valuable lesson or take-away that you have gained from the project?
If you did the project over again, what would you change? What would you keep the same?
As I began working on this course project, it was very difficult for me to decide on a problem space needing an embodied interaction solution. What made the project really "click" for me was choosing something that I had passion for. The stand-up timer project was especially fun to work on because I've seen and lived the pain points almost every single day. It was great to finally open my mind to actually coming up with a real-world solution.
The most important lesson I learned was of the importance of prototyping and iteration. Many of my initial problems were solved by doing multiple evaluations. Although I wish I had done more, each time I created a prototype, I solved a real-world issue. It was great to be able to test out each function and see real people's faces light up. It's also very important to remember that each step of the iteration process doesn't need to be perfect. It's incredibly beneficial to explore different solutions, no matter how "ugly" or "imperfect" they are. All feedback is good feedback.
After the project was completed, I was very surprised by the initial demand for a stand-up meeting timer to be on the market. Had the solution been created using only a 2D mindset, such as just a phone app, I don't think it would have been nearly as impactful as an embodied interaction approach. In general, people use things to accomplish tasks -- and I believe that the physical world is more appealing to our senses than a flat screen. Moving forward, I'd love to explore business opportunities that revolve around developing embodied solutions.