Amber Rockwood (amberr)
Kay Christensen (kayc)
Bowen Pan (bowenpan)

Amber is graduating with a B.S. in Symbolic Systems with a concentration in Human-Computer Interaction. She likes to build user interfaces, and will soon do so professionally (although likely none so colorful in character as Dynamixx).
Bowen is a tech entrepreneur and a product geek from New Zealand. He's a second year MBA student at the GSB and will be joining Facebook as a product manager in July.
Kay is a masters candidate in Stanford's Learning, Design and Technology program. She focuses on informal learning in adult populations, user research and UX, and emergent learning technologies. Dynamixx was the most fun project she's worked on this year.

Team Formation and Ideating

  • Treasurebox

    Treasurebox is a safekeep of your best group memories. After that amazing sailing trip, study abroad experience, or college days of living in a communal, people often have a lot of stories, quotes, photos and other “inside jokes” that instantly conjures up great memories. Treasurebox allows these group of users with the shared experience to store those memories. Our target users will be individuals who has participated in shared group experiences. The two main use cases are impressive experiences such as trips/study abroads and communal living. Features of Treasurebox might include:
    • Ability to store moments of quotes, keywords, stories, and other “inside jokes” as well as associate photos/video with those stories.
    • Allow multiple users to collaborate and add to these collection of moments.
    • Allows users to leave comments and chat in real time about their shared experiences.
    • Pushes notification that selectively brings up moments in the past.
  • Time Capsule

    A time capsule app would permit users to leave messages, images, or other media for someone else to find at a specific location. The sender might have to be present at the location to leave a message, or we could offer them the ability to set a capsule’s location remotely.If it required presence, this might be more meaningful for the recipient, as it indicates that the sender put more thought into planning the capsule and might create a sense of copresence across time. In any case, the only way for the recipient to receive the message is by arriving at a particular location. Time capsules could be between strangers (a note left for anyone to find) or between close friends (only specified recipients can “see” the note). Thus, the target users could be either lonely strangers or close friends/couples. Between strangers, this idea would address a need for low-risk meaningful contact with strangers--the communication is not mandatory, and no conversation is necessary. It simply provides a glimpse into a stranger’s day. Between close friends or couples, it satisfies a need for copresence when it isn’t always possible--for example, a college couple that visits the library at different times of day. The degree of planning required and its asynchronicity also makes it meaningful and special.
  • Sexual Sensation Communication (2 Related Possibilites)

    1. Targeted at sex partners who are not co-located, this app would allow one or all individuals to communicate by manipulating each others’ sex toys. The primary source of communication would be tactile (e.g. vibrations, pulses, temperature and/or direction). Users can also send brief video and/or audio clips to the sex toy devices to enrich the experience for all.
    2. Made for the BDSM community, this app would provide users with different modes of communication depending on their role and particular kinks. For instance, dominant partners may send tactile sensations (vibrations or uncomfortable shocks), video, and audio, and may also control the settings of the submissive partner. Submissive partners default to audio communication but can be given video and tactile modes by the dominant partner. Partners who switch roles default to all modes of communication but can change their settings appropriately. There may be an arduino-based BLE hardware component to this app.

Storyboarding and Skit

Based on feedback about our initial ideas, we're scrapping Treasurebox and Time Capsule. Below are descriptions for the two new ideas that we've expanded into storyboards.

  • Improv Booth

    ImprovBooth is a video person-to-person application that lets users adopt and play out new roles, thus opening up opportunities for more honest and enthusiastic communication. The roles are assigned at sign in, either randomly given to both parties, or chosen by the communication initiator. Users will be able to adorn their video stream with costumes and may be given initial hints for speech, accents, or key phrases that they can adopt to ease into their assigned roles.
  • Interactive Meetup in a Shared Setting (#carnivalcutout #scene)

    Key in this application is that users can virtually place their avatars (animated bodies with faces populated by live video) in a setting with other users’ avatars, and that they can use gestures to interact with other avatars and items in the scene (such as a dining room, office desk, the Mushroom Kingdom, or Star Wars). Decrease a user’s volume by shrinking his avatar; drop him from a call by swiping away his avatar; pass someone a note by generating a note within the app and sticking it on his head! There are many possibilities for what scenes and items could be offered, but the items in the scene allow users to affect the other users' experiences as they would in real life.




Wizard-of-Oz Testing

Functional Prototype I

UI Mocks:
The prototype is at dynamixx.herokuapp.com. A few notes on the current implementation:
  • The first person to visit the site is assumed to be the dominant partner/the partner in control.
  • To allow their partner to join, they just need to send the url + assigned hash to their partner.
  • Video/audio currently needs to be enabled for both partners in order for text chat to take place.
  • The prototype also assumes the submissive partner/controlled partner has the hardware device we developed.
Design decisions:

Our first prototype followed the direction of our initial needfinding and use tests, which confirmed that a kink community was very interested in extending its play to scenarios in which partners weren’t in the same location. Still, additional feedback caused us to consider some of our users who did not identify with the kink scene, but who were nonetheless interested in feeling sensations sent by their partners across distances.

As an example, User A in our initial test discussed the fact that he had had several longterm relationships, but that only one of them had not been long-distance. Though not experienced in “kink,” he considered himself a specialist in intimate communication across distances and was interested in how an app that generated tactile feedback could round out intimacy between couples.

Thus, we pivoted slightly to make Dynamixx an app that lets couples explore many aspects of communication play, including tactile, across distance. Dynamixx Prototype 1 includes the following features:

Control feature: the person who initiates the communication is given the option to grant or rescind video and audio for the second person, thus enabling users to explore exciting and perhaps unfamiliar power dynamics during their chats. We believe that allowing for such a power dynamic could inspire more honest and certainly more creative communication between familiar parties. Each user has a permanent chat box so that communication cannot be entirely removed from either party.

Hardware control feature: the controlling party may activate the tactile hardware from his/her app. We chose asymmetrical use for the tactile portion because 1) it was simply more realistic for one person from a couple to have shared hardware than for both parties to have it, 2) it could amplify the unequal dynamic between the two parties, and 3) it was more akin to real life, in which interactions (such as neck massages or hugs) are often initiated by one person and received by another.

Tactile feature: the second user owns the tactile hardware and can clip it to almost anywhere on his or her body or clothing that she wishes. We chose to make the hardware vibrate (battery-operated motors) to come close to a purring or general biological movement sensation, and twist inward to simulate a squeezing or kneading sensation. These two movements give the user many choices of simulated tactile sensations depending on where the hardware is placed: it can move from simple tugging on a jacket to massage to erotic stimulation.

Prototype 2 Plans

Our plans for Prototype 2, though solidified following our additional user tests, currently include the following:

  • Create second hardware prototype with smaller form factor, so that it can be transported and worn easily. Ideally, use a quieter power source so that the tactile portion is less likely to interrupt other communication types.
  • Add a “backstage” feature to the app to let more extreme users experience darker interactions when they wish.
  • Alter stylesheets according to user feedback.

User Study I

Introduction: Describe your motivation and goals. Note your driving questions and hypotheses.

We designed our initial prototype to serve a very specific, quite underrepresented user group. Many thousands of adults in the Bay Area and beyond are involved in consensual BDSM (Bondage, Discipline, Sadism, Masochism) sexual play of many varieties. One ilk, which explores one partner delivering interesting or arousing sensations to another, is extremely widely practiced among our user group. Thus, we set out to design a social communication app that would help users of this group continue their practices even while partners were apart.

Our primary goal was to make design decisions that--as best as possible--transferred the critical portions of sensation play interactions into a format that could be delivered virtually but convincingly. Most BDSM encounters involve an extremely well-structured arc of negotiation, play scene, and aftercare between participants; likewise, most interactions involve the discussion of safe practices and safe communication facilitated by “safe words” or keywords such as “yellow [slow]” or “red [stop].” Given the importance of incorporating these practices into our design, the use test for our initial prototype explores the following questions:

  1. Which portions of the application create the potential for a realistic interaction between partners?
  2. Which portions of the application facilitate a pleasant or satisfying interaction between partners?
  3. To what extent does the hardware facilitate an effective application of dominance by one partner?
  4. What should be changed to allow for a more effective “negotiation” of practices between partners?
  5. What should be changed to allow for a more realistic or satisfactory “scene”?
  6. What should be changed to allow for a more realistic or effective “aftercare” session?

Methods: Describe your study design and tasks. Whom did you recruit and how did you recruit them?

Our first round of user tests will be lab situated so as to minimize potential difficulties with the technical portions of our device. We plan to complete a deploy-in-environment test with a larger group of users after making refinements to the device.

We have amended a use test consent form and a recording consent form to give in duplicate to all users. Any recordings made will the result of consent by users, and all will be stored on a single local machine under a secure password and destroyed no later than 3 weeks after collection. To protect user identities, we will refer to users by number, and all photos collected will have faces and identifying features obscured.

After the researcher helps User B set up the hardware portion, she will leave the room and allow the users to deploy the test, completing at least the following tasks:

User A

  • Request control of tactile hardware.
  • Request control of partner’s video.
  • Request control of partner’s audio.
  • Turn partner’s video off and back on.
  • Turn partner’s audio off and back on.
  • Toggle the tactile hardware off and on.
  • Click the Re-Negotiate button.
  • Use the chat to send and receive messages.

User B (hardware enabled)

  • Put the hardware on in a place that feels comfortable.
  • Grant control of tactile hardware.
  • Grant control of your video.
  • Request control of your audio.
  • Click the SLOW button.
  • Click the STOP button.
  • Click the Re-Negotiate button.
  • Use the chat to send and receive messages.

Finally, the users will be directed to a survey that will collect their feedback on experience, design, and realism questions. The test will then be ended.

We recruited representative BDSM practitioners from Kardinal Kink, a Stanford group attempting to gain full club status on campus, and members of Mission Control, a social kink practice club in the San Francisco Bay area. Given the sensitive subject matter, we recruited via word of mouth by contacting the president of Kardinal Kink and vocal members of Mission Control, who then helped recruit trustworthy other users. Users have various degrees of experience in the BDSM scene and have various preferences and roles within the scene.

Results: Describe your data and present the results of data analysis (observations, statistics, charts, etc).

Our data comes from six users with a spectrum of involvement in kink groups--some heavily involved in more than one group, and others with friends or partners in kink scenes. More than half of them had interactive walkthroughs of Dynamixx and were then interviewed about the app. The data is from these semi-structured interviews and the participant observations that were possible.

Target population is unacknowledged

“It’s definitely an underserved area.” - U1a “Truth.” - U1b
“There’s nothing like this. This is the first kinky app we’ve seen.” - U1b
“Oh! This is for me! Instead of ‘this is something I can work with.’” - U1b

These quotations from two testers involved in a university recognized kink club sum up their frustration that few sexual tools are really designed for populations with unique use cases, such as extreme power asymmetry and pain generation. User U1b compared Dynamixx to her typical Skype-based sexual interactions (Skype has “not much in the way of UI to add to the scene”) and said that Dynamixx is “super interesting and will definitely cater to the sorts of experiences that I want to have long-distance.” U1a added that she also engages in text-based role play and that it “would be augmented by the tactile component” in Dynamixx. Both users’ body language--handling the hardware, testing it on fingers, playing with video and audio components--indicated that they were excited by the software and eager to find out how it worked. U1b even simulated a 2-minute scene with herself playing both parts.

“This is important.” - U2b
“People will use this.” - U3b

Even users, including the two quoted above, not directly involved in kink groups echoed the feeling that the app would fill a recognized need.

UI is weightier than hardware… unless hardware has a lot of options

“Focus on the UI and what you can do in the software, and market the hardware as an add-on.” - U1b
“How many features it has influences how many people will use it.” - U1a
“As long as you are able to create a sensation that there’s a dynamic, that should be its thing.” - U1b

One of our assumptions was that the physical component of Dynamixx was the feature that differentiated it from everything else. In truth, the interface and core functionality drive users’ interactions as long as the hardware portion is limited to one or two functions. Interchangeable hardware would be preferable. “You’d need some pretty cool devices to make it really… you know,” indicated U4a, who was clearly less enthused with the hardware than the software; he touched the hardware only once during his test.

Needs more scaffolding or messaging to be intuitive and therefore realistic

“What does this Start button do? What does Re-Negotiate do? Aw, maaaan!” - U4a
“And wait, I don’t have the option to rescind control?.... I would like to know that going in.” - U3b

Users pounced on the chat box within milliseconds, but they took more time to click on additional features such as the control step buttons and the SLOW and STOP buttons; they likewise had more questions about what happened after these actions. U4a even sat for more than a minute after clicking one of the three control step buttons but before clicking the adjacent ones. It was clear that to maintain flow and avoid compromising a realistic experience, we will need to add more messaging and calls to action.

The design isn’t generalizable

“There are four populations that I could see using this….” (Interviewer: “Do you see all of them using this same design?”) “Honestly, no.” - U3b

Users who had friends or partners in but were not directly involved in kink groups had a different reaction to the design than those in kink groups. They both interpreted the language and icons (SLOW and STOP buttons) to mean different things--such as slowing or stopping the hardware only rather than slowing the progression of the scene or totally stopping the scene--and wanted the app’s “negotiation→scene→aftercare” system to be less structured. They saw how it could be drastically altered to fit more mainstream populations, whereas the testers within kink communities thought that that we’d “really thought well about what needs to be here and why” (U1b). Body language and time to click on features were also noticeably different; kink members leapt upon it and clicked around, even simulating scenes on video, and kink adjacents sat back without as much physical interaction with the site or hardware.

Discussion: Synthesize what you learned, document any shortcomings or caveats or your testing.

Based on the positive reactions from our users upon having a chance to to try out the app, we’ve concluded that members of the kink community are indeed interested in using this, and that they consider it to be novel and to fills a sore need. Core members of the community recognized the language used to signal what sort of interactions the app afforded (at least in the cases where language was adopted from the community). For example, the safe words, the control negotiation process, as well as the icons demonstrating visual and audio control were familiar, and allowed them to easily navigate the interface. Importantly, the language and explicit ability to control a partner’s sensory experience caused users to feel that this was an app that was made for them and that would allow online interactions to feel more like real-life encounters. Several users indicated to us that they currently use applications such as Skype for remote power-dynamics play. While this currently can be made to work for this purpose, users expressed excitement that encounters through Dynamixx would lay the foundation for how the encounter was to occur. Additionally, they felt that the additional sensory controls that it adds over Skype added value to these experiences.

We also tested with a couple of users who were peripheral members of the community, but who had never before engaged in remote power-dynamics play. Certain aspects of the interface that were very clear to core community members (and valued by the same users for their clearness and for catering to the community) were not as clear to less experienced members of the scene. Like the core members, they were interested in the concept and felt that it filled a clear need. However, the challenges they experienced in following the same metaphors that made the UI intuitive to core community members indicated to us that. To make the app more attractive to groups such as LGBTQ couples, heterosexual partners, or casual users, these users would need the functionality to be more familiar--more similar to an existing video chat app, like Skype, with the sensory control play only existing as a discoverable feature. But core members expressed that it was important that designs, language, metaphors, and standard practices be drawn from the community, and that this would be especially important in allowing the app to be marketed via word-of-mouth within the community. This explicit catering to the community would not mesh well with an attempt to generalize the app. These divergent signals from the two user types indicated to us that the needs and design decisions are distinct for each of these groups. Thus, we’ve concluded that we can’t successfully market a “one-size fits all” app and expect the kink community (our main target group) to take well to it.

That being said, we found that some of the ways that we interpreted data from need-finding and wizard-of-oz testing into building our UI were not quite right. While users did appreciate that there was a negotiation sequence and an aftercare sequence, they felt that the negotiation sequence should not necessarily grant these powers immediately upon users agreeing that they would be willing to grant them. Users wanted to rescind controls or revise controls without being taken out of the flow of the video chat--as it stands, the “Re-negotiate” option returns them to a text-based negotiation sequence. It felt too sudden to them to suddenly grant control of video, audio, and hardware experiences, where in real life the power shift would be more gradual. They also felt that video/audio was more conducive to negotiation than text alone. There were also certain events that took place that were confusing, in which the UI did not provide sufficient information about what was going on. For example, during negotiation, partners were not sure what button their partner had clicked and thus what had been agreed to. Also, when one partner initiated aftercare, the other saw the UI changes but it was unclear to her what this meant.

We also had a chance to test out the hardware portion on a few of our users. However, one user who was a core member of the community indicated to us that there is a great diversity within the community in terms of what specific hardware appeals to people. While the base interactions enabled by the app (negotiation, comfort-signaling) appealed to them and would facilitate the type of remote encounters they engage in better than would Skype, they indicated that the hardware option was not as interesting or important to them. From this, we gathered that the UI should be a priority and should be as rich as possible, while the hardware should be swappable and peripheral. Ideally, there would be many possible hardware options to cater to the diverse needs of the community, and users could opt to use one, more than one, or none according to their preferences.

Our tests were subject to some unforeseen technical shortcomings. We found that our peer-to-peer implementation does not permit connections when one user is on a Stanford network and the other is not. This prevented us from simulating more natural, remote encounters, and confined us to local, lab-based demos. We were still able to gather data, and in certain ways our data collection was more structured than it might have been had we been able to carry out deployment tests, but this issue will need to be addressed before the next round of testing. Another shortcoming in our tests was that certain users were only curious about the scene, but were not actually entrenched in it. As we discovered, we would like to target core members of the scene, and so in the future our data will be more useful if we are able to test with more of these folks.

Implications: Describe how you plan to apply the study results in the next iteration of your application.

In accordance with the results of this study, we will continue to build Dynamixx so that it is targeted at core members of the kink community. It is important to continue to use language and practices that are familiar to this community, as that is what appeals to them most about using this app over a vanilla video chatting app. That being said, it should generalize as much as possible within this community, allowing users to opt in or out of every control aspect (especially the hardware component).

Through user testing, we were able to determine ways that negotiation and transfer of power should operate differently. The negotiation sequence should operate more as a “checklist” to indicate what each user is comfortable with, the the controls should be granted as users grow comfortable. Users should be able to grant, request, or rescind control without interrupting the video chat.

Similarly, users wanted more granular controls. They found it unexciting to control the hardware via a binary on-off switch, and would prefer a sliding scale. We will incorporate analog controls where possible in the next prototype.

The next functional prototype should also provide better feedback about system status. For example, when a negotiation agreement is reached, it should display to both users what agreement they arrived at. Certain buttons, such as the “Start” button, were unclear to users in terms of what clicking on them would do. Unclear language such as “Start” should be replaced with something that more clearly indicates the function of the UI element.

On a related note, there are many functions that are non-obvious. The app should include more calls to action with regard to these functions.

User testing also brought to light some basic software issues that we weren’t aware of previously. We will need to ensure that either the software or network conditions of our users permit peer-to-peer connections so that we are able to test all functionality of the app.

Functional Prototype II

Implementation progress

This week, we focused on making sure users felt safe and secure during the entirety of their Dynamixx-facilitated interactions. This involved letting them know what was going on at all times. We also made some updates to the way the hardware can be controlled, as well as a number of aesthetic changes. We were able to respond to most of the concerns that were revealed in user testing so far. One future change we could implement would be to facilitate changes to agreements about controls without starting over. However, because the only users that expressed concern about this were peripheral members of the scene (people who have experimented with BDSM, but do not regularly attend BDSM clubs), we have decided that this is a low priority that we will only address if it is confirmed via further testing with core members of the scene (those who regularly attend clubs or participate in groups such as Kardinal Kink or Mission Control).

Changes and updated features

Added status messages. Users were occasionally unsure what was going on during negotiation. For example, when the partner in control would relinquish tactile control, the other partner would see that element light up and say “OK!” but would be unsure what had been agreed to. Additionally, when a partner in control’s request was rejected, they didn’t understand what had happened and why they were being offered the same choices again. Any action related to negotiation adds an appropriately colored (based on the relevant element) status message to the chat box. Additionally, when the partner in control "blindfolds" or "silences" their partner, a status alert shows up in their chat box to reaffirm that this is the case (this is also reinforced visually with a change in button color).

Granular controls. Instead of an on-off toggle, we have implemented the ability for the user to control the intensity of the hardware’s movement. They can set intensity via a slider, which sends a signal to the hardware to move with the specified intensity. Users requested this feature as a way of helping them ease into the scene, as well as to feel a greater sense of control over their partner’s hardware. We made use of a familiar image so users would recognize that sliding the knob increased amplitude.

Tooltips and language changes. Because of the unconventional nature of our app, users were unsure during the negotiation phase what each type of control meant. We added small tooltips next to each type of control (tactile, audio, and hardware) that display some information about each upon mousing over them. This will help users understand what each control will allow them (or their partner) to do, so they know what they are agreeing to. Additionally, as user tests indicated that members of the kink scene responded best when it was clear that the product was targeted at them, we utilized more language from the community in these descriptions. For example, we used “blindfold” and “gag” metaphors in the tooltips, and we changed the “Start” button to “Start scene,” as these sorts of interactions are often referred to as “scenes” by members of the community.

Shift in style and feel between stages, especially aftercare. Based on needfinding data and data from our post-testing interviews, it is important to establish a shift in tone between the three stages of a BDSM interaction. It is also important that the style of these shifts reflects the nature of these transitions, as in the user tests, the style shift to green during aftercare merely left users confused. The shift to the main scene now features an animated darkening and the addition of a curtain image to play off of the “scene” metaphor. The shift to aftercare is now marked by an animation to a comforting pink color. There are also several new features for aftercare. First, a banner shows up that says which partner initiated the aftercare and reassuring that all controls have been turned off. This goes along with the sense of safety mentioned previously. Additionally, a number of stats, such as how many times the partner in control “blindfolded” the other partner, or how many times they received a warning, appear in the chat box. These are meant not only to mark the end of the interaction, but to encourage discussion about the scene that just took place. We will evaluate the effectiveness of these stats in our upcoming user tests. (The gathering of these stats also enables logging, which will be useful during our deployment tests of the software this week.)

Other less major changes and new features. This week also saw a large number of bug fixes and tweaks to improve the UI. For example, previously, someone could see their partner’s video before they had hit the “start” button. Now, the partner’s video only shows up when they consent to it, and a “Waiting for partner…” message is shown in the meantime. This again contributes to the safety and trust that we want to establish between users and the app. We also changed the wording for “re-negotiate,” as users did not realize that it would force them to go through the entire negotiation process again. Now, it says “Start over,” which we think will allow users to create a mental model for the button’s function that is closer to what it actually does. Additionally, last week this “Re-negotiate”/”Start over” feature was quite buggy, but this week it has been debugged and now functions correctly. Users are now able to start over after the session was terminated via the STOP button, which was not previously possible. We also discovered via user testing that important buttons during the negotiation were covered by the chat box with certain browser settings; this issue was resolved via dynamic CSS. There are also a number of aesthetic improvements, which we again believe to contribute to the perceived legitimacy and trust for the app.

As before, the app is located at dynamixx.herokuapp.com. We ask that you please refrain from using the slider, as this does control our hardware!

User Study II

Final Presentation

Presentation Slides

Presentation Video


Code & Instructions

Source code (zipped, hosted on Google Drive)
GitHub repo
Deployed site
To use:
  • Open the deployed site or run node server.js in the root directory and open localhost:8080. This will assign you a chatroom/hash. The first person to enter the chat is, by default, the partner in control.
  • Copy the url into a second tab (can be on a second computer, if using Heroku). This interface is for the partner on the receiving end of control. Only two people can enter a chat, so if you do this more than once you'll get booted into a new room.
Heroku seems to have some intermittent issues with webrtc. If video does not show up, or if partners unexpectedly leave during chat, this is the reason. Running it locally produces the most consistently stable results.