Dear Developer,
Love Designer.
How developers can make designers’ lives easier. Sort of.
Last month, a tweet by Yesenia Perez-Cruz, Senior Designer at Vox Media, caught my eye. Her tweet asked what seemed like a simple question:
Usually, when these sorts of questions are asked on Twitter, there is an overwhelming variety of answers. While the answers varied, the majority of those who tackled the question proposed that the reason behind the lack of articles was due to the nature of the design/development process being sequential — work moves forwards not backwards. Pointing out that the process from a designer to a developer is a linear process does a great job of answering Yesenia’s question… if the question was asked 10 years ago.
Today, I believe the answer is a little more complicated than this. According to the replies, some people, albeit the minority, also agree. These days, the web design process isn’t as linear as it used to be. Roles overlap and an openness to iterate frequently means that deliverables move forwards, backwards, diagonally and sideways during the life cycle of a project. In order to keep up with this, a team must communicate early and continue to communicate often. Essentially, the people in a team need to work cohesively throughout the duration of the project instead of siloing themselves in their assigned roles.
While it was great to see people recognising the way the production landscape had changed, I had a small problem with this answer because it skirted around Yesenia’s original question: Why? Why are there so few articles about developers making designers’ lives easier?
Because it challenges status quo
Suddenly, as Katie Kovalcin points out, the “conversation” has begun to flow in multiple directions including the opposite way. Despite recognising the changes in the way we work, we’re still learning how to best adapt and navigate these changes. In the past, because of the way the conversation flowed, it was natural for designers to set up for the next link in the production line. We were all pretty used to this, so articles were written about it. Now, the production line is less of a line and more of series of intertwined paths. Everyone has to work to make everyone’s life easier and, speaking literally and directly to Yesenia’s original question, this includes developers, both front end and back end, looking “behind them” to chip in earlier on in a project such as during the primary design phase.
The tricky thing, however, is that people are now finding themselves in unknown territory unsure of how exactly they should contribute. While I’m not a developer I have had conversations with developers where they have specifically pointed out that they don’t think it is their place to offer help in stages other than their own. The reasons for this range from the internal to the external — developers don’t know how to help, don’t feel “creative”, equipped or empowered enough to help or, disappointingly enough, their contributions are not welcomed by others. Especially by designers.
Herein is the reason I believe that so few articles exist that outline how developers can make the lives of designers easier. In real-world modern web processes, it’s just not happening or, at least, it’s not happening enough for articles to be written about it. For this reason I thought I would address the other part of Yesenia’s question. Sort of. Below is a list of ways I’ve found developers particularly helpful to me as a designer. While some of these things of course help to make my life easier, this is not my main motivation behind writing this list. Instead, I write this list with the hope that it does less to divide the web design process and more to unify it. I hope it can make developers feel more comfortable stepping in earlier on and to encourage a communication crossover between the two disciplines.
I should note before I start that the below list is most relevant to those working in a consistent team such as within an agency like Humaan. A lot of the below encourages organic team growth over time but, with that said and with a bit of tweaking, this could easily apply to any designer/developer workflow.
Offer your technical know-how and suggestions early on.
Offering your technical know-how will help streamline a designer’s ideation process because early on you can help fill in the gaps about what are or aren’t viable options within the project’s constraints. Is something a designer thinks is unreasonable to implement within project constraints actually something that can be easily achieved? What other options are you aware of as result of your technical knowledge? This opens a world of opportunity to a designer while providing tangible technical boundaries that are impossible to establish without early conversations between designer and developer.
Pass on what you know.
One of the most invaluable things I have found as a designer, is working with developers who are open to providing me with some of their knowledge instead of saying things like “I’ll take care of it” or veiling their methods in mystery. When approached with a problem, feature or out-of-the-ordinary request, it is helpful to, within reason, take your designer(s) through how you intend to build something.
This is not to say that you should teach your designers “how to code” (this is a totally different argument altogether) but you should take some time to at least equip your designer with a basic understanding of how things work. Further investigation, of course, should be done by the designer themselves.
In my personal experience, I found that my design work improved ten-fold after becoming familiar with the more technical side of production. I managed to pick up HTML/CSS and while this is not necessary at all, I found that having a better understanding of how my designs were built meant that I was more thoughtful and considerate about my solutions — what’s possible, what isn’t, how will this be built? This all began because a helpful (and very patient) developer took some time to explain a little bit about what they did. As a developer, providing access to this information early on will help your designer think differently and, in my opinion, work better. This knowledge doesn’t have an expiry date either. It will carry on from project to project and inevitably improve your workflow as a team as time goes by.
Offer constructive design critique.
When seeking feedback, I have often heard developers say things like “Oh, I don’t know design” or “I’m not really that creative” or “I don’t really know what I’m talking about, so take what I say with a grain of salt”. On the flipside, I’ve also been guilty of only seeking design feedback from other designers. I’m not sure if this is a product of the aforementioned reactions but what I am sure about is that when a developer — either from an implementation or programmatic background — offers feedback, it is always very useful. Often, developers provide a different perspective and are usually more focused on the experience or functionality side of a design rather than the visuals. This is really helpful when a lot of feedback I receive is focused on aesthetics.
In addition to this, the feedback from developers almost always relates to their own involvement with a specific aspect of the design. Is a minor stylistic feature going to unnecessarily cause more development time than is allocated? Flag it. Is the visual arrangement of information going to cause the introduction of out-of-scope functionality? Flag it. This early identification of issues helps to avoid the need to redo things later on and minimises the need to design anything retrospectively; things that can eventually lead to project and budget blow-out.
Remember, your opinion is worth just as much as a designer’s and it’s helpful.
Tell your designer if you have any development constraints that might affect their workflow.
From a production point of view, be clear if you are using any specific frameworks or grids that a designer must adhere to during their design process. There is nothing worse than not knowing that a developer has to work within a certain set of constraints and then realise you haven’t designed something to suit.
Be open, clear and consistent about your own workflow…
Everyone has different ways of working so it is useful to establish a clear handover process for when a majority of the project moves from design to development. As a developer, do you prefer the styles and assets of a design be separated from the main document? Is there a specific way you would like your designer to prepare and present these assets? Do you care about this at all? If so (and even if you don’t) be upfront and clear about your expectations. This will help your designers design to not only a project spec but a procedural spec. This will help adjust and streamline their process for a more thoughtful delivery and will help and minimise any friction that may occur during a handover.
As an example, here at Humaan, the fancy front enders like to use Illustrator to create their SVG icon fonts. Knowing this, I now keep track of all the icons I use in a separate Illustrator file. This has helped me develop more of a consistent design approach and, at the same time, made the developers’ jobs a whole lot easier.
… just know where to draw the line.
By the same token, your development process shouldn’t negatively affect the designer’s process or cause unnecessary friction in the way that they work. Instead, you should be aware of where to draw the line. If you require weird naming conventions that are unique to your own personal workflow, you should bear the brunt of that work and find ways to achieve that yourself. Separating the need-to-haves from the nice-to-haves will ensure that your designer is left to work on the things that they are best at.
At the end of the day it all comes down to one thing.
Communication. All of the points above dance around improving the communication in and amongst your team.
But…
… this is all useless if everyone isn’t “all-in”. As I mentioned earlier, while it’s easy for developers to attempt to do all of the above, it is difficult if the help is not welcomed. At this stage an easy thing to say would be, “Designers, you magical creatures, welcome this with open arms!” but really, it’s not as completely one sided as that. Everyone should be open to accepting help, assistance, suggestions and feedback. Look at it this way, when a developer helps a designer, the designer is better equipped to help the developer. When a designer helps a developer, the developer is better equipped to help the designer. This kind of cyclic process is beneficial to everyone and especially to the end result.
With everything said and done it’s really quite simple (tl;dr).
The modern web design process is very different to what it once was. Gone are the days when each role was so distinctly separated from one another. Collaborate more, communicate more, embrace the crossovers and focus on ways to work better together rather than separately.
Further Reading
Below are some articles that I have come across in the past that address this sort of thing.
Design with Developers in Mind by InVision
How Designers Can Help Developers by Matt Gemmell
How Developers Can Help Designers by Matt Gemmell
Don’t Say This To A Designer by Juhi Chitra
How to Work with Designers by Julie Zhuo
I’d love to hear your feedback.
I’d love to hear what you think. Do you agree? Disagree? Points you’d like to add? Leave some comments, email me or tweet me (@kylietimpani). Designer, developer, or just fellow human: I’d love to hear from you.
Thanks for reading!
This article was originally posted as a part of the Humaan blog. You can have a read of the post over there along with other helpful and insightful articles.
