A lot has been written about designers learning to code, and most recently Stephen Caver opined that developers should learn design “to gain empathy for the designers with whom they work.” And I couldn’t agree with him more. The overall message of this article and others like it is the idea that working together is the best way to ensure successful delivery of the projects we work on everyday.
This is all fine and dandy, but let’s face it, the sad truth is that it takes a lot of time to actually learn let alone comprehend the material we are diving into, especially if it is something with which we have no experience. On top of that, we have actual work and life outside of work and depending on individual situations those could occupy significant amounts of time. So finding time to sit down and learn something may not be something that we can take on as easily as others think. But I am not going to sugarcoat it, if you really want to learn, you will have to put in the hours to achieve whatever goal you are aiming for.
“the action of working with someone to produce or create something.”
The idea of collaborating is not a new one, but while it is easy to say “we collaborate on projects,” I think it is harder to define collaboration beyond giving an opinion in a meeting or creative session. Well, maybe not necessarily harder, but more… unusual. This is my perspective on what collaboration really means, especially as it applies to my role as a developer working with art/creative directors, user experience designers and project managers.
… a desire to learn
The most important part of achieving a goal is desire. It’s often been said that if you truly want something then you will do everything in your power to attain it. Whether that is money, a car, or a house. The same can be said of learning design or code. You have to want to learn it for you to actually be able to do so. Call it drive, determination or persistence. This is the first quality that you have to show when working with others — interest in what they are doing. Learning on your own is hard, and is often slow, confusing, and frustrating. So why not take advantage of learning from someone who has already mastered the principles? Someone you probably get to see on a daily basis. Take advantage of the resources you have available all around you, it will make the learning process a whole lot easier.
In a comment on Stephen Caver’s article, Rachel Gertz beautifully summed up the importance of learning:
I think for any team to be truly cohesive … having an appreciation for the process and the methodology behind why we each do the things we do means we can communicate using the same language.
… a desire to teach
In the same vein, it is important for you to teach what you know, regardless of whether you think you’re good enough to teach or people know what you want to teach. Brand new topics can be extremely informative, but I have also found that picking up a nugget or two from a talk or class you already know about can have tremendous effects on your workflows and how you approach your work on a daily basis.
If think teaching means presiding over an extensive class or something similar, that is not the case. Take a look at Make Photoshop Faster for example. This is a resource that solved a lot of Photoshop woes, and all it included was two optimization tips. Like I said, a nugget or two has the potential to change paradigms. Other excellent examples of people teaching what they know are Joel Marsh with the Daily UX Crash Course, Mark Otto and Jacob Thornton with Bootstrap, and Dan Rose with the Photoshop Etiquette.
Resources like these create a common understanding of base terms and techniques that make it extremely easy to pick up on the deeper nuances of whatever it is you’re trying to learn or teach. But most importantly, educating others covertly makes you a student by giving you a deeper understanding of what you’re teaching.
… building relationships
I had the pleasure of attending the Artifact Conference earlier this year in Austin, TX, where I got to hear a number of excellent talks. The one that really hit home for me was RWD IRL (Responsive Web Design in Real Life) by Trent Walton. In it, Trent explained that in order to built cohesive units, we need to build relationships (not referring to the romantic kind here) with people that we work with. This allows us to gain insights on how we each work as individuals, our personal processes, and where our strengths lie. I don’t think you have to wait to actually work on a project with someone for this to happen, because it could be as simple as asking questions on topics you’re interested in but are not familiar with, or sending out quick emails with tips, ideas or cool things you’ve come across.
A fair point that Trent also brought up was the almost adversarial nature of the relationship between designers and developers, particularly in environments where silos exist. In this scenario, there is a lot of fear with regards to losing control of your part of the work in progress. This then results in (a) people working in a secretive manner in the corner somewhere and having individual “great reveals” once the “masterpiece” is complete, and (b) creation of problems in one stage of the project flow that have to be solved by those in the next stage. Solving this silo problem requires a structural change within an organization to ensure that all disciplines are represented and contribute in every stage of a project. This is the part of the conversation where we admonish waterfall-oriented processes and advocate for iterative and agile approaches, but a lot has been written about that as well so I’m not going to delve into that.
… charting new pathways
The final piece of the puzzle is trying out new things to see what works best for you as a team. There are countless ideas on what the ideal workflow is, how to arrange workspaces for collaboration etcetera etcetera. But I believe that it is up to you to find what works best for you and go with that. The Basecamp team serves as an excellent example of this. On the issue of using Photoshop or HTML/CSS for designing interfaces, here’s what Jason Fried wrote in an article titled Why We Skip Photoshop:
None of this is to say we think Photoshop is bad or a waste of money or time, but for us we’ve found that going straight into HTML/CSS affords us the best iterative and creative experience.
This is what has worked and continues to work for them. Of course this has certain implications, but they have created a system that works for them. I don’t think anyone can dictate what is best for your team especially as an outsider, so it is up to you to determine what works best. And the way to do this is to experiment with ideas to see what fits best, be it element collages, designing in the browser, prototyping in code and so on. Once you’ve found what works, you can always fine tune it to make it better.
What about you? Do you have any ideas on what you think collaboration is? Leave a comment or let me know on Twitter.