Celebrations, Summer, and Some More Sprints
Ending Spring Semester
Before we knew it, it was presentation day.
We were the first capstone team to present our findings from the work we had done in the last 14 weeks. Prior to the presentation, we had been iterating on our slides after asking for critique on elements such as audience engagement, the use of evidence, the hook, and our presentation skills as a whole.
Our first official run-through was tough. The deck was too long, too dense, and too hard to follow. Our faculty advisors gave us a vivid analogy:
“This presentation is like a block of marble. We have to chip away at it to reveal the statue inside.”
Our presentation had great insights and research, we just had to remove the extra material around it to present the core of our findings. By this point, we had our work cut out for us.
Less than a week out from presentation day, we did another run through with our advisors. We had asked for more feedback; it was better but still not quite polished. The hook wasn’t meaningful, there were too many block quotes, and we were too stiff. We did yet another big revision before we started full rehearsal. Nearly 15 hours were spent on full rehearsal leading up to the presentation, beyond each member’s commitment to rehearsing their lines on their own too.
During our Capstone course, we learned that presentations are like choreography. Keeping that notion in mind, we choreographed transitions, the tone of our voice, pacing, audience engagement, and more.
The presentation came along, and our hard work had paid off.
As for the next two weeks, we were wrapping up our final deliverables, attending peer presentations, and celebrated our team at commencement. Go team!
Getting Things Back up and Running
Following commencement, Sprint 6 had begun and we hit the ground running. Planning faculty and client meetings, revisiting our old prototypes, and reflecting on Spring semester were first.
In the shorter Summer session, our time commitment doubles. We are essentially working at about 3x the speed we were in Spring. 40 hour work weeks have become the norm, and Monday.com has become our newest team member.
Last semester, we were content with our use of Google Docs to delegate tasks, but the intensity of this session was also a major factor in our decision to use a project management tool. Additionally, being able to use a tool such as Monday.com helps us demonstrate our commitment to effective project management, and it is reflective of current industry practice.
The use of a PM tool such as Monday.com encourages the team to follow through with processes such as the Google Ventures (GV) Sprint. Small, digestible tasks are assigned throughout the work week to contribute to creating and testing prototypes rapidly. We found that the GV sprint works well for our team in the summer, as we have more time and commitment to the project.
Unpacking Problems Help Reveal Assumptions
Our first deliverable of this session was to submit prototypes. Naturally, our group thought a rapid idea generation session with our faculty advisors would be a good starting point.
We developed prompts that were based on the insights from last semester and asked our advisors: How might we build a documentation process to facilitate structured data in the system and help handover? At the time, we thought this was the how might we statement of the year! As soon as we read it aloud, it was hard for any of us to really explain what we meant. So, we went back and unpacked our insights. By this, we asked ourselves “why?” for each insight. Why is there a documentation problem? Why is troubleshooting a guessing game? Why don’t facility managers want to monitor sensor health? You get the picture.
After asking a bunch of whys and mapping out a problem space for each insight, we had uncovered a few assumptions that we were making about the domain.
For example, we had realized that we weren’t sure what exactly was the reason that was making documentation so difficult, but we had made the assumption that sensor addresses were confusing to understand. Lo and behold, after talking to some people in the facilities management services office (again), we quickly realized that the coding used to assign sensors unique addresses is fairly easy to understand for experts in the field, but not so much for MHCI students. This example highlights how there is still more to learn and test, so we turn to prototyping to test our riskiest assumptions and ideas.
Prototyping, Again
As previously mentioned, our first assignment in the Summer session was to create prototypes. With the time deadline, we went on to make a series of low-fidelity digital prototypes to turn in. Upon our first critique of our prototypes in class, we soon realized that our developments were really drafts of designs we were thinking of doing, instead of concrete ways to test our concepts.
In that sense, we came back to the drawing board and are currently trying to make our prototypes test our riskiest assumptions and to quantify the human experience. We aim to potentially do this using factors such as speed, number of clicks, or developing a satisfaction score. We are still ideating on this section, but look forward to having more quantitative data so we can prove the statistical significance of our designs as well.
Moving Forward
Looking ahead, we aim to continue iterating on our prototypes and use them as a tool to test our assumptions rather than confirm our beliefs. Research doesn’t stop in the summer, but it should not be a deterrent to us developing and designing. We look forward to what the next few months have in store for us!
The work and knowledge gained from this project are only intended to be applicable to the company and context involved and there is no suggestion or indication that it may be useful or applicable to others. This project was conducted for educational purposes and is not intended to contribute to generalizable knowledge.
