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.

Chocolate Ice Cream Sundae

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:

  • Ross Lee Graham, PhD

    The very notion of Design Principles puts too much focus on the deterministic aspects that underlie any design.  In effect, too much concern for principles has a stultifying affect on any attempt to do something new. Of course you might think in terms of tinker-toys where all the construction elements are pre-designed and it is still possible to find unthought of designs that may be deemed creative even though under such strict limitations. Rather than principles of design perhaps we could speak of the attitudes that underlie the generation of designs. For argument I shall assert that it is our attitudes that give meaning to our actions and one of those action types is the action of designing. To express this from a different context…if you spank a child for an unwanted action we could say that it is a punishment for that action. On the other hand, we could have the attitude that the spanking is a mnemonic device that helps the child remember that that action is unwanted in the context in which it was expressed. Most children readily discern when a spanking is done with hostility and when it is donewith a concern to improve their place in their social environment. They likely do not think so abstractly about it but in terms of feeling the attitude involved it is for the most part sensed with adequate clarity…etc…love is not something that we do, but it is definitely an attitude that affects what we do.