Creating the Scenario Flows
Last updated
Last updated
Used Research Methods:
Relevant Research Questions:
What technological solution at the Fontys Strijp TQ building can be used to stimulate the productive feel of the building users?
The first component I needed to create was the scenario flows of the way the buddy should work on the top level. Based on the general concept discussed in the previous chapter, the following scenario could be created (see image). A group is working and for some reason (noise or time has ended), the buddy needs to recharge. They put it to charge and then when ready, the group goes back to work, both the buddy and the group "feel recharged". The process repeats many times during the day.
The explained scenario is showing the general stages of creating the interaction loop. However, I did not know yet what happens in between those stages. What happens if the group does not go to the charging station? How does the buddy know if it is at the station or at the work table? When is the buddy charged? Is sound always tracked? Because of uncertainties like those I needed to create more in-depth flows so that it is clear at every moment what is happening with the buddy and the charging station.
I created scenario flows that were based on the storyboard. In those scenarios, I was tracking the buddy's state (has to charge, time running, and charged) and the state of the soundtracking (soundtracking off, soundtracking on - good, soundtracking on - too loud). The general flow (see image) is explaining the flow when the group uses the timed feature. The group sets the time to work (they are at their working table already) and by picking a working time, the buddy's time starts counting down and the soundtracking is on. After 20 (desired time in this scenario) minutes, the group is alerted that the buddy is too tired and needs a recharge and in an ideal situation the group goes to charge it. The soundtracking is still on even though the group is not working. At the station, the buddy is charging and the soundtracking is off (the social area is a good place for the students to be louder). After the buddy is charged, the group picks it up from the station and the soundtracking is again on. The group goes to the table and starts a new timer. The flow repeats.
However, a group could be in the flow when a break is triggered, that is why a variation with a five-minute dismiss was created to enable the groups to wrap up. The dismissal could be repeatedly chosen.
The above-mentioned scenarios were happening in case the group did not become too loud. However, part of the concept was to cover the situations when the users are too loud and the buddy gets tired faster because of the noise that the group is making. It is worth mentioning that the group needs to have multiple noise alerts (red spikes on the image) over a specific timeframe so that the preliminary break is suggested. A preliminary break cannot be dismissed.
There were other scenarios covered such as unlimited working time, standup mode, chronometer, etc. However, those scenarios were not having such a high priority so the ideas were noted but were never developed. To see all versions of the flows go to Scenario Flows
As the main flows were made, I created a basic paper prototype of the above-mentioned flows. The prototype setup were including two groups who were instructed about the prototype and had a timer phone with a sound recording level put on. The groups did the 25 minutes timed version so that the test could be time-framed and more manageable to perform. The groups were working on their daily tasks while the test was made. I, as a test conductor was performing Wizard Of Oz to time the tests and go to the tables to give noise or break alerts. The groups went through two work iterations with one break in between. At the end of the test, we had a discussion of their thoughts on the experience.
In iteration one, the group was having multiple time dismisses. On the second, however, they were too loud which meant that I had to preliminary ask them to take a break (after giving them a few noise alerts)
Because of the multiple dismisses on iteration 1, the group mentioned they would prefer if the dismissal were not 5 minutes but a time they could pick in order to not dismiss so often. Therefore the flow was updated to the version in the image below:
Except for that correction, the flows were well accepted by the users and they found the concept quite interesting. Moreover, they could see the time pressure boosted their motivation to work for a short time so that they can have a break after.
As I was tacking noise I was expecting that I would be able to see at what times the noise levels were higher on the device and compare them to my notes during the test (as I was observing my test groups and noting times when they were loud in my opinion). However, not having the sound recording and only the noise level it was too hard to determine if the sound spike was an actual noise or a minor bump on the table (that apparently leads to quite high spikes even though they are not loud to the human ear).
Overall the prototype was very well accepted. People did not want too big engagement at the charging station for now but gave good suggestions of score points and other motivational rewards for the future. The users also shared their ideas for a hardware design, which surprisingly was completely in the same direction as my concept. First Concepts and Design Challenge Redefinition
The results of the test were shared with my client. Therefore as my client has professional experience with sound design, he suggested collaborating with me on the project as an expert and supporting me on the soundtracking in part, so that I can focus on the overall flow of the experience.
As the main scenarios were determined it was time to decide on the flows of user interaction so that the user could perform the steps to set their own timer.
Workshop: Prototyping, Lab: Wizard of Oz
Showroom: Co-Reflection
