How designers can work better with developers

I’ve been working in design at a large software company for some 15 years now. At my company, we talk a lot about what developers can do to be more design-minded, and we in the design community spend considerable effort in educating developers about design.

Recently a developer in my company wrote the following post which sort of turns the topic around. In it, he suggests what designers can do to work better with developers. There are pretty basic suggestions like knowing the technical requirements for artwork (gosh, are there designers really delivering assets or specs in the wrong format?) to precise bug reporting to installing the latest build of the software being developed (oh, how I loath doing that. Guilty as charged on this one.)

I was wondering what your experiences have been and what tips you have on this topic.

1 Like

He’s right.

Design is a team sport. And team collaborate through the mutual appreciation of each other’s workflows.

If you don’t do the things your colleague suggests, then you’re creating friction in their workflow. That’s not going to get them excited to work with you.

Other things including learning how the model-view-controller system works and what the models they are working with are. As designer, you control the view. But you can only manipulate the view through the controllers the developers provide. And the controllers are constrained by the data models. If you don’t understand how the models work, you can’t collaborate.

There are more, but many of them will be dependent on the workflows of the particular development teams. At Center Centre, we’ll have the students work with a variety of development teams throughout the two-year curriculum, so they can learn the differences they’ll encounter and how to adapt.

— Jared

1 Like

I agree with @jmspool, your colleagues post has some great tips.

I would add that working together early in the process can really help create a better product. The developers you work with likely have an amazing and deep understanding of how software works and what possibilities there are for the design. If you collaborate right from the start you can gain access to ideas you probably don’t even know are possible, and you get a different perspective on your design ideas.

Working together early also builds a sense of team ownership, encouraging everybody involved to want to make the best end product possible. It will also help you create a shared vision for the product, and make the best decisions possible at each stage.

1 Like

I would even up what @emenel said by adding an additional take: I’d invite the devs to participate in any early design research. Field studies, concept work, design studios, and critiques. Get them to experience directly the interactions with users and stakeholders. The more they know about your rationale, the easier it will be for them to help you render your intention.


Yes! This is very true. Our best successes come from deep integration of practices, so much so that they almost run as one.

Very good point! Getting the whole team to participate in the design process, even if timelines and resources only allow this to happen in small ways and at intervals, is a mantra around here. In fact, some colleagues and I created an infographic about the design process that starts out by highlighting the importance of a multidisciplinary team and involving everyone throughout the design and development process.

We recently ran a 1 day workshop for a bank with members of the business (who attended the interviews), the design/dev team, the project owner and ourselves as user researchers (as we listened to customer stories) and with intention of designing the workshop setting to explore ongoing good practice, clear artefacts, clear communication between these teams and how the observations/insights bridge into design improvements (critical)

The design improvements based on customer evidence and business support from this workshop was magical.

Do like the idea of co-discover and co-design as a general practice.

I agree that co-design and multidisciplinary teams are great and very important, and I especially like the term “magical” in the latest reply. Getting back, however, to my original motivation with this discussion which was that I found it refreshing to turn the design / dev discussion around. As designers, we are often thinking about how we can get developers to be more design-minded (like by inviting them to participate in design activities) which is indisputably a great thing. The important thing in my view about the original post from my dev colleague is that he was making suggestions how designers can be more “developer friendly.” Clearly there is a whole bandwidth of tech savvyness among designers. However, I liked his relatively simple suggestions for things that designers can do to improve their working relationship with developers.

I too think frequently about how designers can better communicate and collaborate with developers.

Bill Buxton speaks about this at length in Sketching User Experiences:

“Designers have to be aware that what is ‘normal’ to them, in terms of how they read sketches and what they see in them, is not obvious to others, and they must take that into account in how they educate others, and what representation they use to communicate ideas. Those without design training … need to be sensitive to this difference of skills … before making uninformed judgments… [They] should do their best to gain some literacy in design representations, and designers should go out of their way to help them in this.”

Last year, I presented a set of heuristics (with companion checklist) to help designers evaluate their design materials from a software development perspective: