Matt Gemmell

How Developers Can Help Designers

6 min read

This article is a follow-up to my previous one, How Designers Can Help Developers, and covers the reciprocal situation. As developers who work with designers, it’s our job to make that cooperation as smooth and easy as possible.

The spec

Know what you want

The most difficult part of commissioning a graphic design job is knowing the sort of result you want. There can be a tendency to just ask your designer to “make something” – and they will, but it may not be what you’re after. You wouldn’t accept a requirements specification for a development job that was too vague to work with, and designers aren’t any more psychic than you are. Devote sufficient time to narrowing down the sort of work you’re looking for.

Examples are helpful

If you don’t have a strong concept in mind, you probably at least have preferences. Put together some samples of things you do and don’t like, noting what aspects you’re responding to, and why. Other people’s work is fine, as are portfolio pieces by your actual designer. Often, the process of putting together these sample likes and dislikes will help clarify your vision for the work you want done.

Trust your designer

A wise person uses the talents of others, instead of trying to muddle through alone. Trust your designer’s skills and experience. Don’t treat designers as scribes for artwork; allow them the flexibility to contribute and to delight you. Don’t be too prescriptive.

A sketch goes a long way

You’ve probably hired a designer because you’re not a great designer yourself. If you’re like most developers, you’re likely to be a terrible designer, lacking any significant ability in visual arts. That’s absolutely fine, and normal. Nonetheless, a (terrible) sketch of what you’re after is often far, far more useful than a description – no matter how precise. Don’t be afraid to scribble something down for guidance; it can be exceptionally useful to make sure both parties are starting on the same page.

Consider sample data

As a developer, you have an idea of what sort of data your app will manage and display. Your designer, unless told otherwise, is likely to use generic sample data or even random text for layout purposes. It’s better for both parties if you supply realistic, meaningful sample data from the beginning – paying particular attention to extreme cases (shortest possible, longest possible, etc).

Present all the work up-front

Go to extreme lengths to ensure the entire design job is described up-front, as for any job. Adding things later will not only potentially incur disproportionate costs, but will also be harder to schedule, and could have knock-on effects on already-completed design work. As a developer, you’re fully aware of the huge cost of late-stage changes – the same applies to design.

Remember design constraints

Your designer will create their best work to meet your specifications, so it’s important that those specifications are accurate – including limitations. Screen size, orientations, font licensing, required branding colours/liveries, available space for ads or other static elements unrelated to primary content, and so forth. Think carefully about the constraints for the design, and ensure your designer is aware of them from the start.

Professionalism

Be responsive

It’s to your financial and professional advantage to be responsive when your designer presents work for feedback, or asks a question. Design isn’t something that should be done after development, nor even during: ideally, a completed spec is followed by a design, which is followed by implementation – so devote due time and diligence to working with your designer.

Don’t assume it’s easy

The bane of a developer’s life is that non-developers assume that programming is easy. A change to a feature, supporting multiple things instead of just one thing, or changing how something works – we often have to explain the effort involved, and justify the resulting cost. The same applies to design, so resist the temptation to assume that a change must be easy or quick simply because it’s “just” visual.

Don’t micro-manage

Your designer is a professional, and their discipline isn’t measured by the same metrics that so irritate developers (code check-ins, lines of code per day, tickets resolved, etc). Designers must often allow ideas to develop, to experiment with approaches, or to step back from a problem for a short while to get fresh perspective.

Progress in a design isn’t quite as readily measurable as with programming. Allow time for the creative process, and let your designer present you with a coherent, consistent and fully-developed piece of work when it’s ready.

Use the same tools

Wherever feasible, have the same tools as your designer – at least to the extent of avoiding undue inconvenience on either side. For a professional developer, a copy of Photoshop isn’t going to break the bank, and can be a very wise investment when it comes to re-doing artwork cut-ups on a deadline if your original designer isn’t available. At the very least, have something that’s sufficiently up-to-date that your designer doesn’t have to jump through hoops to work with you.

Speak the same language

Just as your designer accepts the responsibility to provide graphic cut-ups from her design for you, you should similarly accept the responsibility for translation between the design work and the programming world. If you have peculiar file-naming requirements, take care of them yourself later. If you need colours in hex format for CSS, or in RGB zero-to-one format for use in code, do those conversions yourself, and don’t needlessly complicate your designer’s life. Omit or translate terminology that won’t necessarily make sense outside of your implementation work.

Allow use as a portfolio piece

If your designer is particularly proud of their work for you, they’ll ask to use it as a portfolio piece. Allow them to do so. It’s the decent and sensible thing to do, and it’s free marketing for both of you. It also reinforces mutual goodwill between the two of you, which will be useful when it comes time to commission the next design job when your designer has a busy schedule.

Business matters

Pay on time

Pay your designer on time, without excuses. Their payment schedule is independent of your developer process and release date. As soon as you’re happy with the work, pay whatever remains of the bill in full. For extra goodwill, and where feasible, pay immediately instead of according to the invoice’s due date.

Don’t condone spec work

Spec work is work done before payment is agreed upon (and often without any guarantee of payment). There are many web sites where you can submit a design brief and a budget, and designers will then create work to fit your brief (to a greater or, usually, lesser extent). You’ll then choose the piece you like, pay that person the fee, and everyone else gets no payment at all for their work.

This is a terrible, destructive, unsustainable way to do business, and it’s actively damaging to the entire industry. Do not invite or support spec work, in any form. Instead, do your research about designers you’d like to use (getting personal recommendations, and requested portfolio examples), then choose a designer, put a contract in place, and work with them.

Understand the model

Commonly, you’ll receive one (or perhaps a small number more) design to fit your brief, and will be entitled to one or more rounds of changes or refinements to that design, as part of the agreed-upon fee. Any further concepts, designs, rounds of changes or other extra work beyond that will incur extra cost. That’s an entirely normal, reasonable and fair system, and it’s the reality of the design industry.

The way you offset the uncertainty of extra cost for design changes is to present a complete and accurate brief at the beginning, and to be responsive to your designer during the process. By contrast, you do not complain about the basic model, or expect unreasonable amounts of design hours for a flat fee.

Source code is extra

In the majority of cases, the “output” of development work is the source code for the app or web site; the product and the inner workings are one and the same. Thus, in most cases (though by no means all) for contract development/programming, what you’re selling is the source code. That isn’t quite so true in the design industry.

The “output” of a design is the graphic work, in a format suitable for use – commonly PNGs, EPS files, PDFs, perhaps JPEGs, or some other such thing. It’s not so common for the actual work files (Photoshop PSDs, Illustrator AIs, etc) to be included in the fee – indeed, it’s normal for those to cost significantly more. This is normal, and equitable – if you need them, be aware that it’ll cost extra, and be willing to pay it.

Final thoughts

As I said in my previous article, design and development are two inseparable halves of the process of creating quality software. Professionals on both sides should always strive to work together as effectively and respectfully as possible.

Feel free to follow me (@mattgemmell) to keep up to date with new articles here, or subscribe to the RSS feed. Likewise, do feel free to share your own thoughts on design, development, and how the two fields fit together.