Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience 2nd Edition

Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience 2nd Edition

English | 2015 | ISBN: 978-1-491-91985-9 | 620 Pages | PDF | 50 MB

Designers, developers, and entrepreneurs today must grapple with creating social interfaces to foster user interaction and community, but grasping the nuances and the building blocks of the digital social experience is much harder than it appears. Now you have help.
In the second edition of this practical guide, UX design experts Christian Crumlish and Erin Malone share hard-won insights into what works, what doesn’t, and why. With more than 100 patterns, design principles, and best practices, you’ll learn how to balance opposing forces and grow healthy online communities by co-creating the experience with your users.

  • Understand the overarching principles before applying tactical design patterns
  • Cultivate healthy participation and rein in misbehaving users
  • Learn patterns for adding social components to an existing site
  • Encourage users to interact with one another, whether it’s one-to-one or many-to-many
  • Use a rating system to build a social experience around products or services
  • Orchestrate collaborative groups and discover the real power of social networks
  • Explore numerous examples of each pattern, with an emphasis on mobile apps
  • Learn how to apply social design patterns to enterprise environments

Contacts and Relationships

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 ofcollaborative 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 fid 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” on page 454 can work for this situation

What Is the Social Object?

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

What Are the Jobs to be Done?

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

Open APIs

You have a suite of interesting solutions and a collection of data You recognize that others can create new and unforeseen solutions with the data if it is exposed through an API, as shown in Figure 18-6

Use when

Use this pattern when developing your site’s architecture, when conceptualizing the ecosystem your service will live in, and when deciding which APIs or which aspects of your existing APIs to expose to the public


Wherever possible, expose APIs that enable outside developers to extend the value of your core service  Each case will have its own issues of data security, privacy, what gets shared, authentication, authorization, and so on Terms of Service provide a legal framework for safe data sharing practices, but a rule-based permission system must be in place to enforce rules mechanically  Some services must be opened on a read-only basis This may frustrate your third-party developers, but if it can be justifid as better than no access at all to data and connection information, then it may still be worth offering