I dashed off a post yesterday entitled Disregard ideas, acquire assets which seems to have gotten an unexpected amount of positive reaction so I figure I would use this opportunity to formally talk about the new startup I'm working on.

In early January, I left my previous job to work on an idea that's been a burning passion of mine for quite sometime. The premise behind it is pretty simple:

1. Our social relationships are some of the most important assets that we own
2. We are horrendously inefficient at leveraging those assets

To point number 1, in the past week, I've helped someone navigate which neighbourhoods in Seattle to rent a house, helped a friend spec out a new machine for work, offered to introduce a bright young kid to a potential mentor, referred 3 separate marketing/PR to a promising startup, cooked brunch with 4 close friends, offered to cook dinner for a friend in town from the East Coast and spent 2 hours talking over the social experience design problems with the lead designer of one of the top 10 websites in the world. In return, this week has been of commensurate value with all of the offers of help that have been extended to me by my friends. My friends are like a secret superpower, they make me 10X more awesome.

To point number 2, while these points of contacts were enormously valuable, they were also largely arbitrary. They only really occurred during the points in time when two of us were physically co-located and were able to have genuine, productive conversation. What about the friends who, by whatever circumstance, I only get to see once every 3 months or less? When we do get together, our conversations are so valuable and productive I wish I could continue them once we part ways but it's always so frustratingly difficult to do so that those conversations eventually whimper and die. The web has the potential to turn our 10X superpower into a 100X superpower but the tool to do so is not there yet.This is not a new or original idea. I first had it almost two years ago when I found myself spending close to $3000 to travel to a conference just to be able to have those genuine, productive conversations. But it was only until recently that I finally had the assets to truly feel confident executing on this vision.

• Asset #1: I've been thinking about the field of Social Experience Design for close to five years now. I'm pretty confident in saying there are, at most, a dozen people who have the depth of thinking at this point in being able to marry all the diverse disciplines of knowledge required to think through this issue (Social Interaction Design: Where are the most interesting uncharted waters in social software design? is a reasonably comprehensive list of everything I've been thinking about)
• Asset #2: My go-to-market strategy is, I think, incredibly strong and relies on deploying assets I've carefully been cultivating for a while, chief among them is Product Design Guild. There aren't many companies who are able to meet with their customers for 6 solid hours once every two weeks like clockwork and I'm enormously excited about this as a potential asset.
• Asset #3: The Product Design Guild has been an amazing testbed for many of my hypotheses and large parts of the product have been dramatically warped due to my experiences there. This is the ultimate lean startup, we built a following before we built a product.
• Asset #4: I spent the formative years thinking about this in Seattle, outside of the Silicon Valley bubble and I think my unconventional thinking on this issue gives this a secret edge. While other people were going gaga over photo sharing and coupons, I was hanging out with academics and salesmen, watching how they navigate their social relationships.
• Asset #5: My extraordinarily amazing CS educators who gave me an abiding love and appreciation of technology. I asked my friend Sutha Kamal to give me his notoriously tough engineering pre-screen test for Massive Health which rejects 20 candidates for every one it admits and I was, rather depressingly, able to pass it without too much undue effort. My first programming language was Haskell, I've built computer vision systems before, I can still rattle off the performance characteristics of close to two dozen algorithms and yell at you if you aren't using tries when you need to do fast string retrieval. I don't have the operational experience to be and engineer anymore but one thing that's clear is that, while this will be first and foremost a product company, deep in it's bones, it will also always be a technology company.

Which brings me to the one asset I don't have right now, an amazing technical co-founder. Let me be clear, this is not just a big vision, it's an enormous one. While the people I've been meeting in the past few weeks have been great, it's not yet been love at first sight because my standards for this are ridiculously high.

The person I am looking for is:

• Obsessed over product. If you can't name me four products that frustrated you with their inadequate design that day, then you're not the right person, even if we're meeting at 9AM.
• Passionate about doing something meaningful. If the choice is between working on this or being the CTO of Zynga and this is a hard choice, you're not the right person.
• Excited by grand visions. We might try and fail and only achieve something great instead of something world changing but at least we fucking tried.
• Gets shit DONE. nuff said.
• Has the operational experience to solve the hard technical problems necessary to achieve truly great product vision. There are some startups that can be made purely with pluggable, off-the-shelf components. This is not one of them. While the MVP is currently deceptively simple, there's some deep technological challenges that need to be solved that are fundamental to this space.

If this sounds like you, email me at hang@bumblebeelabs.com and tell me a little bit about yourself. If this doesn't sound like you but it sounds like someone you know, introduce me and I'm willing to offer 2% equity as a referral bonus if that person becomes my co-founder. Human assets are important and they deserve to be rewarded as such.

edit: If you're neither of these people but you're intrigued and would like to know more, you can add in your email here: https://spreadsheets.google.com/…

Let's fucking do this thing!

Post on Quora

There's the romantic notion of two complete nobodies, coming up with the next great idea and forging off to change the world. While that does happen, I believe that it's not the optimal path towards controllable business success.

There's a ton of brilliant 22 year old kids these days all churning through the same bucket of rather trivial ideas for web startups. Games! Group Messaging! Coupons! The reason why is that when you're 22 and just out of school, there's only a limited scope of ideas that it's actually practical for you to execute on. What I've found though, is that the most exciting startup ideas are mostly not in this pool but are, instead, backed by a hidden asset.

When I talk about assets, cash is the least interesting of all of these. Instead, I'm talking about more intangible assets like skills, reputation, relationships, attention & fame. I'm of the strong opinion that the most reliable path towards startup success is to focus relentlessly on acquiring interesting assets and then execute on the startups that naturally fall out of them.

Stack Overflow is the perfect example of this. The software that runs Stack Overflow is actually relatively trivial and really could have been built by anyone at anytime. What made Stack Overflow possible were two hidden assets:

1. Without an initial community of high quality users, Stack Overflow would have died. Joel Spolsky & Jeff Atwood ran, at the time, two of the most popular programming blogs in the world and were able to generate sufficient interest and attention to get SO over the initial cold start hump
2. Without great software design SO would not have been able to retain users at the rate they did. Joel Spolsky & Jeff Atwood had both been thinking very deeply about the structure and organization of social software for a very long time and avoided a number of obvious mistakes in the fundamental foundations of the software. Here's a blog post from Joel in 2003, thinking about these issues: http://www.joelonsoftware.com/ar… and the Stack Overflow podcasts are a secret mine of excellent social experience design insight: http://blog.stackoverflow.com/ca…

Neither Joel or Jeff had any grand, overarching vision of starting Stack Overflow when they started blogging for the first time. Instead, they just diligently worked to each build this amazing asset. But by building this asset, they opened up a thousand new, good startup ideas that were unavailable to most other people in the world and all they needed to do was to pick the one most appealing to them and execute on it.

I talk to a lot of different early stage startups these days and, inevitably, the ones I'm most excited about are those with a hidden asset backing them. Joe Edelman who built one of the most sophisticated reputation systems in the world at Couchsurfing is now deploying that asset towards Groundcrew. Gabe Smedresman who ran real world social games at Yale is now deploying that asset towards Gatsby. Yishan Wong who is one of the one of the world experts at startup engineering management is now deploying that asset towards Sunfire Offices. Sutha Kamal who is one of the most relentless business development minds I've seen at work is now deploying that asset towards Massive Health.

Inevitably, the story was that these entrepreneurs focused on acquiring assets and they reached a point where they couldn't not do a startup with them. It became like walking through a field of low hanging fruit and wondering which ones they should pick.

I think the conventional startup narrative is mistaken in that it casts the world into those who are temperamentally suited towards only doing startups and everyone else in the world who can be regarded as a brighter species of sheep. Instead, practically every one of the entrepreneurs in that list has spent significant time being an employee, quietly building up assets that would later become valuable. Many of them were even reluctant to become entrepreneurs.

What I take away from this is that I would like for a new startup narrative to emerge. One that focuses on the less sexy aspects of building a startup which is the 10 years before you write the first piece of code. I'd like for people to start thinking of startups as less something you decide to do and more an opportunity that gets handed to you. I'd like for people to focus first on making real contributions to the world before feeling like the world owes them a startup success. It's things like this that are the key towards shifting the ecosystem into a more mature startup culture and most optimally deploy the scarce human capital that we have.

Disregard ideas, acquire assets.

Post on Quora

To say “design is about making it look pretty” has finally become a faux pas within Silicon Valley. To utter it brands you as the worst kind of n00b. Instead, people have adapted to this shift by saying “Interaction Design is about making work well, Visual Design is about making it look good”. This seems to be the new status quo and it’s easy to mistakenly hold this impression if all you’ve ever worked with are bad Visual Designers. Good Visual Design is about clear and effective communication and it involves everything from understanding who you are communicating to, what message you want to communicate and then how to effectively deliver that message.

To demonstraJaco, over at the guestlist blog, has an excellent time lapse video of the design of the guestlist front page which, IMO, convincing demonstrates how visual design encompasses so much more than making things look pretty:

Timelapse of Homepage Design from Jaco Joubert on Vimeo.

This is the ninth of a weekly series of posts on various aspects of social software design I find interesting, here is the full list. If you’re wondering where SSS#8 is, it’s still in the process of being written. Oops. Each of these posts are written over the course of a few hours in a straight shot. Contents may be mildly idiosyncratic.

Yesterday marked the second Product Design Guild meeting and it’s becoming clear that we’ve managed to hit upon something special with these events. Fortunately, I took some video at this event so I can let the attendees speak for themselves:

For those of you who are not familiar, the Product Design Guild is about having designers come together and bring real work so that they can help each other. At our last two events, we had roughly 30 attendees each time, mostly from small, exciting startups but also the occasional big company like Yahoo & Autodesk. They bring anything from glass bottles for Fijian Rum that they’re working on as a side project to tools to help better manage digital assets within a team to the latest beta version of their new front page. Projects range in maturity from whiteboard sketches to functioning code that gets modified live during the event. We hold an introduction at the start of each event where every person stands up and gives a short spiel about what they brought and I’m always struck each time by the breadth and diversity of projects present in the guild.

After reflecting on this for the better part of a day, I think I’ve managed to uncover just what it is that makes this group “magic”. The world of the technology founder has undergone radical innovation in the last couple of years. Y Combinator, the rise of co-working spaces, hackathons and convertible notes have all radical changed what it means to found & run a company. Meanwhile, the process for workers has remained largely the same. Even at exciting new startups, while the tools might be slightly different, the basic way that work is done hasn’t really changed. The reason why the Product Design Guild feels so fresh & news is that it’s trying to do for employees, what Y Combinator has done for entrepreneurs. It’s changing the bargain of work into a new form which is more radically open, collaborative & cooperative.

The first rule of the Product Design Guild is that you have to bring work. It can be a side project or something you do for fun but we would prefer for it to be your everyday work. We want you to shut off your laptop at your office on Friday at 5pm and then bring that work over to the Guild on Saturday at noon and resume right on working. Already, this is quite a radical concept. For most companies, work never leaks out beyond the walls of the building, at least not without a thicket of contracts and regulations. Sure, you get to see the company website or iPhone app or hardware device. But you never get to see the half finished PSDs, the initial sketches and doodles, the bits of barely working code that has yet to be skinned. To be able to sit down and work with someone who you’ve just met is what I think causes the spark you hear in people’s voices as they describe the guild.

Of course, revolutionizing work is not easy. If it were easy, it would have been done a long time ago. Right now, we’ve captured the magic but the main challenges still lie ahead, in trying to keep that magical spark alive. To do that, I think we need to focus on five key elements we’ve managed to nail:

• The quality of the people: One of the themes that was repeated in the video was how just being around smart and talented designers made this event special. From the start, we were determined to keep quality high and for to only get higher over time. This means not only lots of time spent on the back end, filtering for candidates who met our standards, but also time on the front end, personally selling the guild so that high quality candidates actually applied. This relentless focus on quality is something we’re committed to keeping to over time.
• An attitude of helpfulness: While I expected quality to be an important factor, it surprised me how much the attitude of intense helpfulness that we’ve managed to develop in the Guild has, in many ways, been even more important. You go to a typical networking event or mixer and everyone you talk to is only half paying attention to you while trying to figure out who else in the room they should be connecting with. You might exchange pleasantries or generalities but it’s mostly surface level conversation. After experiencing that, there’s really something indescribably about coming to the Guilt and having another person giving you their full attention. Your problem suddenly becomes the most important thing in their lives. Such an attitude is infectious. At both of the events we’ve held, it was clear that everyone in the room was more concerned about giving help than taking it. Thus far, it’s been a happy accident but, moving forward, it’s also something we’re going to be taking very seriously.
• Supporting confidentiality: Part of the reason why it’s so satisfying to participate in the Guild is because you feel like your help has impact. People there are working on real products that affect real users and you can help make real improvements to those products. Confidentiality is a major part of making this work. This is why fully half of our rules and all of our policy is designed around respecting confidentiality to the fullest extent possible.That being said, confidentiality being violated at the guild is a matter of when, not if. Some designer will bring in early versions of a new product launch and they’ll wake up tomorrow to find the details splashed over the pages of TechCrunch. There is nothing we can ever do to eliminate these breaches in confidentiality, only to mitigate them as best we can.
• Managed serendipity: In my last Guild meeting write up, I talked a lot about the Human Expertise Routing Network and this was the meeting which saw it pop up into existence. Over and over again, during the event, I walked into a conversation and figured out that I could add value by dragging in the right person. This was so evident that people actually explicitly commented on it at the end of the day as significantly enhancing their experience. It’s this type of serendipity that really leverages the true strengths of the Guild format.
• A commitment to offering value: Our mission for the guild has been very clear from day one; we serve designers and the profession of design. While we may try and help out other interest groups like engineers, CEOs or investors, it’s never at the expense of designers. Over time, this means figuring out ways of supporting designers with creative and helpful services.

  This Guild meeting marked the beginning of our “in Residence” program. Drake Martinet from the Wall Street Journal’s AllThingsD because our first “Journalist in Residence” and added immense value by providing design insight from a journalistic perspective. Over the course of time, we’ll be adding other “in Residence” partners from Engineering, Investment, Marketing & HR.

  The next Guild meeting will be the beginning of our “Bring a friend usability session”, a program designed to get startups onto the usability testing bandwagon in as quick & efficient a way as possible.

  Beyond that, we have other exciting projects coming down the pike that are still too early to talk about. Part of why designers are so willing to give to us is because we’re so willing to give to them. It’s only be demonstrating this commitment to offering value that we can keep that enthusiasm alive.

It’s still very early days and so these are just a tiny fraction of the lessons yet to be learned. That being said, I think this provides a pretty robust framework that captures the essence of our experience and allows us to “bottle the magic”. Over the next couple of weeks, I’m going to be actively talking with people about setting up sister groups and so this serves as some useful documentation about how this will happen. Here’s to hoping for future success!

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:

Social Software Sundays will be on a brief hiatus but I’ll be back next week with a meaty post.

This is the seventh 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. Fair warning: This one happens to be especially idiosyncratic and full of obscure, uncited references.

In the fashion industry, clothing can either be made bespoke, made to measure or off the rack. Bespoke clothing is custom made to the individual, fit with meticulous care, godawful expensive and, as a result, a tiny niche of the market. Made to measure clothing involves some degree of measurement but the patterns are standardized with carefully designed in room for modification. It’s still a tiny niche of the market but much more affordable. Finally, off the rack is the clothes you and I actually buy. We go into a retailer, try something on, find the best fit we can and accept that this is the price you pay for stupid cheap clothing.

Online communities can also be thought of as bespoke, made to measure or off the rack. Bespoke communities such as Quora, Reddit or Kickstarter are custom built, one at a time, for a single community for which they are designed to serve. They are distinguished by having the designers of the code also being the designers of the community.

Made to measure communities are ones which the owner of the community obtain the basic software from elsewhere but then make modifications to suit their purposes. This blog is an example of a made to measure community. It’s based of a stock wordpress installation by with many plugins & custom modifications involved. Similarly, many of the forums I’ve participated in over the years have modified their software to suit the community. Made to measure communities are distinguished by their community owners having limited control over the software environment based on what extension capabilities were built into the software.

Finally, the ready to wear communities are ones in which a completely stock version of community software is used as-is. Blogger, Skype & Facebook Groups are all examples of ready to wear software. They’re distinguished by performing all of their customization of the social experience from within the social layer since the community owners have no ability to access the technology layer.

The comparisons between online communities can be illuminating, especially in relation to how fashion houses manage the complex mix between the three categories and what implications this has for web companies trying to do the same.

A short and mostly remembered history of online communities on the web

The web was social from the very beginning. The entire point of connecting computers together was to allow for rapid communication and a simple, cobbled together version of email was one of the first programs ever written for networked computers. This early phase of the web was hand crafted, in the same way that all of early clothing was hand crafted. People largely cobbled together their own software system from the original source code and every user was also a maker.

The first waves of serious communities happened via Usenet, BBSes & MUDs; ready to wear, made to measure and bespoke respectively. These three systems provide us a view in just how these three different economic models affected the eventual social systems. Usenet was a mass market system (well, as mass market as you could get back then). It was the global commons which provided the most basic infrastructure around conversation and not much more. The endless groups had the same cheerful austerity that you find in low-income housing, where individual neighbors desperately tart up their apartments in order to hide the dreary sameness.

BBSes, on the other hand, were the wonderfully quirky community hangout spots. Each one was run by an individual, according to their own tastes and going into one was like entering into the living room of the sysop who ran it.

Finally, MUDs or Multi-User Dungeons (Think World of Warcraft, only 100% text) were more like artistic experiments, designed to push boundaries and explore radical issues related to this brave new frontier. It’s no co-incidence that many of the studies of radical issues such as gender-bending, online rape or radical libertarianism happened within the context of these game spaces as the custom built nature of them allowed them to go further and faster than most.

The next phase came from the development and subsequent domination of the web as the primary way that internet was consumed. IMHO, the web was actually a pretty big step back for social technologies as the fundamental underpinnings of HTTP do not mesh well with the needs of social systems (only now are we starting to see abstraction layers like the LiveNode system that Quora runs which rectifies a lot of these deficiencies).

Once we finally managed to figure out how to hook up dynamic, database backed websites into the a system designed for viewing static documents, we started to see the holy trifecta of online communities start to take shape: blogs, forums & chat. This was later joined by Wikis to make what were almost regarded as the platonic solids of the community space. It’s hard to remember for many people now but this was the era when “community management” was the hot buzz term and there was almost a Lord Kelvinesque attitude that “there is nothing new to discover, all that remains is more precise measurement”.

This is what I term the “social winter” that ran from approximately 2000 to 2005. With a couple of notable exceptions such as Slashdot, bespoke social software had virtually disappeared from the scene and everyone was fiddling around with some variation of blog/forum/wiki/chat, only innovating in terms of what made to measure plugins could be retrofitted into those basic paradigms.

I place the creation of Digg & Reddit as the first resurgence in interest in online communities again and some serious fresh blood coming into the field. Social news was a completely different beast from the blogforumwikichat and demonstrated convincingly that more social primitives were left to be explored. Since then, we’ve seen a number of notable bespoke communities, all exploring different facets of this space. Aardvark, Stack Overflow, Quora each represent intriguing experiments and even blogs got revitalized with Posterous and Tumblr both providing fresh spins on the concept.

I had originally planned for this to be a piece investigating how the fashion strategy of diffusion lines apply to shifting bespoke designs “downmarket” into more mass friendly designs but it ended up veering into a completely different tangent and this seems like a discussion for another day. I’m going to end this essay here and hopefully take it back up another week to provide a more conclusive conclusion. I’m tired and it’s time for bed, gnight.

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: