Making Workplace-Relationships Work

Working out the relationship model for an Enterprise Social Network

Cisco's WebEx Social is an enterprise collaboration platform focusing on capturing and retaining institutional knowledge and project history in a centralized place.

In a workplace, there is no need for adding "friends", so the product started off with just a single "follow" action. Following someone would get their updates into your activity feed, and also added them to your chat contacts.

This became a problem. Following the CEO to get news would also add them to your contacts list--right next to your lunch buddies. If you weren't careful, posts from your buds on another team end up drowning out your own team's posts, rendering your feed useless.

Unsurprisingly, the success rate for the simple act of adding a contact hung at an abysmal 60%.

As the product grew, I had the opportunity to revisit the interaction and propose a new relationship model that would better fit the needs of a workplace social network.

The ask was simple but abstract: separate the concepts of following and contacting someone.

Though we started from the lowest hanging option (tossing an extra "add contact" button up), I wanted to take the opportunity to involve our researchers and uncover more specific needs around workplace people and content management.

I contributed heavily to the research script, developed the prototype, took notes and participated in follow-up analysis for all sessions.

From there, I explored concepts around ease of management, negotiated these with the Product team and uncovered additional business needs, created and prototyped several UI avenues to test, culminating in both an interim solution that fit our available development resources as well as a long-term proposal that would address all of the various needs uncovered through research and collaboration.

Context Overview

Human relationships are at the core of any social network.

Message. Follow. Friend. Connect. These terms describe the relationships that a platform supports and each term implies a specific sharing and privacy model on the platform.

‍Friends suggests a personal bond and a bi-directional acknowledgment that allows sharing of a certain level of personal information, while connections suggests bi-directionality, but no personal ties or access.

When the terms used (and their perceived privacy models) don’t match what is actually happening, the platform becomes unusable.

Benchmarking and Comparative Analysis

Before trying to reinvent the wheel, I performed an extensive review of a few prominent existing social models.

‍Facebook: The de-facto reference and probably the simplest model (for the average consumer)

‍LinkedIn: An individual’s professional profile. Publicly displayed information influences who to connect with or contact (name, role, employer, industry, etc.) and network statistics are employed to suggest connection and contact.

‍Twitter: A one way model where privacy is rendered a non-issue by the public nature of the platform.

‍Spokeo: A search engine for people who you are presumably not in contact with. Interesting due to many people having the same name--disambiguation is also important for large enterprise organizations.

‍Gmail: One of the most important ways we still communicate and share work documents, with private contact list features.

My research focused on their capabilities and features around searching for, adding, managing, and ultimately utilizing (contacting) contacts. I took note of how people are referenced before and after adding, the information available with which you can make a decision whether or not to add, and behaviors around all involved interfaces. From this, I began sketching out an initial concept.

Initial Concept Model

We often describe an enterprise social network as “Facebook for Enterprise”, but the phrase is a bit lacking. The social constructs in personal networks and work networks are wildly different, thus ‘sharing’ takes on a different meaning.

Within a company, you do not bar who can or cannot communicate with you, and restricting access to documents counters the mission of capturing institutional knowledge.

Since we don’t need to limit who you can contact or share documents with, any explicit list of ‘contacts’ becomes more about convenience than access. My initial concept sought to explore ways to create convenience around the formation and organization of contacts lists.

A thorough solution should also address motivation for organizing contacts, because it's a bit lame if users are only driven to a task out of annoyance. I hypothesized that people would more proactively manage lists of people if the lists get surfaced in a beneficial way throughout the product.

In broader terms, I wanted to explore how professional relationships help users navigate the sea of information generated by a large company or team.

The strength of workplace ties depends on set structures such as company hierarchy and project membership as well as social cues such as contact intimacy (small group settings) and communication frequency.

Those closest to you often share multiple layers of structural and social ties with you. This affects document sharing and consumption--you might chat with lunch buddies, but you have no interest in their work documents if you are not on the same project.

A cross-section of the venn diagram shows how the same person may fall into many different social and hierarchical groups. Roughly, the more salient (and recent) layers a person occupies, the more immediately relevant their documents are to you.

In other words, the broader goal of people-management is really tied back to how users interact with content.

As 'Follow' implies a one-way flow of passively consumed content and is quite different in nature to the two-way exchange of shared documents and experiences suggested by other forms of communication, we decided to propose a full separation of these two concepts.

A small addition, but the real change is under the hood.

The existing product did not capture any contact behavior.

We proposed that once a user initiates contact (chat, call, or meeting), both parties are marked as 'contacts' within the system, and show up as such in predictive search for document sharing and all people-search fields throughout Cisco connected communication products.

Product Feedback

The PM team disagreed with the separation proposal. They put forth that having a separate UI element and management for a list of people you 'follow' would complicate the relationship model. They proposed instead that people you 'follow' should just be another type of contact, and wanted to reflect that relationship in the UI while still promoting 'follow' as the main CTA.

Though I agreed with the intent of their proposal, I still believed that separation was the simplest solution to the problem at hand. I hand coded prototypes for all variants (along with a few other concepts I wanted to test) and we took the issue through User Research.

User Research

Research Plan
Our research sessions focused on communications tools that participants were already using, as well as their current habits regarding organizing and contacting people.

In the latter half of the sessions, we used the prototype to test the proposed contact addition methods to gauge response, as well as to hear reactions to the automatic addition/categorization of contacts.

The order of appearance of these interfaces was randomized across participants.

User Tasks
Follow Jeff

Setting: User is viewing their activities feed and sees Jeff Jefferson tagged in a post
Goal: See how users try to perform an action on a tagged person
Sucess: Hover over Jeff and click 'follow' on the hover card that appears

‍Chat with Anne and Close Chat Session

Setting: After the session is closed, a message appears saying that Anne has been added to Contacts
Goal: Get reaction to auto-add feature

Add Jeff to Contacts (option 1 from above)
Add Jeff to Coworkers List (option 2)
Add Jeff to Coworkers List (option 3)

Setting: User is viewing their activities feed and sees Jeff Jefferson tagged in a post
Goal: Determine which UI Option is most understandable and preferred
Sucess: Hover over Jeff and click the corresponding element for adding him

Find Anne in your Contacts List

Setting: User is on any page of the application
Goal: Test whether users are able to find the contacts list
Sucess: Open the contacts list from the bottom bar

Abridged Findings

Users varied widely in how organized their existing contacts lists were, depending on personality and job role.
Users understood the potential usefulness of the proposed auto-add feature, but most did not like having the adding done for them, and stated they would turn it off.
Option 2 (PM Proposal) was universally confusing. Option 1 and 3 were equally usable, but Option 3 was preferred, as users preferred to categorize their contacts up front.
The speech bubble notification that appears upon adding a contact helped users find their contacts list.

Final Wireframes

I successfully obtained buy-in for the future vision, but we still had a limit to our current resources and needed to settle on a useful first step towards that vision.

I developed the following set of final wireframes with this in mind, covering basic features of list creation and organization, and going with UI option 3 from user testing.

In-context adding and removing of contacts:

Contacts List management and usage options:

Concept Model Revision

Though I had to reject the PM proposal for the UI based off of test results, I supported the long-term vision of a more flexible relationship unit. Our scope and allocated resources for this release would not be enough to fully realize this vision, but even a mid-step required that we make sure which background model we planned to move towards.

I began by diagramming out models for the options tested:

Though we planned to move forward with Interface Option 3 (the best performer from user testing), we noted that this does not match the desired model.

‍Of course, it's not all that bad for users. They don't really need to know that people they follow are also captured in the same structure as their contact lists.

However, to share our long-term proposal, I wanted to sketch out how a fully realized flexible model would look.

A more flexible relationship unit allows lists of people to be used throughout the product depending on individual user need, and opens up opportunities for upcoming needs.

You can see posts from a “Senior Leadership” list in your activities feed while keeping your chat only to your “Team” and “Lunch Buddies” lists, and have cross-functional “Project X” and “Project Z” lists in the back ground to share documents and invite to meetings.

You can create public or private lists, as well as retire (without deleting) lists you are no longer using, like a “Project X” list once Project X is completed.