Indulge me for a moment. I have a series of jokes I want to tell you:
How many social scientists does it take to change a lightbulb? None. They do not change lightbulbs; they search for the root cause of why the last one went out.
How many simulationists does it take to change a lightbulb? There's no finite number. Each one builds a fully validated model, but the light never actually goes on.
How many statisticians does it take to change a lightbulb? We really don't know yet. Our entire sample was skewed to the left.
So what's with the (not particularly funny) jokes? The point is that they play off particular ways of thinking. In doing so, they show us how different the world can appear, depending on your perspective.
This was evident in a recent meeting. Reminiscent of another set of common (and usually also not funny) jokes involving different nationalities walking into a bar, there were six people in a room: an interaction designer, a statistician with an interest in behavioral modeling, a social scientist, a computer scientist, an self-described "back end with a touch of front end" engineer, and a business executive. We were brainstorming about accessing social Web applications from personal mobile devices.
Two minutes into our conversation, I said, "We should start with some sound social principles." This was my bland opening gambit, a preface. Or so I thought. I paused for a fraction of a second, took a breath and...everyone started talking at oncelike whippets chasing after the faux rabbit at a dog race, the conversation was off. Then it stopped, followed by blank looks.
The problem was the word "social."
Sometime later, as I was contemplating what had happened, a quick perusal of the dictionary yielded these definitions of social: relating to human society and its members, living together or enjoying life in communities or organized groups, tending to move or live together in groups or colonies of the same kind, and living or liking to live with others, disposed to friendly intercourse. Etymologically, the word derives from the Latin socialis, meaning "united," "living with others," and sequi, meaning "follower," which should make contemporary social Web application designers happy". John Locke, the famous 17th-century philosopher, spoke of "social" as meaning "pertaining to society as a natural condition of human life." And as an adjective, "social" creeps in over the years as: "social climber" (starting in 1926); "social work" (1890); "social worker" (1904); "social drink(ing)" (1976); "social studies" as an inclusive term for history, geography, economics (1938); and a concept close to our hearts in these hard times, "social security" as a "system of state support for needy citizens" (1908). That gelled with my thinking, and was the backdrop to the conversation I thought I was starting.
However...to the interaction designer, "social" invoked "social Web applications" and all that it means for human interaction with voting (thumbs up and down), favoriting (stars), contact lists and buddy lists, followers, avatars and profiles, chat threading, commenting, recommendations, and view counts. It meant a discussion of icons that suggested (or were derivative of) those on successful social media sites and multimedia content upload and sharing. Talk poured forth about social games and questionnaires, pokes and winks and friending. Let me be clear. I love thinking about these issues, and have recently reviewed drafts for two excellent books about how to design interaction elements for social applications wellBuilding Social Web Applications by Gavin Bell and Designing Social Interfaces by Christian Crumlish and Erin Malone. But for the purposes of this meeting, tossing out all of these concepts was great, but it was also putting the cart before the horse. We'd get there, but not yet.
To the computer scientist, "social" sparked sweet, seductive imaginings of the social graph. Wikipedia defines a social graph by explaining that "a social network is a social structure made of individuals (or organizations) called 'nodes,' which are tied (connected) by one or more specific types of interdependency, such as friendship, kinship, financial exchange, dislike, sexual relationships, or relationships of beliefs, knowledge or prestige." The entry continues: "Social network analysis views social relationships in terms of network theory about nodes and ties. Nodes are the individual actors within the networks, and ties are the relationships between the actors. The resulting graph-based structures are often very complex." No kidding...I love the complexity and curiosity of my specieshuman beingsand these ways of conceiving social relationships often strike me as dismayingly reductive. They're very useful within their bounds, but they are summary abstractions of the lyrical complexity of everyday social life. We had a very fruitful foray at this meeting into social recommendations and boundariesthe complexity of "friend relations" and "access control privileges"; the connections between objects via hash tables; and connections between people, their stuff, and other people's stuff. We discussed these things as inadequate approximations for supporting the negotiated and fluid nature of social trust relationships and the subtle boundaries we negotiate with others.
Somewhat related, my colleague with statistical training was excited to introduce aggregate behavioral models from activity data and collective intelligence from explicit data in our discussion about contemporary notions of "harnessing the hive." We pressed through issues in database design and the potential for data mining, as well as the relevance, recommendation, and algorithms for automatically inferring buzz, interest, and so on. Here, "social" was to be found in the shadows cast by humans clicking, clacking, typing, uploading across the interconnected networks of the Internet, and making connections betwixt and between things that were heretofore not there to be connected, or at least not visibly so. We discussed how we sometimes derive modelshypotheses, reallyabout behavior from these obscured traces and how we are sometimes fooled into seeing patterns where there in fact are none.
I won't enumerate all views expressed, but surely you get the point. I also don't want to pretend I was seeing the whole picture as this conversation was unfolding. I was equally seduced by these viewpoints and equally entranced by possibilities for implementation and creation. But laterand it was some time laterwhen I pondered how this short conversation had played out, I realized that we had all collectively engaged in a "we could build/implement/create/design/make" discussion. I had intended to have a conversation at a higher levelone that addressed what people really need, or what would be really helpful and valuable to people. Stepping back even further in the ideation process, I would have liked a conversation about broad design opportunities, about finding out what people want/need/desire or would value before we outlined interface, interaction, and "under-the-hood" possibilities.
Instead, we were enacting the classic "ready, fire, aim!" approach to design that has been a parody of innovation for many years nowdesign it because you can, stitch together what you already know how to do, throw it out and see what sticks. This is perhaps a natural human tendency because really creative thinking is hard. In a 1986 paper entitled "No Silver Bullet," Fred Brooks differentiates software design and development processes; he calls them "essential" and "accidental." "Essential" refers to the difficult part of understanding the domain for which we're building software and the determination of what software to build in that domainwhat activities to inspire, improve, or transform. "Accidental" is the programming and process that has to follow to implement the solution that has been devised. Brooks aptly points out that we have become quite good at training people and designing tools for the accidental part of software development, but the ideation part continues to pose problems. He succinctly states, "The hardest single part of software development [remains] deciding precisely what to build." Perhaps this will always be the hardest part because it requires embracing uncertainty, opening possibilities for new solution tracks and resisting the urge to redescribe every scenario until is appears tractablethat is, until it becomes the kind of problem for which we already have an familiar, easy to execute solution.
What I had intended to inspire when I dropped my word-bomb was a discussion of the role that such applications could and do play in everyday life. I was talking about the potential contexts of use for any application we would build. I was silently channeling ergonomists and social scientists who address the physical and/or social constraints of settings, about the factors beyond the interface, application, device or appliance that would be the major part of why it would be adopted or abandoned. I was talking about how whatever we propose could fit into people's social context, into how they manage their everyday doings. I was thinking about people, about relationships and friendships, and about the contexts that we inhabit and cocreate as we move through daily life. I was hoping to explore the options and hone in on possible social settings that would afford, support, and allow a technology to be used. I was talking about delivering value in situ without disrupting the situor at least giving some thought to designing ethically; to considering the positive versus negative knock-on effectsany disruptions to the social status quo we wanted to inspire and those we did not. I was talking about social norms in the places people frequentwhether or not, for example, it would be socially acceptable to whip out said devices and applications in public.
I am not saying we should have indulged in an infinite regress into consequences of every design decision, but I am saying it is worth engaging in chain-reaction thinking. I was inviting us to elaborate the potential design spaces, where there would be something useful for people, before we start coming up with specific solutions. It seemed to me that we needed to understand what we were designing for before we starting designing. I was trying not to be Rube Goldberg or Heath Robinsonwhose love of the engineered artifact gives us fantastic contraptions that maybe, perhaps, get the job done but in the most circuitous manner possible, honoring the engineering over and above utility, aesthetics or the social/physical context of use.
In retrospect I inadvertently started the conversation poorly, and it took us some time to get back on track.
However, the rambling consequence was perhaps the greatest lesson. I am not a social linguist, but perhaps what I was seeing at work was the result of each of these people being representatives of different "epistemic cultures." An epistemic culture underlies how we know what we know and how we think about things. Think of places you have worked: how different organizational cultures enact and formally or informally measure performance based on concepts like incentive, performance evaluation, teamwork, work-life balance, and so on. In the same way, "social" may be observed, measured and applied, or designed differently in different epistemic communities or cultures. What this means is that we must be wary of words, vigilant of misunderstanding, and prepared for the work of creating shared meaningswe need to understand these conversations are not casual, they are the place where we broker between different epistemic communities and different constituencies in the design space. We also need to look out for design suggestions that are drawn out of comfort (let's do it how we have always done it and with what we have available), where that strategy will not result in the experience we are trying to design. I am all for reuse and finding new value in known techniques, but not when it is done because it is simply less work. I suspect it also means that if one is to carry a vision for a designed artifact from ideation to implementation and release, one had better be present for all the "decision" gatesfrom inspiration to innovation.
With these observations, I am likely preaching to the choir. In the world of design we know we need to accommodate a lot of perspectives.
How many designers does it take to change a lightbulb? Well, normally one...but:
- +1 because we need to user-test the lightbulb
- +1 because marketing wants to build the box and brand the bulb
- +1 because sales wants to go global with the lightbulb
- +1 because engineering wants details specs
- +1 since we need to evangelize about it
- +1 since we need to build a user community around the lightbulb
- +1 since we need to explore different directions we can take the lightbulb.
Elizabeth Churchill is a principal research scientist at Yahoo! Research leading research in social media. Originally a psychologist by training, for the past 15 years she has studied and designed technologies for effective social connection. At Yahoo, her work focuses on how Internet applications and services are woven into everyday lives. Obsessed with memory and sentiment, in her spare time Elizabeth researches how people manage their digital and physical archives. Elizabeth rates herself a packrat, her greatest joy is an attic stuffed with memorabilia.
©2010 ACM 1072-5220/10/0100 $10.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2010 ACM, Inc.