My mind was buzzing after I took off the headset. As a content strategist at Facebook, I use language to create clear, consistent and compassionate experiences for the people who use our products. Content strategists often communicate through words displayed on a screen in the form of dialogs, notifications, calls to action and other interface components.

What I’d just experienced felt more immersive than any interface I’d encountered before. And, while the experience was a completely new one, it had felt strangely intuitive. It became immediately clear to me that virtual reality represents a new and exciting challenge for content strategists. How do we bring clarity and simplicity to an experience when we move beyond the screen and the interface is all around us?

Several months later, I had the opportunity to investigate this question for myself. I worked with the Facebook Spaces team on Facebook’s first social VR app. It’s a virtual environment where people can spend time with their Facebook friends. They can watch videos, capture photos, play games, work on art projects and experience 360 media together. There was a lot to explain and no screen on which to do so. I was going to have to approach this from a different angle.

Social VR represents a new kind of conversation with the people who use our products. We didn’t want to introduce a lot of text into an immersive experience. We knew we’d have to make the most of the limited opportunities to explain all the features and functionality, like creative tools to make 3D art and media players to experience 360 photos and videos. I felt that the best way to do this was to help people form a clear mental model of the virtual space we’d created by anchoring the experience in simple and familiar concepts. To do this successfully, we needed to make careful decisions about how to label the concepts in this experience.

We had a long list of placeholder names and labels for various features. In Content Strategy, one of our core principles is to name things only when it’s absolutely necessary, so I did a quick audit of our list with that in mind. The goal was to choose names that would clearly communicate the purpose and potential of features, and they had to make sense all together. We put together a set of guiding principles to help us identify the names that felt unhelpful, inconsistent or unclear:

• Avoid names where interactions are intuitive. We decided not to name something if its function or purpose was immediately obvious. For example, when a person was in a virtual space in the app, we didn’t need to explain to them that the surface they were standing on was like a floor — it was intuitive and familiar enough a concept that it needed no explanation.

• Don’t label design decisions. One important feature of the Spaces app was the ability to show media, like photos, to others in the space. Facebook Spaces supports both regular (2D) photos and 360 photos, and the team had created different designs for each of these. In Spaces, 2D photos look like a flat tile you can grab with your fingers, while 360 photos look like a sphere you can hold in your hand. We’d taken to calling these “photo tiles” and “photospheres” during the product development process, but it felt unnecessarily complicated to have multiple names for what was essentially the same concept. To simplify the experience, we chose to focus on the concept and choose one name (“photo”) rather than name each form.

• Question the use of metaphors. Metaphors can be useful as feature names when they clarify the purpose of an object or the intention of a part of the interface. Prior to the launch of Spaces, we were using a lot of these kinds of names for features to tie features to objects in the physical world. But taken together, placeholder names like polaroid, tool shelf, dressing room, picture frames, props and selfie stick painted a jumbled and confusing picture of the environment we’d created. We needed to make sure that any metaphors we did use were clear and supported people’s understanding of the product. And I felt we shouldn’t close ourselves off to future functionality or localizability by getting too specific with the comparisons we were drawing between real life and this virtual environment. As we started to assign more names to features in Spaces, it felt necessary to clarify additional guidelines around when and how to use metaphorical labels for virtual objects.

Metaphors are useful as feature names when they clarify the purpose of that feature. They’re a handy way to make a direct comparison between a virtual object and something familiar from the physical world. For example, calling a glowing, blue oval a “table” is a clear and concise way to explain to someone that they can place things on top of it or gather around it, without having to actually say all of that. It seemed wise to use metaphors sparingly, as giving people too many to keep track of could create a confusing experience. I worked with the team to create a set of principles to help us make quick decisions around which metaphors worked and which ones didn’t:

• Keep them consistent: The metaphors in a product need to make sense together. For example, it’s confusing to mix live theater metaphors with home theater metaphors, or futuristic metaphors with retro analog ones.

• Make sure they’re relevant: We needed to make sure that metaphors we included could make sense to anyone. This meant avoiding any metaphors that had specific cultural meaning and might not be relatable for people from different locations or backgrounds. In a pre-launch version of Facebook Spaces, people would change the appearance of their avatar in what looked like a room with heavy velvet curtains. Two names that were top contenders for this place were “backstage” and “the dressing room.” These theater-themed metaphors felt problematic for a number of reasons. First, they implied that your space was a place of performance rather than a place where you could spend time with your friends. Second, it was a metaphor that might not make sense to everyone. We eventually decided it was simpler to not to name this part of the experience at all.

• Maintain flexibility: Because we intended to continue to build more functionality into this new app over time, we needed to choose names that afforded us the flexibility to change functionality as needed. “Projector” was the working name for the feature that you’d use to show photos or videos to other people in your space. The name “projector” drew a comparison between this feature and a specific piece of analog technology. It suggested that this affordance had one specific function: to project images on the walls of the space. This felt problematic because there was a chance that it would eventually do other things, too. We decided against this restrictive metaphor and, instead, focused on explaining how it worked (“Place a video here to display it” or “Show photos and videos to other people in your space”).

With Spaces, we were giving people a new kind of space in which to have new kinds of conversations. People would talk to each other in real time about what they were experiencing, so the language needed to work in conversation, not just in interface elements. We brainstormed things people might say to each other:

• “Hey, could you pass me that photo?”

• “Play that video — just put it down there and it’ll start.”

This was a great way to stress test our decisions. It helped us see how a name (or the absence of one) would fit into the conversations people might have in the app.

Here’s a summary of the guidelines that were useful to our team:

• Content strategists are often called upon to name and label new features, but we can do a lot more than just assign names to features once a product’s design is complete. A content strategist is uniquely positioned to contribute to the formation of concepts in a new product.

• Prioritize natural, descriptive language that works in spoken conversation. The stakes are high when you’re naming new concepts and features, especially in an interface that supports actual conversation — you’re giving people the words they’ll use to discuss their experience with each other.

• While names are necessary sometimes, avoid labeling every design decision or novelty in an experience. In other words, not everything needs a new name. This gets tricky when placeholder names have been attached to features during the product development process. It’s important to discuss which features deserve a name and why, and testing those decisions with examples.

• Don’t rely too heavily on metaphors as feature names. They’re an easy way to tie a feature to a familiar object or concept from “the real world,” but they can be restrictive or confusing. Choose names that are inclusive and will age well. Make sure you’re thinking holistically about how all of the terms you choose will work together as a cohesive system.

• Identify the guiding principles that help you make your terminology decisions. This will help others understand the philosophical underpinnings of your decisions and show that they’re not arbitrary. Principles will also help inform future naming decisions and ensure that they’re consistent with your approach.

Read more about the Facebook content strategy team’s work in VR in my colleague Andrea’s piece on Medium, “Designing for Virtual Reality: 3 Tips for Content Strategists” and check out Facebook.design.

Thanks to Sara Getz and Jasmine Probst for their feedback and support.