Contributing to a great developer experience (DX) as a designer

Published in

UX Collective

6 min readFeb 8, 2019

(This post was originally published on alexanderskogberg.com)

Over the years, I’ve learnt that a great developer experience plays a large part in a successful project. Here are my tips for contributing as a designer.

For the past eight years, I’ve been working as a UX designer and frontend developer in Stockholm, Sweden. When I look back on the projects I’ve been a part of, the ones that were successful and provided a great user experience always had a great developer experience. When it was neglected, the projects often fell short of set expectations.

Developer experience (DX) could (somewhat oversimplified) be described as user experience (UX) for users that are developers.

While the term developer experience isn’t uncommon, I feel it doesn’t get the attention and love it deserves. While a great developer experience requires a joint effort, I think designers can make a solid contribution and make a lot of things easier for their fellow team members.

Be open and positive to criticism

When starting a new project, be upfront that you want to tailor your tools and methods for collaboration. This makes for an excellent first impression and proves you have a good attitude to teamwork. I recommend having regular feedback sessions on this topic throughout the project (perhaps during your sprint retrospectives).

Treat developer feedback just like you would treat user feedback and improve your tools and methods for collaboration.

You should ask for specific feedback on your tools and methods for making and sharing design deliverables. Even if your tools and methods have worked well in past projects, they can always be improved. Make a habit of questioning and improving them with feedback from your developers.

However, don’t be a pushover if team members don’t want to try new things. Argue for what often has worked well and show them some samples of, for example, a clickable prototype in InVision or an exported style guide in Zeplin. It can be an eye-opener for everyone involved.

Teach yourself some code

Should designers code? This question has sparked many heated debates within the design community over the past few years.

If you ask me, I think having basic understanding of frontend development:

Isn’t needed for becoming a great designer (but will make it easier)
Will make an already great designer even better
Is essential for contributing to the developer experience

*If you want to improve your frontend development skills (or primarily design skills), the* *A Book Apart* *series is a great jumping-off point.*

Story time… Over six years ago I was still taking on some client work as a frontend web developer. At one client, I was in a team where we had to work with an art director that had literally no (yes, literally) basic understanding about frontend web development. His lack of knowledge and poor attitude towards the team hurt the project and the team spirit.

For example, this art director:

Never sat down with us and solved issues together
Sent us messy Photoshop files with hundreds of (often unnamed) layers
Didn’t understand or respect basic accessibility issues like poor contrast and too small text
Had an obnoxious attitude when given constructive feedback on his design and deliverables
Criticised us when fonts didn’t render as smooth on our desktop monitors as on his retina Macbook Pro (sigh)

With this story told, I believe teaching yourself some code will have a positive trickle-down effect on your way of collaborating with developers. For example, you will probably:

Get more respect for the complex problem-solving nature of programming
Understand technical possibilities and limitations better
Make more detailed and better design deliverables
Understand and get more respect from developers
Become a more valuable team member

If you don’t feel like teaching yourself some code, I suggest asking the developers if you can just sit next to them sometime while they’re implementing your design. See how they work, take notes and ask them questions that come up.

Make sure to read the following Twitter thread by Jared Spool on this topic.

Work together with your developers

If you were to believe some people on the Internet, you might get the impression that developers don’t like to work with designers and vice versa.

As a designer, I’ve never experienced this divide in any of my projects. I’d like to think it’s because I always make sure to be inclusive and have a good attitude from the get-go (or I’ve just been extremely lucky).

A few years ago, I worked with some incredible skilled developers at a client. The client also had two full-time designers that had been with them for several years. These designers were pleasant to deal with, but they didn’t spend much time collaborating with the developers. They sat in their own room and just handed over high fidelity sketches to their team. When the team had issues or questions, they always felt a bit bothered.

My approach was completely different. I sat next to the developers and included them in design process. Several times per week we had sessions where we would draw paper wireframes and whiteboard sketches together and discuss issues and possibilities we came across.

The developers found this approach productive, refreshing and fun (especially the sketching). Two of them later told me personally that they felt much more appreciated when being included like this.

Write motivating and great task descriptions

For keeping track of your backlog and current tasks, chances are you and your team are using software like Jira or Trello. Using these tools can be great, but reading poorly written and unclear task descriptions week after week can quickly drain your team members of both energy and motivation.

I strongly believe that every well-written Trello card will give the developer reading it a small boost of energy and motivation that can matter in the long run.

Tools like Jira and Trello are great, but only if you make them so by writing well-written tasks.

Here’s how I most often write my Trello cards:

Background information about the tasks at hand
A detailed description of the issue to be solved
How the user experience is likely to be improved
The design changes to be made (often with links to design resources)
Potential obstacles or pain points

Note: Remember to make your text easy to read by not writing too long paragraphs and using subheadings and bullet point list when suitable. No one wants to open a Trello card and be met with a huge wall of text.

Show interest in your team members’ work

Developers like designers who listen, care and are curious about their craft. This social aspect of the developer experience goes beyond making great design deliverables, writing motivating task descriptions and including the developers in the design process.

During lunch or a cup of coffee, make sure to every now and then to ask your developers about stuff like:

Possibilities and limitation of APIs they are or want to be using in the project
Their development environment setup (what editor they use, why and so on)
Their opinions on frontend frameworks (like React, Vue or Material-UI)
Which new skills and tools they learnt during the last year
Development issues they struggle with on a regular basis
What they wish more people knew about their craft
Software they wish existed

Who knows, they might even start asking you about design related topics (they will, trust me).