Guest lecture by Kurt Luther in Prof. Leysia Palen's "Social Computing" course, Department of Computer Science, University of Colorado, Boulder, January 2014.

1. How to Design a Social
Computing System that
People Want to Use
Kurt Luther
Carnegie Mellon University

2. “If you build it, they will come!”
1

3. “Nobody came!” 
2

4. 3

5. 4

6. pipeline.cc.gatech.edu
5

7. 7 Recommendations
1.
2.
3.
4.
5.
6.
7.
Focus on a community and learn what it needs
Use informants as beta testers
Release early and often
Form a relationship with the staff
Organize events around your software
Evaluate and iterate
Embrace unexpected uses
6

8. 1. Focus on a Community
• Systems designed for “everyone” often aren’t
great for anyone
• Find a community that interests you and focus
on them
7

9. 1. Focus on a Community
8

10. 1. Learn What the Community
Needs
• Triangulate with mixed methods
• Participate, don’t just observe
• Involve users throughout design process
– User-centered design (Norman & Draper 1986)
– Participatory design (Schuler & Namioka 1993)
– Meta-design (Fischer & Scharff 2000)
9

11. 1. Learn What the Community
Needs
• Research methods
– Interviews with 17 Newgrounds
members with collab
experience
– 5 years of participantobservation on forums
– Content analysis of ~900 collab
threads
Joseph Blanchette, 24, USA
Eric Carlson, 19, USA
Luis Castanon, 27, USA
Michael Frank, 19, USA
Tom Fulp, 29, USA
James Hole, 16, Australia
Tyler Koch, 19, USA
Massimo Maitan, 21, Australia
Anders-Martin Meister, 16, Estonia
Ross O’Donovan, 19, Australia
Kraig Phillips, 27, USA
Joseph Rooks, 21, USA
Kester Smith, 21, UK
“Sven”, 18, Netherlands
Hans Van Harken, 17, Spain
Robert Westgate, 21, UK
“William”, 19, USA
10

12. 1. Learn What the Community
Needs
• Study results
– More than 80% of collabs never completed
– Leadership is crucial, but leaders often overwhelmed
– Leaders try to increase success by simplifying
projects, minimizing interaction
– Poor technological support
(Luther & Bruckman 2008; Luther et al. 2010)
11

13. 1. Learn What the Community Needs
12

14. 1. Learn What the Community Needs
13

15. 2. Use Informants as Beta Testers
• They already know you
• They’re knowledgeable about the community
• They’re excited to see their comments acted
upon
14

16. 2. Use Informants as Beta Testers
15

17. 3. Release Early and Often
• Don’t just show up with a “complete” project
• Early announcements provide more time for
community buy-in
• Frequent releases mean frequent opportunities
for exposure
– Keep the community informed
• Linus’s Law
– “Given enough eyeballs, all bugs are shallow”
(Raymond 1999)
16

18. 3. Release Early and Often
17

19. 3. Release Early and Often
18

20. 4. Form a Relationship with the
Staff
• Staff can help in many ways
–
–
–
–
–
–
Advertising
Providing resources or prizes
Endorsing your project
Giving access to user data
Offering insights into the community
Generally making life easier
• Much trickier if you’re a competitor
19

21. Newgrounds.com main office, near Philadelphia, PA
4. Form a Relationship with the Staff
20

22. 5. Organize Events around
Your Software
• Attract a critical mass of users in a short time
• Online contests can be motivating, even if the
prize is attention instead of money
(Nickerson & Monroy-Hernandez 2011)
• Special events are a hallmark of a vibrant online
community (Kim 2000)
21

23. 5. Organize Events around your Software
22

24. 5. Organize Events around your Software
23

25. 5. Organize Events around your Software
24

26. 6. Evaluate and Iterate
• Does your system do what you designed it to
do?
• How are you measuring success?
– For creativity support tools, consider process as much
as output
• Iterate based on what you find
25

27. 6. Evaluate and Iterate
• Evaluating Pipeline
– Research questions
• (How) does Pipeline foster more ambitious, successful
projects?
• (How) does Pipeline change leadership?
– Methods
• Case study of Holiday Flood
– Interactive artwork organized on Pipeline
• 1100+ Pipeline log events
• 140+ Newgrounds forum posts
• Interviews with 5 most active members
26

28. 12 Drummers
Drumming
(Dec. 14)
6 Geese Laying
(Dec. 20)
11 Pipers Piping
(Dec. 15)
5 Golden Rings
(Dec. 21)
10 Lords Leaping
(Dec. 16)
9 Ladies Dancing
(Dec. 17)
8 Maids Milking
(Dec. 18)
6. Evaluate and Iterate
7 Swans Swimming
(Dec. 19)
4 Calling Birds
(Dec. 22)
3 French Hens
(Dec. 23)
2 Turtle Doves
(Dec. 24)
A Partridge in a
Pear Tree
(Dec. 25)
27

29. “Holiday Flood was all planned
and plotted. It’s the reason we
needed Pipeline. I doubt it would
have worked out any other way.”
–Renae (co-leader)
6. Evaluate and Iterate
28

30. 7. Embrace Unexpected Uses
• Appropriation (Salovaara 2008)
– Within the community
– Outside the community
• Unanticipated use is still use!
– Learn from it and design for it
29

31. 7. Embrace Unexpected Uses
30

32. 7. Embrace Unexpected Uses
31

33. 7. Embrace Unexpected Uses
32

34. 7. Embrace Unexpected Uses
33

35. 7 Recommendations
1.
2.
3.
4.
5.
6.
7.
Focus on a community and learn what it needs
Use informants as beta testers
Release early and often
Form a relationship with the staff
Organize events around your software
Evaluate and iterate
Embrace unexpected uses
34

36. “If you build it with them, they will come!”
35

37. Questions?
• Thanks for listening!
• Contact me
– kurt@kurtluther.com, http://www.kurtluther.com/
• Try my software
– Pipeline: http://pipeline.cc.gatech.edu/
– ProveIt: http://proveit.wmflabs.org/
• Fix my software
– Pipeline: https://github.com/kluther/Pipeline
– ProveIt: https://code.google.com/p/proveit-js/
36