In many software projects, there is a cultural and communicational gap between designers and developers. To overcome this gap, design initiatives often focus on the developers only. Here I want to offer a few tips targeted at designers, based on my experiences as a developer working with designers in various software projects.

Know technical requirements for artwork

Often, you need to provide artwork or other design artefacts in certain formats: icons come in many different resolutions; some need to be JPG, others PNG with or without transparency. (Apple is famous for their extensive guidelines and requirements, but Microsoft and Google follow suite with similar requirements for the Windows Store and the Google Play store.) Colors are sometimes specified as hex (#009DF4), sometimes as numbers (0,157,244); font sizes are given in pixels or points, etc. Try to familiarize yourself with the requirements and deliver assets in the right format. This saves time for developers who won’t then need to do the conversion themselves, and it minimizes the risk of glitches and hiccups.

Work with the real product early on

Try to install the software that is being developed as early as possible, even if it is still buggy and incomplete. You’ll get a feeling how development progresses, and you have a higher chance that your feedback and guidance can be taken into account. In any case, it’s always much better to work with the “real thing” as much as possible, rather than to rely on mockups and paper prototypes, and just trust that they will be implemented as you planned.

Installing and running software early in the development cycle is often technically challenging. Don’t hesitate to ask developers for help if you cannot get it to work. They struggle as much as anybody to get the software running and they are usually helpful and understanding. Once you have the software installed, be prepared for constant updates and much iteration. There’s nothing worse than reporting on an issue and the developers telling you, oh, we fixed that yesterday.

There’s also something called a source code versioning system which can be quite helpful for non-developers. It shows a detailed history of every change that the developers make, every feature they work on, and every bug they fix. If the developers you are working with are using this, ask them to set it up for you so you can follow what’s going on, even if you never intend to work with the sources yourself.

Work together

In many companies (and SAP is no exception), designers tend to sit with other designers, away from the developers. Rather than just attending the weekly update meeting, try to sit with the development team as often as possible. If you’re in the same room, you can help with the many small design decisions they need to make throughout the day: where to place a button, how to align controls, whether to show a popup or just write a log etc. Developers are usually grateful if someone can help them with these questions. Sitting with developers and listening to their conversations also helps you to get a better feeling for what is difficult to do and what is not – which is often quite counter-intuitive to what “non-technical” people might think.

Be precise when reporting bugs

Bug reporting is so important, yet unfortunately, it is often done wrong by many non-technical people. A statement like “Feature X doesn’t work” is not helpful at all to a developer. You can assume the feature worked at least once on the developer machine, so there must be something special that causes the bug to appear. Developers need to know whether the issue is reproducible or not. If it is, give step-by-step descriptions with as much detail as possible. If it is not reproducible, try to describe the situation and circumstances in as much detail as possible. And always include the original error message text or screenshot. A bug report, just like a product, should be well designed. It needs to be easy to consume, understandable, thorough, and precise. Last not least: if you are reporting bugs in a bug reporting system, report only one bug per message. Bugs fall into different categories (e.g. easy, hard, feature request), they need to be tracked, and are often worked on by different people.

In my experience, following these tips can significantly improve the relationship between designers and developers, and ultimately create a better product.

Now I’m curious: what tips do you have?

Not logged in