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:
- Which portions of the application create the potential for a realistic interaction between partners?
- Which portions of the application facilitate a pleasant or satisfying interaction between partners?
- To what extent does the hardware facilitate an effective application of dominance by one partner?
- What should be changed to allow for a more effective “negotiation” of practices between partners?
- What should be changed to allow for a more realistic or satisfactory “scene”?
- 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:
- 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.