Development Blog

This is the sixth of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Today we have a very special guest post Social Software Sunday.

Today’s Social Software Sunday is written by a good friend of mine, Jonathan Morgan. Jonathan is a graduate student at the University of Washington in Seattle and a member of the dub group. He studies online collaboration and recently worked on the design of ConsiderIt, the crowdsourced deliberation platform that powers the Living Voters Guide. He also blogs irregularly at newsfromconstantinople.com.

There’s a tendency among designers of social media platforms to believe that they can learn anything they would ever want to know about their users by looking at easily quantifiable things. Want to know whether your new question feature is popular? Check the logs to see how many people are using it. Want to know whether your site is sticky? See how long new users stay when they arrive on the front page for the first time.

Questions like these are easy to answer through aggregated behavioral metrics like hits, clicks, links and log ons, or through demographic data gleaned from IPs, webforms and on-site surveys. However, relying solely on such a ‘big data’ approaches to user research glosses over a lot of important information about how people actually use your site. There are other, tougher, sorts of questions that are harder to answer with quantitative methods alone, and that are nonetheless critical for effective design and evaluation of social media, such as  how are people using your comment board? What kind of questions get the most responses on your new Q & A feature? What kind of profile information do people share about themselves on your social networking site? What kinds of features will best support high-volume users?

Neglecting these kinds of questions and the user research methods that have been developed to answer them can get you into trouble for several reasons:

• Different user groups will use the same features for different purposes. Most social media platforms serve different purposes for different people. Some people use Twitter to advertise themselves to the world, while others use it to maintain an ambient awareness of the trending topics in their field. Still others actually use it to communicate with a distributed group of friends and colleagues (despite claims by some bloggers that it’s purely a marketing vehicle), and many people fall somewhere in between. Not all of these user groups will benefit from every potential new feature, and some people might even find certain features make it harder to do what they want with Twitter. Likewise not everyone is looking for the same kind of experience when they ask or answer a question on Quora. As designers, we need to be aware of the different user groups that are out there, how they use our software, and which users and uses we want to explicitly support.
• The features that get the most traffic aren’t necessarily the ones your users value most. Facebook is probably to most visible example of how to make sweeping design changes that royally piss off your user base. They may be somewhat bulletproof (for now…) when it comes to feeling the adverse impacts of their constant fiddling with our privacy settings, but you can’t count on your own site being so indispensable. Due diligence calls for at very least understanding the functions or features that your users hold dearest, and often these come down to deeply-held values (like privacy and trust) that you can’t easily detect with an algorithm or represent in a graph.
• Users will use your site the way they want to, despite your best intentions. The main advantage of social media is their flexibility, which sometimes means that people come up with novel ways to use them that their designers never intended. MySpace wasn’t designed to provide cheap web hosting for up-and-coming garage bands, but once they started losing people to Facebook, they came up with a variety of features that supported this use.

The actual content of user-generated content–the things people say, upload, tag, bump and ‘like’–is often treated as a black box by those who design and evaluate social media, unless it happens to be a kind of content that is easily machine-tractable. One simple example of a feature that probably wouldn’t have happened without someone actually paying attention to how people use their service is Twitter’s @replies feature (since renamed @mentions). @replies would never have been implemented if someone at Twitter hadn’t looked at some tweets and realized that a lot of people were putting ‘@‘ in front of messages directed to particular other users and decided to facilitate that use by hyperlinking the replies and adding notifications to let people know they had been mentioned in a tweet.*

But I think that the case of Twitter is an exception. In many cases, the deepest analysis that user-generated content like the text of a tweet or status update ever gets from SM platform designers is an automatic scan for keywords and links related to current events, trends, etc. To some extent, this aversion to actually looking at this messy human-created content is understandable. For one thing, the volume of text entered into a platform like Twitter, Quora or Facebook is staggering, and human speech, even text-based speech is highly variable and contextualized. After all, people didn’t put it up there for you to glean actionable design insights from. Most of your users probably aren’t going to post direct statements about your interface like “If only this damn comment box allowed rich text formatting I would use this service much more often and be willing to pay for the priviledge even” in your interface itself.

But it’s still a shame, because directly examining what people say and do is one of the best ways of understanding their motivation for saying or doing it. And understanding your user’s motivations, as everyone knows by now, is invaluable for deciding what functionality to add, what interface tweaks to make, or why no one seems to use your new ‘poke’ feature.

You can get at some of these kinds of questions through traditional qualitative methods such as interviews, open-ended surveys, usability tests and focus groups, but these take time and money–making them hard to justify within companies working in the web application world of limited startup funding and rapid deployment cycles. These methods also have the disadvantage of providing findings that seem hard to generalize and turn into concrete design recommendations, since these findings are often anecdotal and contextual, and the sample size is usually small.

While these disadvantages are too often overstated, a more fundamental difficulty of applying these methods to the use of social media is that they elicit information from the user outside of the normal context of use. Because social media are by definition communication platforms, methods that focus on single-user interactions with an interface (like usability testing) or ask users to describe their online experiences and behaviors after they’ve logged out (like interviews and focus groups) can’t always answer your ‘why’ questions any better than quantitative metrics can.

But there are other ways of making sense of user-generated content and gleaning design insights from it that. Content analysis for example, is a lightweight, flexible method for breaking down data that’s too complex to be automatically detected into manageable categories and making comparisons between them. Content analysis has been used in academic disciplines like communication, political science, sociology, psychology and health sciences for decades, and is commonly used in human-computer interaction research today to complement quantitative methods like social network analysis and behavior trace logs.

Content analysis ‘coding’ can be very quick and dirty and still yield interesting results: check out this study of Twitter that classifies tweets according to their purpose. It can also be performed in a more or less structured way: simply having the temerity to actually read through some posts, comments, uploads or tags and picking examples of interesting behaviors to share with the rest of your team can be quite illuminating. On the other hand, there are also more elaborate content analysis coding schemes out there that require some training to employ consistently, but which can allow you to identify and tally certain kinds of user behaviors, infer the motivations behind those behaviors, and even run stats.

However you do it, content analysis methods can facilitate the identification and measurement of socially meaningful behavioral cues can shed light on how groups of users interact with and through technology. Content analysis is an effective method for surfacing user wants and needs and for testing specific design decisions, and should be a part of a the methodological toolkit of any researcher or practitioner tasked with the evaluation of social media.

*Note: I don’t claim to know exactly how Twitter became aware of the ‘@‘ phenomenon, although I would be fascinated to find out. Perhaps they use the service themselves, or got direct requests for the functionality from users rather than poring over tweet logs.  Regardless, read this interesting post on the Twitter blog to read a good example of how the good folks at Twitter make usage and user feedback drive design–they obviously take a mixed-methods approach to user research. Not all designers have the benefit of being in the community they’re designing for though (Remeber: you are not your user!), and you can’t rely on users to always tell you directly what they like about your platform or why they like it–so observation is key.

To read more of Jonathan’s writings, you can visit his blog or twitter page. To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

This is the fifth of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic.

Over the last 6 weeks, I’ve been working hard to get the Product Design Guild off the ground. The Product Design Guild is an event for designers where they can bring in work they’re doing in their everyday jobs and engage in collaboration with other designers. We held our inaugural pilot yesterday at pariSoma with the generous support of 500 Startups (with special thanks to Enrique Allen who is a hidden gem on the 500 Startups team). It was immensely gratifying to see that our intuitions were correct and we managed to put on a truly special event. It’s self-aggrandizement of the lowest order for me to explain how my own event was awesome so, instead, I’m going to let pictures do the explaining for me:

I think it’s clear from these shots that people were seriously invested in each other’s work and that deep thought and reflection (as well as fun) were taking place.

I’ve already spilled many words on why the guild exists and what values it operates under. I thought I would spend some time in this post laying out some of the design decisions & principles that went into the formation of the guild, how those worked out in practice and learnings which are going to be applied back in the next iteration. A quick plug, I’ll also be talking about this along with other social experience design stuff at BayCHI on Tuesday, November 9th at Xerox PARC. Please drop by and say hi if you’re interested.

Design Principles

It seems like an eternity since I first sat down with Brian Gupton to map out how something like a Product Design Guild would work. It’s hard to imagine it’s only been 6 weeks to move from conception to reality. Brian was the one who originally set up a meetup group and bought the domain name and started promoting the idea. I thought the basic idea had promise but I could see that if it continued along that path, it would devolve into something not especially compelling. I was already starting to formulate some of my ideas around the Evaporative Cooling phenomena and I wanted to design to support a community that would grow better over time instead of devolve.

The most apt way of summing up my design philosophy is paranoid in the long term but pragmatic in the short term. Operating from a position of extreme ignorance, I don’t believe it’s practical to do anything but idly day dream about features too far into the future. When I was promoting the guild, people would ask me “How often are you holding them?” or “Are you planning on getting your own space someday?” and my answer was always “I’m focused on the first pilot right now. Once we hold it, we’ll know more”. At the same time, many of the flaws I saw that caused communities to fail were baked into the fundamental structure at the very beginning. When designing the guild, I continue to be paranoid about how decisions that are expedient in the short term may end up causing long term harm. Thus, the main design that I was doing was establishing the basic structure and crafting the rules which would start to scaffold the social norms.

My guiding inspiration when designing the Product Design Guild was focused on how we can provide value to the very best designers in the industry. This is a hard problem because the very best designers are hard to even reach, let alone persuade. They are busy, they have a good network and have enormous demands on their time. In order to capture them, we have to figure out how to provide them with enduring value and solve the problems that they care about. While all of the design events I was aware of focused on education or networking or job hunting, the thing that all designers (including the great ones) still cared about the most was work and work was something the design community thus far has failed to grapple with. I figured, if we could make even the best designers more productive at their everyday jobs, then they would find value in that since it gave them more time, not less if they chose participate.

Part of my hypothesis about why work was a difficult area for design communities to crack was that the activation energy was simply too high. Work is assumed to be confidential by default and involves multiple stakeholders, most of whom are risk averse. To get two people, not working at the same company to work on the same problem requires enough red tape that it’s just usually not done. By focusing on startups & freelancers at the start, we simplified the problem by aiming for those who have the least to lose from sharing and the most to gain. At the same time, by collectivizing the agreement, it only had to be made once, at the start of the meeting instead of n^2 times for each pair of participants. This was the impetus behind the last 4 rules that we established:

• Seek permission from all of your stakeholders before sharing: Don’t sneak work into the guild under your client’s or boss’ nose
• We operate under the FriendDA: Seek explicit permission before sharing anything you saw outside of the guild
• Disclose any possible conflicts of interest before collaborating: It’s up to the requester to decide whether to proceed
• Any guild work you do belongs to the requester: The requester is free to use it however they like without reseeking your consent

Not all work can be shared with the Guild and that’s fine but the hope is that by providing this durable social contract, we can begin to streamline within companies the process of inter-company sharing (for example, work might be split into confidential, OK to share with the Guild & OK to share with everyone). I think we saw at the first pilot that confidentiality was not perceived as that big a deal but I think it’s going to be something that will grow in importance as the guild evolves and grows.

The next decision I made was that the event should be exclusive rather than free-for-all. Exclusivity was not so much about increasing the average quality of the group so much as the minimum. Because each member in the group was hand selected, people started off knowing that any random person they were talking to possessed some minimum degree of design insight and that they could start from a platform of mutual respect. Design conversations could proceed at a high level rather than starting off by feeling out how much expertise the other person had. I call this the difference between “literate” and “illiterate” cultures and it’s something I plan on expanding upon in a later post. Of course, exclusivity is easier said than done. In order to get the 30 people who were at the first pilot, we had to drive over 100 people to sign up and then cull the list down to 50 people who we considered good enough for the pilot. This involved lunches, dinners, drinks, emails, phone calls and many hours of me tapping into my own personal network and cashing in favors.

As a sidenote, it really demonstrates the unique, meritocratic nature of Silicon Valley that someone like me, a newcomer who’s only been here for less than 6 months was able to build up such a strong and wide network. During the months that I was on the job hunt, I spent a lot of that time meeting as many people as I could and trying to be helpful to whoever I was able to, without expecting anything back. This phase has paid itself back in spades as virtually the entire pilot was spread due to word of mouth recommendations from friends I had personally sold. I don’t think there are many cities where such a thing could have been started by such a newcomer.

The other thing I really focused on baking into the system from the start was the appropriate “social gatings”. Social gates are factors about the community that allow other people to self-select as to whether they want to be members or not. Of the people who become aware of your community, who decides to join is largely a factor of the social gates you put in place. For the Guild, there are currently 3 explicit social gates in place:

• You need to bring work: This is a place for work to be done. There is no room for tourists
• Give before you receive: We want this to be a community for contribution, not a resource for exploitation
• Be articulate about what you can offer: We are looking for people who can contribute to the education of fellow designers

If you’re a great designer, you can mentally list out the types of people that you would dread running into at an event like this. They are the social parasites that end up sucking value out of the community rather than contributing. Each of these rules was designed as a way to gate the community such that these people would feel unwelcome even considering applying. Looking at the people who signed up for the pilot, our social gating appears to have been pretty effective. The quality of the submissions was almost universally high and only about 10% of our list were people who we clearly were not looking for. Even the people that we wait-listed were all very high quality designers who we only excluded due to lack of space in the first pilot. What I also thought was really interesting was that we got roughly 6x the number of Facebook “Likes” for the guild compared to tweets. What I believe is that the social gates managed to give off the correct air of exclusivity & intimacy that caused people to want to share with their closest friends rather than everyone in the world.

Learnings

There were a couple of things that came out from the pilot that we’re going to feed back into the next iteration. Probably the biggest one is what I call the “ramp-up” phase. Before two designers can start working together, there’s a good 20 minutes where the outsider needs to be brought up to speed before any productive contribution can be made. After 20 minutes, only the most shallow advice can be given at the highest level. Truly ramping up to being on the same page about a problem could take weeks for a particularly intricate problem. The ramp-up is necessary for collaboration but it’s purely non-productive time. Not only was ramping up time consuming, adding a new member to the group meant you had to re-ramp up the group which took even more productive time away from working. This made it hard to leave & join other groups because the act of joining a group would cause a productivity hit.

At the first pilot, everyone spent a significant amount of their time just ramping up because all of the projects and people were new. This is OK for the first pilot but, for the PDG to be sustainable and scalable, we need to figure out ways of more efficiently ramping people up. One thing I definitely want to do for next time is to allow people to demo rather than just explain the work they brought during the first intro period. Another idea I want to explore is to push the ramping up period into the pre-event phase by having people post what they’re working on online and allowing others to find people they should be connecting with. Finally, since explaining your work is a relatively scalable task, a designated “show & tell” phase during lunch and opportunities for everyone to switch around could also help.

Another really powerful pattern we saw was what I call “Human expertise routing”. The most helpful thing I think I did at the Guild was not directly helping someone but recognizing that their need matched the expertise of another member and introducing the two. I want to explore different ways of encouraging people to serve as this human expertise routing network as something that provides real value.

Finally, something I want to explore further is what phases of design is this type of collaboration most ideal for and what is the limit of what this format can provide? Anecdotally, coming up with new feature requests was the most popular design activity but it’s also not that compelling since most products suffer from an excess of features, not a dearth. I think it has value in other areas but we need to push people to move into them.

Failed experiments

The nature of prototyping is that there should be failures and that failures should be used to learn and feed back into the next iteration. There were two ideas that ended up being dismal failures. The first was the idea of using colored dots on nametags to indicate what expertise a person had. Application was inconsistent, it was impossible to remember the color codings and nobody seemed to pay attention to them.

The second was the idea of supporting impromptu “masterclasses” where people could gather to go into more depth about a particular topic. That ended up being a massive bomb from the very beginning. I put down an example masterclass but I couldn’t even get a single person interested. After my very public dismal failure, nobody else even bothered. I think part of it was that the language was intimidating. “masterclass” sounds like this big, sophisticated heavyweight thing that wasn’t really in line with the tenor of the rest of the event. The second was that I think it was thrust on people too quickly. I think people needed some time to figure out what it is that they could offer. Finally, the risk to reward ratio was skewed by my failure. For the next event, we’re going to change the language to “birds of a feather”, allow people to propose and sign up for them ahead of time and explain the entire concept a lot better.

Future experiments

For the next meeting, we’re going to be focusing on learning more about the following areas:

• How do people work now that they’ve already done the getting to know you stuff?
• How do we integrate new people into the group? What is their experience?
• What happens after the “new and fun and shiny” phase? Once you get past the novelty, what is the enduring value we provide?
• How quickly can we scale? What are the effective mechanisms for doing so?
• How do we lessen the amount of time spent in ramp up and make teams gel more efficiently?
• What are the ways clever technology can be used to augment the guild experience?

The design of the second guild meeting is going to be centered around learning from these questions.

Conclusions

This is but the first significant step for the Product Design Guild. It’s been enormously gratifying so far that every early indication seems to be pointing to this becoming a success but there’s still a lot of trials and obstacles along the way. We are currently tentatively scheduling the next event for early December and I’m excited to see this idea evolve.

To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

About a month ago, I asked on Quora Why is there such a stunningly short supply of designers in Silicon Valley right now? This question lead to an amazing amount of high quality discussion, both in the answers to the question and in followup questions that it spawned. This question was also what provided sufficient impetus for Brian Gupton & I to start the Product Design Guild. Coming full circle, a followup question was asked today, What are some ways a designer could best take advantage of the short supply of designers? In answering it, I took the time to delve into a lot of the reasoning behind starting the Guild in the first place and also everything I had been learning since then. I thought it would be valuable to replicate this here:

In a market based economy, the most obvious short term tactics for a designer right now are:

• Ask for more money
• Ask for more responsibility

I’m going to argue actually that these are actually detrimental moves in the long run and that extreme imbalances in demand can, paradoxically, be bad for both designers and the design profession as a whole.

Demanding more compensation purely due to market conditions and not because you’re getting better as a designer means that you’re increasing the value captured:value delivered ratio. As this ratio approaches 1, you become an increasingly bad deal for smart companies and only companies ignorant enough to be overpaying for design are willing to hire you. This is an ultimately unsustainable practice which sours companies on the value of design and sets back the progress we’ve been making over the last few decades, demonstrating the importance of design as a a competitive business advantage.

You can see this happening already. Enthusiastic but way too junior designers are being offered “Lead (and only) Designer” roles at hot startups for lack of more experienced candidates. This may sound like a fantastic deal to the designer in the short term but they’re ultimately not ready for that role. The design that they produce are unrefined and immature, not delivering value to the company commensurate with their responsibilities. This ends up with both sides being unhappy and delivers a “poor user experience” to the company that impacts how they treat design in the future.

Instead, I counter-intuitively have the following advice: figure out a way to increase the total sum value of design in the world as a whole and your slice of the pie will rise commensurately.

I’ve been thinking a lot about these issues in the past month as we’ve been setting up the Product Design Guild. I’ve spent time talking to designers, entrepreneurs & investors and trying to understand how the Guild can best serve to help designers flourish.

What I think this means for designers in more concrete terms is:

• Fight for design to have it’s rightful seat at the table. One advantage of designers being a hot commodity is that we can fight for real political change or threaten to walk. Rather than focusing on salary, focus on impact and choose companies which understand and respect design and let designers have the necessary independence & influence to make a meaningful change in the product.
• Set aside time for education and self-improvement. As more and more responsibilities are piled on designers, it can be tough to carve out “non-productive” educational time. With tight deadlines approaching, it’s easy to efficiently crank out something you already know how to do for this next release and save the long term stuff for a later date. Except that later date is never going to come and you’ll realize that it’s 5 years later and you’re still churning out the exact same designs you were 5 years ago with your now rapidly obsoleting skill set. Designers need to push back against demands on their time and assign equal importance to growth as production. Use the clout you have now to fight against overly aggressive ship dates and over-demanding bosses. Take time to attend design events, read broadly, pursue creative hobbies and generally living an interesting & meaningful existence.
• Leverage your talent as much as possible. This means focusing on trying to do more with what you have and being as efficient and effective as possible. Part of what differentiates experienced practitioners from novices in any field is a grace of action and conservation of motion. Only the minimum amount of effort is needed to accomplish a task and every action is streamlined down to it’s very essence. Be diligent about figuring out the most effective way to accomplish something. Learn all of the tricks and techniques that most effectively leverage the talent that you have. To this day, the best way of doing this is focused exposure to great talent. Jared Spool talked about this at the Warm Gun conference last month, junior sushi chefs in Japan go to work for master sushi chefs, doing scut work. Even though they never make sushi until very late in their apprenticeship, simply being around and observing master sushi chefs do their work is essential experience for becoming a master sushi chef. Similarly, junior designers should figure out a way to be exposed to experienced designers and simply observe how much more effortless design is when experience is gained. Without this knowledge, junior designers don’t even know what to strive for.
• Recruit more great designers. It may seem paradoxical that bringing more competition for your job helps you in the long run but the demand for great designers is so extreme right now that even increasing the supply fourfold would not measurably affect your bargaining power. The current market is also extremely inefficient. In talking about this, many people both outside and also inside Silicon Valley are completely unaware of the extreme demand for designers. There are many capable designers locked up in big companies right now or working in other cities that could be persuaded to take the leap if given the right push. Similarly, there are a lot of people in product management, engineering, art & content production that have design aspirations but no clear path to becoming a designer. Recruiting all of these people into the design profession by selling how it’s both satisfying and rewarding can is only going to influence the power of design.
• Take care of the design ecosystem. Historical trends in the last decade have not been kind to the design ecosystem. Design school education is becoming increasingly irrelevant to the fast paced and unique needs of Silicon Valley. Smaller team sizes means that many designers are now working as the sole designer on a team, without the ability to collaborate or learn from other designers. Even for companies that can still afford to maintain a design team, lower job loyalty means that mentorship becomes a losing economic proposition. Taking away productivity from your senior designers for mentorship only to have your junior designer take off and apply that learning at their next company makes you feel stupid the second or third time it happens. Where are we going to get our next generation of designers if this continues to be the case? The only way to fix this is to take time to contribute back to the design eco-system. If you’re a senior designer, take the time to mentor junior designers, even if you never directly benefit. If you’re a junior designer, work in co-operation with other designers instead of in competition. For designers overall, push to be less proprietary about your work and offer to share what you can with anyone who is interested.
• Finally, spread the message. One designer, working alone can make an individual difference. One designer, mobilizing a thousand can affect real change. To make companies take notice and effect meaningful reform in the role of designers can only happen if the hear a clear and consistent message, coming from all angles. Designers are in a unique position right now where they hold a lot of potential power due to the extreme demand for designers. We should be taking advantage of this to make design a valued and sustainable profession that can keep us all happily employed in the long run.

The Product Design Guild is our attempt at addressing the issues that I’ve just outlined. Our ambitions are small to begin with but everything I’ve articulated is something that’s very much present in our thoughts as we figure out how to grow and develop the guild. If you’re interested in finding out more or want to participate, I encourage you to visit http://www.productdesignguild.com. I believe we’ve managed to strike upon a very compelling concept and I’m passionate to see the Guild affect meaningful positive change in the design ecosystem.

This is the fourth of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic. To vote on what I should write about next, go to this Quora question.

This is going to be a relatively short post this week. I wanted to talk about a specific social mechanism that has promise and a few interesting areas where I’ve been toying with applying it. I’m going to call the social mechanism the “kickstarter mechanism” even though it obviously predates kickstarter.com.

The kickstarter mechanism allows people to perform contingent social actions. That is, they can make social promises of the form IF x, THEN y. On kickstarter, this promise manifests itself in the form of IF total promised donations exceed $limit, THEN I will donate $promise. Contingent social actions are an interestingly powerful tool because they cause incentives to line up in nice ways. In kickstarter’s case, the donor is mitigating the risk of a project not being serious by only committing to projects they know have a lot of energy behind them. In the requester’s case, they can gauge interest without having to commit to doing something until they’re sure a market exists.

Now, kickstarter style negotiations have been around since pretty much the beginning of negotiations. However, the beauty of moving it online is that computers happen to be uniquely suited at enforcing contingent promises.

There’s two ideas I’ve been loosely toying with over the last few months that have kickstarter mechanisms embedded in their core as a way of constructing interesting social spaces (the reason I’m not pursuing either of them is that they’re both basically features, not products):

Event Planning App A:

The first one is not too interesting and I’m sure someone has already built it. It allows people to create speculative events with their friends. Say I’ve wanted to go to SFMOMA for a while but it’s pretty low on my list of priorities. I’m sure there are other people in my friends circle who are in the same situation. Knowing that they would also be interested in going would be enough to spur me into action. What I could do is post a speculative event which says “If at least 5 people agree to this event, then we will all go to the SFMOMA together. If less than 5 people agree, then none of us will go”. It’s basically kickstarter applied to events.

Trial Balloon:

This is far more interesting to me. Trial Balloon is an internal corporate feedback tool designed for the giving of “risky” feedback. There are certain types of feedback where giving it might bring benefit to the company but could cause professional damage to your own career. Anything from “we should bring back free sodas to the breakroom” to “our marketing strategy is terrible and alienating our customers”. Typically, even for employees who want their company to do well, such feedback isn’t given because personal incentives aren’t aligned.

The way it works is that any employee of a company can leave feedback and it is initially anonymous. Other employees can also choose to agree with the feedback and they, too are anonymous. However, when enough people agree that it “kicks” over a pre-determined threshold  (this can be either determined by the poster or by the system in a clever way), everyone becomes unanonymous at the same time. Furthermore, the order of the names is randomized so it’s impossible to determine who posted the feedback in the first place.

Trial balloon allows you to leave safe feedback because it makes the powerful bit happen first and the dangerous bit happen only in contingent circumstances where they are substantially less dangerous. It’s more powerful than fully identified feedback systems since it allows for a wider range of feedback to be given but it’s also more powerful than purely anonymous feedback systems because the people agreeing have all agreed to stake their professional identity behind the statement if the conditions are met.

Some very rough wireframes:

Conclusion:

Kickstarter mechanisms are an interesting tool to have in your toolbox if you’re designing a social application. If applied in the right way, they can greatly encourage participation by shuffling the commitment and risk around in interesting ways. I hope this post provides inspiration to some of you building social apps about how to make them more socially graceful and human using kickstarter mechanisms.

PS: If you’re thinking about building either of these, please email me at hang@bumblebeelabs.com. I’d love to see them in the wild and I’ve done quite a bit of thinking outside of this piece which may help you avoid going down some blind alleys.

To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

This is the third of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic. To vote on what I should write about next, go to this Quora question.

And one day the wizards of LambdaMOO announced “We’ve gotten this system up and running, and all these interesting social effects are happening. Henceforth we wizards will only be involved in technological issues. We’re not going to get involved in any of that social stuff.”

And then, I think about 18 months later — I don’t remember the exact gap of time — they come back. The wizards come back, extremely cranky. And they say: “What we have learned from you whining users is that we can’t do what we said we would do. We cannot separate the technological aspects from the social aspects of running a virtual world.

Clay Shirky – A Group Is It’s Own Worst Enemy

Social software is deceptive because it looks like conventional software but does not behave like conventional software. You can take a piece of social software and it seems possible to analyze it in terms of feature set, user experience, traction and all the conventional tools used to analyze software. But to do so fundamentally misses it’s essential nature. It is impossible to split social software into a technical system as distinct from a social system and analyze each piece separately. Instead,  all social software are inherently socio-technical systems.

To illustrate with an example (borrowed from Latour), let us assume that we have a road in a quiet residential area in which the main problem is that cars drive too fast down down it. There are at least two possible ways of solving this problem: adding in a speed bump or adding a “slow” sign at the start of the road.

Speed bumps provide an obvious physical mechanism that forces cars to slow down: driving too fast results in an uncomfortable jolt and possible damage to the car. If we were technical analysts, we would totally understand through decomposition, the purpose and mechanism of speed bumps. But a “slow” sign has no intrinsic property of slowness about it. Using technical decomposition, we can see that the molecules of the “slow” sign barely interact with the molecules of the car. Instead, “slow” signs operate purely due to the social mechanisms that society has set into place. I know that if I were to run a slow sign, there is the possibility of a policeman catching me and this could lead to a large fine which would ruin my day (not to mention my social conditioning to be lawful regardless of circumstance). Both the speed bump and the slow sign achieve roughly the same goal but through two very different mechanism.

Likewise, with all social software, only part of the mechanisms that ensue success are encoded in the technology platform. The rest of it is encoded in the social mechanisms of the community of users who are running it. Rather than analyze social software from the perspective of features and code, it is instead, far more correct and useful to analyze it in terms of what mechanisms are necessary for the software to succeed and only after that, to figure out which is the correct place to put them.

This makes social software a very different beast from conventional software because social software runs on humans in conjunction with machines. While machines can be manipulated by typing words into a text file and hitting compile, humans are much more finicky and dynamic (although, it the case of some game dynamics, almost as easily predictable and reliable). What this means is that every piece of social software has a huge chunk of it which has both limited visibility and is constantly in flux. What’s more the same code base running on different communities leads to intrinsically different pieces of social software and lessons learnt from one community cannot be directly applied to any other. On top of that, while only the developers have the privilege of checking in source code, any particular user can affect the social norms of a community. Unless you start development with these realities baked into your understanding of the world from the very beginning, you cannot produce humane social software.

The most visible arena where social software fails is as communities scale. Small, tight knit communities are capable of having a rich social layer and good communities manage to practically design themselves with merely the benign neglect of the software creators. However, as communities grow, the social fabric becomes weaker and weaker and less capable of supporting sophisticated mechanisms. Unless technical solutions are put into place, the community degrades into an underwhelming mess.

Last week, I talked about the Evaporative Cooling Effect and how one way to mitigate this is by unequal reputational roles for different members. In a small community, it is possible to do this purely through the social layer. Participants are able to remember who has particularly good domain expertise, who displays generosity and kindness & who is abrasive but knowledgeable.  Rich mental models of reputation are formed and different members in the group will be treated in different ways, abusive behavior will lead to shunning and admirable behavior will lead to respect. But there are intrinsic cognitive limits to how much reputational information we can hold and process (Dunbar’s number is commonly cited in this, usually incorrectly). Once communities exceed this limit, the ability to provide reputational distinction through purely social norms becomes impossible. Instead, reputation must be augmented through technical means (action logs, karma, reviews, etc).

However, overdeveloped technical systems can often be a much bigger problem than underdeveloped technical systems. It’s a common failing for technologists that to see software as the hammer that can hammer in every social nail. Access control and privacy is a perfect example of this kind of thinking.

Access control mechanisms are often developed under the assumption that no social layer exists whatsoever and all access control must be done purely through the technical layer. While this leads to cleanly analyzable assumptions and formally verifiable proofs, it also leads to rigid and inflexible access controls systems which do not at all map onto people’s actual work patterns. This, ironically means that workers routinely bypass the technical access control mechanisms anyway and routinely email “confidential” files around and rely purely on just social mechanisms to prevent unwarranted access.

This same security thinking has been applied to our consumer social arena with even more absurd results. Technologists love to crow on about how “privacy is dead” and that they now live their lives in a purely binary completely-in-public or not-on-the-internet mode. In reality, most of our sharing is done through mediums with rich social layers through which we use to mediate our privacy. While celebrities and occasional unlucky people thrust into the limelight end up having their private lives completely exposed, the average person still goes through life without any significant privacy violation because they manage to effectively modulate the social norms around privacy. Drunk party photos of them exist on Facebook but, as long as they take care not to friend their boss, none of their friends are assholes enough to be actively forwarding those pictures along. Facebook itself seems to fundamentally misunderstand at the most basic level and this is reflected in their byzantine privacy settings which were an attempt to encode all privacy data in a purely technological fashion. This is a topic worthy of a completely separate post so I’m going to punt on the discussion for now.

The only effective way of building social software is to view code and policy as two sides of the same coin. To build a successful social system, what is needed is to establish what are all the requisite mechanisms that are required for a successful social design and then figure out how to keep those mechanisms in place, via either the technical or social layer regardless of how either of them morph. This leads to a fundamentally different way of building compared to conventional software and is a large part of the reason why so many technologists struggle so much, building compelling social experiences. Too often, people who analyze social software systems only look at the technical aspects because those are the most visible, stable and generalizable and completely ignore the morphing social contracts that are happing at the same time. But doing so leads to unbalanced design which either does not provide enough technology to support the social layer or ignores the powers of the social layer and overcompensates with inflexible technology.

To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

I’ve been spending the last hour with a friend batting around potential startup ideas he wants to do around photo sharing. After brutally castigating him about how every one of his alternatives seemed uncompelling, I think I finally analyzed the nub of my disagreement.

His basic thesis was that photo sharing is a compelling activity because so many people are taking so many photos these days so there must be some way to capitalize on that trend. My response is that I’m unconvinced that there actually any people in the world who enjoy the intrinsic process of taking & sharing photos. Instead, photo share is an instrumental step as a means of achieving some intrinsic goal.

I share photos of me on vacation to prove to my friends that I’m an interesting person. I share photos of something funny that occurs because I want to amuse my friends. I share artsy photographs on flickr to prove to people I’m good at taking artsy photos. In all cases, photos are just the shortest and most efficient way for me to achieve the goal I want.

I made the following analogy: It was like if you were casting around, trying to invent the next big sport and you decided that it had to involve long sticks. The reason being, you have observed that many traditional popular sports involve long sticks. This may lead you to the next great sport but it is unlikely. Instead, it is far more productive to analyze the purpose behind long sticks in sport (as a lever that allows you to accelerate objects at far higher speeds generally) and find a way to deliver on that experience, whether it involves long sticks or not.

This is the second of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic. To vote on what I should write about next, go to this Quora question.

The people who most want to meet people are the people who the least number of people want to meet. The people who are the most desperate to date are those who the least number of people want to date. The people who are the most eager to talk are the ones who the least number of people are interested in hearing. It is the ignorance of this fundamental principle that I see at the heart of so many failed social software designs. This is what I call the Evaporative Cooling problem and one I believe must absolutely be tackled head on by the designers of any communal gathering product unless they want to see their product descend into a squalid lump of mediocrity.

The Evaporative Cooling Effect is a term I learned from an excellent essay by Eliezer Yudowsky that describes a particular phenomena of group dynamics. It occurs when the most high value contributors to a community realize that the community is no longer serving their needs any more and so therefore, leave. When that happens, it drops the general quality of the community down such that the next most high value contributors now find the community underwhelming. Each layer of disappearances slowly reduces the average quality of the group until such a point that you reach the people who are so unskilled-and-unaware of it that they’re unable to tell that they’re part of a mediocre group.

Evaporative Cooling is a dynamic that can apply to both real world and online communities but the affordances of the Internet make it particularly susceptible to Evaporative Cooling. By looking at real world social structures, we can get some clues as to both what causes Evaporative Cooling and what are effective ways of preventing it.

Example the first:

Moving to San Francisco, it was amusing to me, unearthing the social structures around networking that go on here. There is the public “scene” of parties, events & mixers. Alongside this is an entire shadow community of private, invite only, exclusive events which is where all the real work in the Valley is done. It is possible to live your entire life in the Valley, wandering around amicably being blithely unaware of the shadow ecosystem. You could go to the same events every week with the same mix of aspiring entrepreneurs, social media marketers, CEOs of dipshit companies, bloggers & the occasional A-Lister who is forced to be there out of professional obligation.

But, if you’re halfway decent and capable of networking, you’ll soon find yourself with an entrée into a small part of the shadow economy. How far down the rabbit hole you choose to go is purely a function of your innate function and drive. For every layer of exclusivity, there’s almost certainly one more exclusive that you’re not aware of. Some of these venues are well known; TED, Davos, Sun Valley. But for every one of these you’ve heard of, there’s certainly at least a thousand more equally as exclusive gatherings you haven’t. After a while, you start to subscribe to what I call the Groucho Marx rule. You stop attending any event which would have you as a participant.

Lesson the first:

Openness is a major driver of Evaporative Cooling. If anyone can join your community, then the people most likely to join are those who are below the average quality of your community because they have the most to gain. Once they’re in, unless contained, they end up harming the health of the community over the long term. Communities that are allowed to select their members in some way are much more immune to Evaporative Cooling. Unfortunately, most viable internet businesses have no choice but to set their business model to open. The nature of most Web 2.0 businesses is that they depend on extracting a tiny bit of value from a large number of users and are betting on their fuck you exit from massively exploding in scale. Building a thriving community that tops out at 10,000 members over the course of 10 years isn’t going to pay the bills.

Example the second:

One of the communities that I’m part of down here is BayCHI. It’s a community that’s been around for 20 some years now and the quality of the talks and people who attend is still excellent. It seems to have only minimally succumbed to Evaporative Cooling. Why is this? A large part is due to what I call Social Gating. Social Gatings are mechanisms that allow participants to self-select out of the group. In the case of BayCHI, the social gate was the nicheness and unglamorousness of the content. The only people who would choose to participate in this group in the first place are those who find the talk sufficiently interesting to take 3 hours out of their life. This, by itself set a minimum bar.

Lesson the second:

Social Gating is a powerful force and, unlike direct exclusion, works in a much more scalable fashion at Internet sized growth rates. However, it is also a much more subtle one and requires a deft hand to get right. Nicheness is just one possible social gate, charging money is another popular one. But there are an entire constellation of more nuanced ones. Spelling, for example, is an interesting social gate. Just seeing a forum in which ppl spel liek thiz instantly polarizes you onto one side or the other. At the other extreme Quora, in it’s very early days had an incredibly Orwellian system in which Quora staff would routinely directly edit the contents of your answer to fix spelling and grammatical errors. I’m planning to dedicate an entirely separate Social Software Sunday blog post to Social Gating so stay tuned (pro tip: If you want to see it faster, go to Quora and add it to the list).

Example the third:

Another event that I attended this week that had a remarkably high quality of participants was Warm Gun. Among the people in the room were the Director of Design at Facebook and the Director of Design at Google. How did Dave McClure get these two in a room? He put them on a pedestal, literally. They were invited to take part in a panel discussion on how designers & engineers could better work together and it was the inducement of special treatment that made these very busy & high value contributors deign to be in the same room as us design peasants.

Lesson the third:

Unequal roles of participation can help shift the gradient of power and kill the evaporative cooling. When the community is small, such processes can be managed through the social layer. High value participants are treated as special because they have recognition & reputation from the community. But, as the community scales, these social mechanisms break down and often, if nothing is done to replace them, high value members get especially miffed at the loss of special recognition and this accelerates the Evaporative Cooling.

Explicit reputation systems like karma are probably the most popular way online communities have implemented unequal roles. But, for some reason, online communities seem particularly resistant to the type of elitist promotion structure common in real world institutions. In Academia, high school students have to fight to become undergraduates. Undergraduates have to fight to become PhD candidates. PhD candidates have to fight to become adjuncts. Adjuncts have to fight to become tenured and tenured professors have to fight to become Dean. I can’t even think of a single online community that bears even the slightest resemblance to this sort of power structure. This is something to ponder for a later piece.

Example the fourth

Finally, I will examine what I consider to be one of the most successful technological systems ever at scaling while maintaining quality: Facebook. I joined Facebook when it was less than a million members. Since then, it’s managed to grow by a factor of 500 but the quality of my experience has dropped by only maybe 50%. The reason why is because when some random person is participating in Facebook from Brazil, it has an absolutely negligible effect on my experience. Because every user only ever see their tiny corner of Facebook, every user is in direct control of their own experience. Lest you think this is a property that is intrinsic to Social Networks, Orkut was brought down precisely by those random people in Brazil. Facebook’s design, especially in the very early days, was especially conscious of this design dilemma and designed around it masterfully.

Lesson the fourth:

There are two fundamental patterns of social organization which I term “plaza” and “warrens”. In the plaza design, there is a central plaza which is one contiguous space and every person’s interaction is seen by every other person. In the warren design, the space is broken up into a series of smaller warrens and you can only see the warren you are currently in. There is the possibility of moving into adjacent warrens but it’s difficult to explore far outside of your zone. Plazas grow by becoming larger, warrens grow by adding more warrens.

These are the two fundamental patterns of social spaces. Every social space can be decomposed down to a collection of plazas and warrens. In Facebook, your profile, friends and newsfeeds are warrens but fan pages, groups & events are plazas. Twitter is mostly a warren with the exception of trending topics which is the one plaza. On forums, the front page and topic listings are plazas but each forum thread is a warren.

Plazas and warrens both have their unique set of tradeoffs. Warrens are notoriously difficult to get started. New users, stuck in empty warrens often don’t know how to connect to hubs of activity. The onboarding process is crucial and still not well understood (Friendfeed found that people needed to add at least 5 friends to have a reasonable chance of sticking with the service). On the other hand, plazas only need to be started once and then they remain a hive of activity for new users to participate in from the first day.

Plazas are much more visible than warrens so it’s easier to watch and understand your community. In communities, like in justice, sunlight is often the best disinfectant and the neglected spaces often become thriving breeding grounds for all sorts of social pathologies.

But the one absolute killer feature of warrens is that they allow your community to become almost perfectly scale free and grow like mad without ever sacrificing quality. This alone, makes them a design element that’s heavily worth studying to figure out what are the good social designs.

It’s also interesting to note that the real world is intrinsically warren while the online world is intrinsically plaza. In real life interactions, the physics of sound mean that we can only ever talk to a few people at once. Every person gets a “personalized” social life. To give every person the exact same content takes special work. Online, the easiest model to program is to serve the exact same bits to every requester. To provide “personalized” content takes special work. It is interesting to observe how this difference has influenced the evolution of these two mediums.

Conclusion

Evaporative Cooling is a fundamental social dynamic and one that is corrosive to the long term health of communities. This post contains barely 1% of everything I could write about Evaporative Cooling but I’m already at 2000 words and I’m not looking to write a novel here. They say ideas are worthless and execution is everything. Since I’ve gotten to the Valley, I’ve heard probably close to 100 pitches for social products in random conversation. About half of them involved a meeting place dynamic of one kind or another and about 80% of those, as they were conceived, would be killed dead by Evaporative Cooling. It is absolutely essential if you’re to be designing a social product that you deal with this issue up front or you’re just a dead man walking.

To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

Over the past few weeks, I’ve been working on a small side project which I’m finally ready to announce:

The Product Design Guild is a space where designers bring in the work they’re doing in their everyday jobs and engage in a collaborative design process with other designers.

To find out more & sign up, please visit:

http://www.productdesignguild.com/

If you can, I would appreciate it if you could pass this on to any designer friends you may know, especially those in the bay area who are freelancers or working as the sole designer at a startup. We are hoping to making this a resource that improves both the quantity & quality of designers in the Valley.

This is the first of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic. To vote on what I should write about next, go to this Quora question.

The original impetus for this came from an impromptu Caltrain ride with Ben Newman, an engineer at Quora. During that ride, we had an interesting conversation about Quora’s particular attitudes towards humor (they’re pretty dour) and why that was the case. As it turns out, the Quora staff had thought pretty carefully about the nature of humor and its effects on communities and their operational procedures reflect a certain set of beliefs they hold. I’m not going to attempt to speak for Quora based on a 20 minute conversation a few weeks ago but some of their thinking did remind me of some of the stuff I had also been thinking about with regard to humor on the web.

The Internet has a citizenry. Like how some people self identify has African-American or Asian-American, there is a subset of the population for which it would be most accurate to label them Internet-American. Not everyone who has ever been on the Internet is part of this group. Most people are merely tourists or commuters, they come in, they visit a while but, at the end of the day, they go home to their real lives. For the Internet-Americans, the Internet is, at least in part, their real lives and meatspace existence is the culturally foreign experience.

Like the founding of any new migrant nation, the citizenry of the Internet is a motley crew. Some were lured by the promise of virgin lands, yet to be explored, others by the promise of a new identity. But like any new settlement, by far the most dominant were the people who arrived to escape the oppression of their homeland. They were the ones who felt under appreciated, misunderstood, ignored or abused by their real world peers and found refuge among their kin online. Together, they built an alternate culture, one that was a deliberate snub against those who had rejected them. It is from these foundations that a particular strain of Internet culture was born and the effects of this evolution are still felt online today.

To fully explore the extent of this would be it’s own, separate, mammoth task. For this post, I’m solely going to look at the ramifications of such an evolution in the context of humor and how it has become operationalized in a way that may seem unfamiliar to those who are not citizens of the Internet.

In real life, almost all of our opportunities to deploy humor are with people who we already know or would like to know better. While we use humor for many purposes, we crucially care about the reaction from the other person. For the most part, humor is deployed to give other people pleasure.

On the web, the affordances of the interaction are different. Most of our online interactions are with people we do not know and cannot fully empathize with. Humor shifts from less of a bonding activity and into more of a performative one. This is not entirely without precedent in our offline worlds. If you listen to interviews by prominent comics about their childhood, often they turned to humor as a defense mechanism. It was a way they discovered to deflect harm or attract attention. Humor was a way for comics to validate their worth and prove to themselves their superiority. To understand humor on the web, you have to look at it from this perspective.

By far the largest majority of humor on the web comprises of memes, catchphrases, remixes and repetition. All your base are belong to us, lolcatz, goatse and the rest. Some of them are funny. With the enormous profusion that is characteristic of the Internet, it would be impossible for some of them not to be funny. But, by far, the majority are not. They are tired, cliched rehashes of beaten to death jokes. Why then, do they persist? Because their goal never was to be funny, your amusement is never the prime concern. Instead, they exist as a credential of citizenship. It is a communication from the poster that he belongs to some in-group for which a set of memes form the common language and the humor is both simultaneously inclusionary of those who get the reference and exclusionary to those who do not. It’s of no coincidence that Family Guy is a show particularly beloved by the Internet citizenry, given that a full half the jokes on there comprise of mere recognition of some obscure, pop cultural phenomena.

The next largest contingent of internet humor comprises of pedanticism. Ask a serious question on the internet and there is some slight chance you may get a serious answer but you can almost always be guaranteed a series of stupid answers which answer the letter of the question while avoiding the spirit. Again, regardless of whether the answer was serious or subversive, the purpose was almost never to be helpful, by as a validation of cleverness. To answer seriously provides your bona-fides as an expert who is able to intelligently comment on a domain but to provide a joke answer is much easier to accomplish and gives you a platform to demonstrate your wit. This, as far as I can gather, is why Quora is so ruthless about extirpating parody answers. For any given question, a few people might have the requisite domain expertise to give a serious answer but almost anybody can provide a parody and, while a few might be genuinely funny, most will be a lazy attempt at recognition which contributes nothing but a sense of smug self-satisfaction for the poster.

Thus far, I have delved into two particular types of Internet humor but the same general principle applies to almost everything else the Internet citizenry writes, both online and off. Humor serves in a pure operational context, to prove worth, intelligence, belonging or superiority. It is not there to please, delight or amuse (except insofar as these further an operational goal) because it is rare that you could care enough to want to do so.

I want to note again at this point that this is not a description of all humor present everywhere on the Internet, just that deployed by the particular segment of the population which I term the Internet citizens. It has been interesting over the years, as the number of tourists on the web has started to overwhelm the citizenry, how the different cultures have merged and adapted. In a way, it mirrors the integration of African-American culture into the mainstream starting from the 60′s and continuing on into today. Most web literate people are familiar with the lingo and conventions of the Internet citizenry now and some of it has shifted into the mainstream so much that the origins have become murky. At the same time, entire communities are forming which do not derive from the legacy of Internet culture and want nothing to do with it. They are finding, much to their surprise that the virgin lands they thought they were inhabiting actually have injuns on them and that they’re none too happy for the intrusion.

I think it’s essentially for anyone trying to deploy an online community right now to be aware of the various factions and interest groups that occupy the web and how they can be both an asset and liability to your efforts. The last 10 years has been littered with the corpses of various naive corporate community building attempts who inadvertently blundered head on into these swamps like the Chevy Tahoe “Make your own ad” campaign, the Time 100 4chan stunt or Mr Splashypants among hundreds of others. I hope this impromptu ethnographic sketch provides some degree of insight into how to properly navigate the Internet and effectively deal with the natives.

To be notified of the next Social Software Sunday piece as it’s posted, you can subscribe to the RSS feed, follow me on twitter or subscribe via email:

On February 26th, I made a post entitled Career Transitions, detailing the failure of Bumblebee Labs as a startup and outlining my next steps. Now, exactly 7 months later, I’m ready to detail what’s gone on in the intervening time. First things first, I accepted a job offer at a startup called peel one month ago as a “social experience designer”. The company is still in stealth mode so I wasn’t really quite sure what I could publically say about them. Let’s just say I’ll be heading up their Social Television initiative and there’s going to be some exciting developments coming down the pike.

Even at the beginning of the job hunt, I anticipated that it would be a long process. I wanted time to scope out the scene, understand and surface all the various interesting opportunities and get a better understanding of where I best fit into this crazy landscape. Publically, I was predicting 3 –  4 months. In the end, it turned out to be 6. I’m not going to pretend that the entire process wasn’t hard work & demoralizing at times but, looking back on it in retrospect, that period did serve to form the basis of relationships & experiences that will reap dividends over time.

What surprised and gratified me was validation that the problems I were thinking about were interesting, my level of insight was high and what I was doing was important. It was heartening that people who were very senior up at very important firms, taking the time out of their day to meet with me and explore what I had to say about social experience design. On the other hand, what surprised and disappointed me were the tiny number of companies I could find that I regarded as trying to do anything truly innovative with social. I met up with a lot of companies who were merely trying to stir fry a bunch of existing social features into a hopefully appealing amalgam. I’m not saying that there’s anything wrong with this. It’s a strategy that is probably as good at making money as any other. It’s just that with so much innovation yet to be explored in social experience design, it’s disheartening to find so many people unwilling or unable to really push the boundaries.

Now that my life has started to busy up again, I’ve also found the urge to take up side-projects. One that I’m extraordinarily excited to be starting but not ready to announce publically is the formation of a Product Design Guild in San Francisco. The other is this, a regular series of blog posts I’m going to title Social Software Sundays.

This gestation period has also given me a better sense of what it is that is interesting of the stuff I have to say. I’ve had countless conversations, pitches and discussions with people and I’ve been slowly reworking, refining and adapting the messaging and positioning over time. I’d been toying with the idea of starting to contribute some of this knowledge towards the public domain. A question on Quora finally prompted me to start to list out all the various problems I was interested in and even I was a bit stunned with how much was in my buffer. After confirming support that it seemed like a good idea, I have decided to write a new blog post every Sunday about a different area of Social Software that I find interesting. To help guide what I should write next, I’ve decided to open it up to the community. I’ll be using Quora as a platform to help manage the community element but the writing will appear here.

Looking forward to writing my first Social Software Sunday next week .