Gone are the days when impersonal IT departments can impose horrendous “ERP” or any number of other TLA software with archaic unusable interfaces and seemingly no concern at all for the experience of the end user. This longstanding state of affairs thrived because traditionally the end user has no purchasing power or direct input into the software selection process.

We have entered the era of BYOD (bring your own device) and our workforce increasingly comprises peole who have come to expect “consumer quality” experiences in the online products and services (meaning, roughly, “I paid for this crap. It had better work!”). This puts pressure on wannabe disruptive new entrants into enterprise systems, productivity, HR, employee relationship management and so on to live up to increasingly smooth, focused, tactile, satisficing standards of the others apps on their employees, customers, vendors, and supplier’s smartphones.

It is possible that we are being too optimistic about this. We have thought so in the past, but the trends are encouraging.

Fewer and fewer workers today connect to their own information and colleagues from a single stationary workstation. Oh, you might have a cube and you might even leave your laptop there overnight, but you are also looking at email on your phone in the line for coffee and you might be getting Slack alerts on every device you own.

It’s the people who are mobile, not the devices per se. Your job, if you want to make social software that is valuable and effortless (and thus adoptable at all in the first place), is to ensure that you are everywhere, in browsers and where necessary in native apps, and connecting to as many effective communication, alert, notification, and cross-pollination channels as you can handle (see Figure 17-1).

Figure 17-1. As of this writing, the dominant player in enterprise social at this exact moment is Slack, which sometimes seems to be taking over the entire knowledge-work economy.

In the corporate environment, there should be no need for signing up, because the user is already an employee and part of the system. Designers should take advantage of existing security and sign-up mechanisms, including username, password, and any security measures, such as RSA tokens. After the user is signed in, the social tools should reflect his identity to himself and to others (see Identity).

First of all, the designer should consider how much of the basic social networking foundations need to be a part of the system. In most corporate environments, there is an intranet and an internal employee lookup system, such as Lightweight Directory Access Protocol (LDAP), which gives employees information about role, title, email address, phone number, location, and other information about their fellow colleagues. This information is often managed and generated by the HR and IT departments and is a source of truth in terms of data.

Any social tools built for this environment should pull in this existing profile and identity information rather than duplicate it, such as is demonstrated in Figure 17-2. You should not require users to create another profile. At the same time, as our reviewer Laura Klein helpfully pointed out, “users should also be able to control the information shared with their coworkers. Even basic information, such as assigned gender, can be something that a person doesn’t want to share with his or her coworkers.”

Figure 17-2. The user experience design (UED) team at Yahoo! (at the time of this book’s first edition) had its own intranet, but tapped into the main Yahoo! internal system for identity information, including username, reporting structure, phone numbers, and email. The UED intranet itself allowed users to add more personal information to help build teams and strengthen relationships across workgroups.

In many corporate intranets, employees can see where a person falls in terms of her reporting structure or workgroup. There is an inherent set of relationships available in the reporting structure information, but this is not necessarily the most useful people list for users in terms of collaborative software.

The useful people list in an enterprise social context is the listing of the relevant workgroup, regardless of reporting structure. In most cases, the group or project leader can put this together. The functionality of walking the social graph to find and add friends to the list is not as vital in the enterprise situation, but there can be value in being able to pull together a network that is divergent from the hierarchical reporting structure or workgroups. Displaying the work group or members list in a collaborative situation is useful, and Publicize Relationships can work for this situation.

As with any social design project, you must identify the social object around which you are going to build activities and connections. Note that you start much higher on the engagement scale when folks are working together in a committed environment. The presumption is that collaboration is a key goal, and so the social object might be documents, plans, roadmaps, deliverables, or things such as projects and teams.

A version of Clayton Christensen’s “jobs to be done” theory applied to software design proposes that rather than investing in UX instruments such as personas and scenarios, that the better approach is to interview potential customers and understand the jobs they need to get done and how they do them today. From that, as the theory goes, you can focus on improving their ability to get these jobs done without understanding them as a theoretical people.

Thus, the basic model of a “job story” (versus a user story) is, “When I am [in some situation], I want to [do something] so I can [get an expected outcome].” There are schools of thought that bring in forces (just as with Alexander’s patterns) and the affective experience of the person doing the job. That is, how they feel doing it: When are they happy or in the flow? When are they frustrated, angry, annoyed, or discouraged?

Whether or not you go all in on this approach to figuring out what to build for your customers, the underlying framework makes a great deal of practical sense when you are making something for folks who have work to do.

A shared dashboard for the workgroup that shows the latest changes or activity within the context of the enterprise solution is a good way to utilize the status or vitality stream in the corporate environs.

Users of the system will want to know at a glance where activity is happening, what conversations are happening, who last worked on a document, or whether a collaboration event has been scheduled.

Designers need to be mindful of the delivery mechanisms for the status stream within the enterprise environment. People get a lot of email already, and consideration needs to be made for whether an action pushes out both a vitality notice to the stream as well as an email, or whether the user will be responsible for continually checking in to see what’s happening.

A perennial holy grail of enterprise software is to kill email. Sometimes, this is expressed in a maximalist sense: to get rid of all email period. Most people don’t want this necessarily, but they do want to avoid clutter, noise, unproductive and inconclusive discussions about important decisions, and so on.

Thus, one enduring opportunity being chased in the social space for work is a communication medium that is separate and usually rather different from email (although, in the end most of these systems reserve the right to send you more email after all). The most common paradigm seems to be chat.

In the old days, it was said that eventually every piece of software evolves to the point at which it can send email. We might be entering an era in which every application offers you another chat window to monitor (and of course the risk of an embarrassing “oops, wrong window” faux pas when you type or paste a message intended for one type of correspondent with another type entirely).

Slack, for example, is taking the enterprise social world by storm with a beautifully designed, smartly interoperative experience built around Internet Relay Chat (IRC) at its core.

Quip set out to reinvent documents for the mobile era and seems to be providing customers more with chats focused around shared document or whiteboard spaces.

Google Docs provide places for comments and live chats.

Facebook has its own chat window and independent app, of course.

Yammer and Chatter enable “public” conversation (in the sense of Many Publics). Figure 17-3 shows the rich variety of communications that are available in Salesforce’s Chatter app.

Figure 17-3. Salesforce’s Chatter product provides forms of public conversation as well as instant messaging (chat) and private groups. It also provides opportunities to collaborate around documents and other objects.

No one seems to have killed email yet. (In fact fax machines persist in some zombie-like half-life, and I believe there are still some active telegraphs chattering away somewhere.)

Administrators and moderators of these types of social experiences don’t have to deal with the large amounts of bad behavior that can often disrupt a discussion or other social environment in the public at large, but this kind of behavior can still take place in the enterprise world. The difference here is that users cannot hide behind a pseudonym, and their interactions are tied to the workplace and often to work performance.

Tools for various levels of permissions and roles might still need to be developed. In this context, different levels of authorship or ownership might be tied to the hierarchical role in the company and some data-editing might be limited to certain levels in the system. For legal reasons, many companies never delete anything. They can archive it or hide it, or that option might be given only to the highest level of administration in the system.

Wikis and forums and other collaborative tools still need to be moderated, if only to clean things up, keep files and documents organized, and generally keep projects or tasks moving.

In short, features such as favorites, ratings, reviews, and reputation are not necessarily needed within the enterprise. Users are captive, so they don’t need to be led along the social ladder of participation, but many of the tools can be helpful. Features such as tagging and collecting can be valuable for finding and sharing information in an ongoing fashion, or for finding people in the organization who might be experts on a specific topic.

Ratings, reviews, and reputation should be scrutinized for their value in the specific organization. There are potential social and cultural barriers for utilizing and participating in ratings and reviews in the enterprise. People might be hesitant to proactively rate or review work or documents in a public forum for fear of repercussions affecting their status, their employment position, and their annual reviews. The ramifications of these tools for the people and the business should be carefully considered before spending the time and effort to implement them.

Communication tools—text, video, and voice—play a bigger role than in consumer software and should be integrated into the everyday workflow.

Collaborative tools—wikis, blogs, and group calendars—should be at the forefront of an enterprise social experience (see Chapter 12).

Ultimately, people are there to get work done together, and the enterprise tools should help facilitate that collaboration and sharing, regardless of the organizational structure.