Designer Ego and Collaborative Design

[GarthDB]

Does the stereotypical designer ego get in the way of collaborating on design effectively.

Includes:

• not wanting to show ideas until they are perfect
• not wanting to share credit
• thinking a project is too valuable to open source

[teamvvork]

I kept thinking about this after Moody brought it up last night... Some initial thoughts: I don't know if thinking of designers as egoists is a solid starting point to get us to a solution that resolves problems relating to collaborative design. I think good designers have learned that openness is not generally efficient, or an optimal way to keep things to a high standard. UNLESS, it is intrinsic to the concept of the design itself, too much openness often trades quality for ethos and is the worse for it.

But it can work.

For example, if we were designing a branding solution using an open source approach/framework we would have to conceptualize a reason for opening it up in the first place. I can think of examples where such an approach would be both elegant and benefit from the potential "missteps" varied participant abilities would bring. Like the Japanese concept of wabi-sabi, the thing's imperfections and asperities would become its strengths. The system from the beginning would re-articulate "good design" as any something that was contributed. The only right answer would then truly be any answer you felt inclined to give as a response to the terms of the prompt. If it sounds too theoretical, a practical example would be a logo comprised of three shapes that could be repositioned however someone saw fit. This would allow for play, localization, ownership, and comparative innovation.

I realize such a logo wouldn't be truly "open" anymore, but the parameters would endow the gestures with more significance inside the matrix of play. The limitations could then begin to articulate a space of showmanship and dexterity -- potentiating moments of pure joy (read Dave Hickey's essay on basketball if you can find it). That's why sports have rules in a way, so that people can reach higher planes of expression while staying in-bounds. So maybe rather than calling it Open Source Design, it should be called Transparent Design.

Transparent Design would avoid the stymying need to address the mandates of open source as a politic and focus instead on a generalized paradigm of disclosure and openness. A transparent designer would readily show ideas that aren't perfect (and ignore misinformed critique/comments), naturally share credit with others, and make projects open source when it was obvious that is how they should live. At least I think they would.

[GarthDB]

@seecoy I started to write a response, but I'm on my phone and I don't think I could organize my thoughts completely. I should be able to get on my laptop soon.

[teamvvork]

@GarthDB yeah, re-reading what I wrote now more closely - "good designers" is not the right way to put it. There are a lot of different types of good designers --- but I still do like the idea of this term "transparent design"

[GarthDB]

@seecoy I'm super happy that @terracomma talked about the work he did on the site. I'm very appreciative of the contribution.

I also appreciate the feedback especially that it isn't casual. You mentioned a number of things. At the risk of oversimplification I wanted to summarize your points to make sure I understand what you mean.

1. Labeling designers as egoists or egotists may not be a great strategy
2. Too much openness in design is not efficient or hard to maintain a high standard
3. Rules help improve performance
4. Call it Transparent Design

Ok - if I misrepresented something you said let me know. Either way, I'd like to respond to these points as I think they are valid.

1. Labeling designers as egoists is not a great approach to attracting the design community

True. I didn't mean to make that sound like a bad thing. I was referring to the ego everyone has, not just specifically designers. However we have real stigmas to overcome in relation to our inflated egos.

2. Too much openness in design is not efficient or hard to maintain a high standard

I do think there are some projects that should not be done in the open or invite collaboration. Usually projects that are very personal can be difficult to collaborate on; it is easier to design for ourselves in such cases. And of course, projects that need to be closed to protect client interests are best done in a traditional fashion.

However, I whole heartedly disagree with your comment that "good designers have learned that openness is not generally efficient, or an optimal way to keep things to a high standard." Two parts to this - openness is not efficient and promotes a lower quality of work.

2.a. Efficiency in Open Source

Openness is as efficient as you want it to be, and often times better than you'd expect. As the owner of an open source project, a designer should not be sitting around waiting for feedback or contributions. They should work as fast they want and if a comment or contribution comes in that merits a response the designer should address it. Sometimes this means an idea is challenged and the designer gets to explain decisions; sometimes the project gets a new contributor or advocate; sometimes design flaws are pointed out and suggestions are made. None of these things are bad; nor will they slow the project, they can only improve it's chances and productivity.

2.b. Quality in Open Source

As far as quality, again that lies in the hands of the project owner. The design/owner acts as the creative director when new contributions come in. If the designer likes the decisions made as is, they can accept them (like I did with @terracomma's pull request). More often, the design is not a perfect fit with the project. When that's the case, the owner can work with the contributor and together make something better (this is ideal for many reasons) or decline the contribution with a short response. The quality of the design is 100% dependent on the project owner. Even if a core contributor accepts something that is not ready for production, the owner can easily restore the project to a previous revision using something like git, dropbox, or layervault.

3. Rules help improve performance.

True. Open source has rules. They are established and tested and have produced amazing results. The rules are so good it keeps everyone in check. We can go into more detail on this if you would like.

4. Call it Transparent Design

The Transparent label is fine. I actually use the label open design for what you are describing. I don't like the term transparent personally, but it just a matter of semantics.

I think open/transparent design is great, it is a first step to open source, but they are different. I fully support open design as it is much more accessible to a wider variety of the projects. But open source is the real goal. Allowing a community to join in as they see fit is amazing. Giving them direct access to your source files and process, with a license to use them in their own projects is a powerful force in improving design quality. I've seen it on development projects, and as I've started to see it on this site I'm fully convinced that it can produce surprising results, and can improve, not only the quality of design, but the quality of designers in the industry.

Far too often designers are seen as elitists. We can have those tendencies to be exclusive, or cliquish. This is damaging to potential designers, and stunting to the industry as a whole. Open source design is in complete contradiction to this trend. I think we can do more.

[teamvvork]

@GarthDB, Thanks for the thorough response. Fundamentally, I think I'm really wrestling with the term "Open Source Design" as the ideal way to describe this paradigm of working. And I think I've jumped in with opinions that didn't have a deep enough understanding of the terms and definitions you've put forward in other places on the site. My next self-assigned task: dig deeper into the conversation and all the things you've already posted.

Also, I'd love to focus the debate solely on designer egos at some point. I think there's more at play than just an innate desire to be exclusive, cliquish, or selfish.

[GarthDB]

@seecoy Open source can be a bit of a heavy term, but I still think it's the best term to describe collaborative design with an open license.

As far as the egos discussion I'd love to chat more.

A lot of this is autobiographical so feel free to chime in with your perspective.

Personally, I have a tendency to not want to show work until it is perfect. Perhaps it stems from being burned in the past by premature design reviews with unimaginative clients/managers, but I tend to suffer this paralyzing perfectionism which can lead to quitting a project too soon. I think working in the open is a good exercise for me to get over this.

I also feel the need to prove myself, which can make it hard to share credit. I'm unsure about my own skill and I want to show that I can create things of value. Part of me worries that if I work with someone else, I won't know if it is me or them that really made it good - maybe I'm nothing without a partnership. This is also a damaging way to look at things. When I objectively look at projects I've collaborated on with people I respect, I've come out of them a better designer.

The last one: In the distant past, used to think my ideas were valuable by themselves and would therefore keep them to myself, but I'd end up never getting around to working on them and eventually someone else would make something similar to what I had in mind. Ideas alone don't complete projects, and don't make money. If I could find someone to collaborate with I have a greater potential to complete the project.

These are all simplifications of the way I fight with my own ego on projects.

[teamvvork]

Yeah, me too on working to properly identify and minimize my own ego on projects. Admittedly, I'm not always as successful as I'd like to be, but I've noticed that the sooner I involve others in the process with clearly defined goals of interaction and feedback things run more smoothly.

When you say that you've quit projects too soon, I'm guessing not like full-stop quit, but more just sort of letting someone else drive it to their imagined end vs. the one you've envisioned? Or are you talking about side projects that don't have the same expectation for completion and just sort of fizzle out?

[GarthDB]

@seecoy Quitting too soon? both - when it is a project I'm allowed to quit I let it fall to the back burner then never get back to it. If it's a job related one I don't finish with the same passion/zeal.