Week Seven found the team exploring operational ideas, and dealing with the resulting chaos.
On the suggestion of our client, we started to dig deeply into how Toast Master would exist in, and interact with, the physical world. By drafting out our ideal use of the physical space, and outlining the guest journey from entering the area to successfully retrieving their drink, we began to see how the whole experience might take shape. The good news was that we now had a better understanding of how our interaction would work. The difficult news, but still beneficial for design, was starting to understand the holes and impracticality of our initial plans. While our over-all experience withstood the test, our details were thrown into disarray.
This high-level/low-level split was made even more clear by time spent with visiting professional Anthony Daniels. As someone who had had nearly no exposure to our project until the moment he walked into the room, Mr. Daniels was an excellent proxy for a naive guest. Speaking through our interaction with him was eye-opening. The two things it became apparent that we needed to clarify were why Toast Master was a preferable experience to just going to a human bartender, and what the button of our experience would be. He also provided a good amount of insight over the fact that even though our experience is focused on cocktails, the end goal is the human interaction.
Examining our design ideas also made us examine our ideas of a functional pipeline. Much of the work this semester has been done in parallel, in an attempt to save time. However, looking at what has been done and what still needs to be done, the team has reached the conclusion that trying to do everything at once is only leading to muddy results and conflicting processes. Our new approach is going to be a more inside-out design. Programming will have less constraints on the content that they’re using, and more freedom to do what they need to to get the architecture up and running. Design will carry foreword with paper prototypes, allowing the content to be rapidly prototyped without bogging down the programming team. Once both sides have a firm idea of what they want to do, we’ll begin bridging the gaps between the two, making sure that the experience fits the technology, and that the tech best serves the design.
This choice is showing immediate dividends. With a single sample interaction to focus on, programming now nearly has a complete system up and running. The exact interaction is far from polished, but that’s not what’s important at the moment. This basic interaction serves as a proof of concept that we can interact with the software in the way we want to.
Without the need to worry about selecting specific data to be used, design’s focus shifted towards an issue that came up while considering operational issues: Toast Master was functioning both as facilitator and gatekeeper. To facilitate well, it required an engaged conversation. But, to be able get drinks quickly, the requirements shifted to speed and efficiency. Coming back to the idea of pulling on human interaction, design has shifted focus on the experience to facilitate conversations about AI. While drinks are the vocabulary we’re using to start that conversation, they shouldn’t be where our focus lays.
Research continues to try and find the best interaction between the hardware and guests. We’ve begun testing Assistant’s ability to pick up voice in noisy environments, seeing how we might be able to incorporate Toast Master directly into the dining environment. We’ve conducted further interviews leading us with case studies for us to base personas on, and we’ve begun paper prototyping the dialogue as well.
With Halves only nine days away, we need to start focusing on our Alpha build. While Halves tends to be process focused, we need to show that our idea has merit and can be delivered on is vital. With an operational prototype on schedule for Monday, we’re going to need to test and iterate quickly to make sure we can justify our choices.
