Over recent months I have been in a position where I’ve been working on some fantastic projects for clients - that had you told me a year ago i’d be working with, i’d call you ridiculous. However, the twist in this tale is that I wasn’t the designer on these projects, I was the developer. While I will be quick to admit I have been massively out of my comfort zone and not exactly in the position i’d want to be in, I have been able to look back and learn a lot about myself and how, having lived in a developers shoes, I can be a better designer. This period of being outside my comfort zone frames the purpose of this post. I want to discuss the idea that we as designers can be more conscientious of the development process. Meaning we can create a smoother, less stressful process from design through the development and delivery. Some of the points I raise may extend beyond the relationship between designers and developers and encroach into how we present and communicate our work to the client also.
Learn to develop a little, or work closely with developers you trust
There is a strong argument against learning to develop, for example becoming a jack of all trades or not wanting to limit you creativity due to the tools you are using. However, I believe that a fundamental knowledge of the medium you are working within is vital. As a graphic designer must know, print processes and how substrates will impact the outcome of a design. We as designers for the web, and screens, must understand our medium. While I must admit I somewhat stumbled into learning to code through a desire to design for the web, I believe I have become a better designer for it. For example, I have gained a foresight, I am aware of potential traps that are inherent with different browsers and devices, interactional issues and how usability will impact upon my work. I am no longer seeing my design as a flat canvas inside Photoshop. I see it for the transient nature it is and am keen to get my work into a prototype as soon as possible so that it can start being regarded as a website. From this knowledge, I have begun to see the value in knowing how to develop. However, these issues can still be overcome if you simply have a close relationship with whoever is developing the project. They will recognise potential development issues or certain decisions that may impact the client or the user - which brings me nicely to my next point.
Learn to let go of your design
As designers we need to learn to let go and understand that it is not our baby; someone else will be developing it and someone else will be maintaining is long after. Keeping the developer in the loop during the design process will allow them to advice and spot potential pot-holes in your design. From an interaction and a development perspective, it also makes you rationale your decisions. Is there a reason why a particular vertical gutter is 18px when all the rest were 16px? Such a minor inconsistency may massively impact on the development, as your design has suddenly become inconsistent. Does the sudden inconsistency add any greater value to your design? Or will it in fact confuse the user?
A Canvas in photoshop is not a website. As Dan Mall coined it, lets ‘decide in the browser’.
Accept the ‘ebb & flow’
This term is thrown around all the time in the web nowadays, and with good reason. We’re learning to embrace the transient nature of the web and while it’s almost common knowledge for us designers, we have to educate our clients on this too. If we create pixel perfect designs, which the client signs off on, without knowledge of potential development issues, we put the developer in an incredibly difficult position. This will only result in conflict between the client and the developer further down the line. The designs should be an illustrative guide in which the developer can then take creative license to slightly tweak and we need to educate our clients that this will be the case. A Canvas in photoshop is not a website. What this means is that we are allowed to base our final decisions inside the browser rather than in Photoshop, where we are not faced with the same constraints. As Dan Mall coined it, lets ‘decide in the browser’.
It ought to go without saying that we need to keep our websites consistent. Not only will this create a more familiar website for the user, it creates a more streamlined experience overall. Contrast is a great way of creating impact upon a user, however we also stand to alienate users if we create needless change. If your Headings are consistently 18px and all caps, we create confusion when we then switch to 17px and lowercase. It creates a much more harmonious experience to maintain a consistency. It also significantly aids the development process by allowing the developer to code the site modularly. If it helps, create a style guide and elements list which explicitly isolates the style conventions of the site.
I know its satisfying when we’ve got everything all perfectly aligned, neat and tidy - but the web is a messy place.
Break your own design
I know its satisfying when we’ve got everything all perfectly aligned, neat and tidy - but the web is a messy place. What happens if that row of information blocks has a title that drops on to two lines? Or if the amount of copy you accommodated for is exceeded? We need to let go of our desire for symmetry and order and accept that this is how the website will be used once its handed over. This becomes the point where a dialogue with the client is vital. In an ideal situation you would already have content and copy from the client which allows you to actually stress-test your design with real content. A good friend of mine, Rob Mills, discusses this better than I could, so if you want to know more about working content out, read his blog. Another solution, as previously mentioned, is to start prototyping your design in the browser. It is much quicker to break and subsequently fix text based issues in the browser. More importantly you are able to see at what point your text will break in the browser too, as lets not forget text will be rendered differently browser to browser and does not always have the font-smoothing settings that Photoshop does. By breaking your site, this allows both you and the Developer to put a solution in place that the client is aware of, be it min-heights on content boxes or a cap on the amount of copy which the client then adheres to.
Let the developer do what they do best – Development.
Once the design is signed off, save the developer a lot of time by creating a sprite/assets files for them. It is not enough to expect the developer to use the flattened icon you used inside the PSD that cannot be edited or scaled. What if the client decides they want the icons in a range of colours? Ideally you should create a separate file for all your assets in a higher quality than required, which can then be edited through blending options. Further still, use SVG’s for icons and then output a copy as .PNGS so that the design is already set up for Retina devices. Furthermore, create a style guide. This will outline the colour swatches used on the site, the range of colours used for Type, the text sizes and the line heights margins and paddings. Doing this will give the developer a literal reference sheet and also keeps you more focussed to adhere to the rules you’d set earlier in the project. This is too make yourself less inclined to stray away and create new rules later down the line.
I believe that most of these points very much state the obvious. I also believe that most Designers are already practicing most of these points. But what I want to create is the mindset of being conscientious and being considerate that once the design is signed off, the job isn’t done. We’ve all seen our designs massacred once they’ve been handed over, and I believe that sometimes we have ourselves to blame for this. By being more conscientious in our process, working more closely with developers and accepting the ebb and flow, we create a design that has been conceived with the intention of being in the browser.