I’m going to skip the tired “should designers code?” discussion. You can be a successful designer either way, but I personally believe that software is never built with more attention to detail than when it’s coded by the person who designed it.
Let’s say you agree. Let’s also say you have at least some basic technical skills and want to use them to contribute in your day job. Now what? How should designers code? How can you actually get involved in the development process at work?
I can think of several possible entrypoints you might want to consider. These are all based on my own experience as a product designer on cross-functional teams of all sizes that viewed designers working in code as either tolerated, supported, or expected.
Some variables to keep in mind when reading these options and choosing where to start:
- Your own skill and comfort levels — Are you ready to dive in and write production code or are you still learning the ropes?
- The shapes of your teammates — Do you have a strength that can help patch an existing gap?
- The status quo of the team/organisation — Could there be any friction or gatekeeping that hinders your initiative?
I’ve listed them roughly in ascending order of demand on both time and technical skills, though the last two are interchangeable depending on a number of factors.
Pair program
This is by far the easiest way in, and even easier if if the team is already in the habit of pair programming. Just ask to join engineers while they build things.
Pairing is almost always productive and enlightening, but especially so when you’re new to a language or codebase. Ask questions, take notes, and offer what you can. That might be a good eye for detail, design system knowledge, CSS tips, accessibility considerations, or whatever else you’re good at. You can begin to establish your credibility as an asset to the engineering team without even having to touch your keyboard.
With pairing, you don’t have to wait until the work is “done” to find issues with it. Whether implementation doesn’t mean your expectations or your own design falls down when met with stress cases, you can adjust on the fly. It’s more efficient to have these conversations and fix shortcomings as problems are identified rather than let them block development.
Review pull requests
I like to kick off any new project or team by asking engineers to request my review on pull requests that make user-facing changes. It’s a good way to understand how code actually get shipped, and a great way to catch a lot of low-hanging fruit.
Depending on the stack your company uses, it might require a bit of knowledge to be able to read code for components or views and understand how it will look. It’s helpful if changes are deployed to staging environments so you can look at things and suggest changes to the code if you see issues.
If you have a design system where naming is aligned across design and code, you might be able to raise a lot of nits. Are the variables for colour, spacing, etc. the right ones? Did they use correct button variant? Is the copy capitalised properly? Did someone write new copy for an error case and it doesn’t make any sense? Don’t be afraid to get in there and make suggestions.
If you are or get really good in a certain area, you might be able to take more responsibility at this stage of the development process. At Litmus, I was a codeowner for all of our CSS files. Any changes to those files were flagged to me so I always had an eye on things and could jump in if needed. At GitHub, I’m on the codeowners team for Actions; I subscribe to Slack notifications for every new pull request assigned to that team and regularly stop minor mistakes from shipping.
Fix bugs
You’ll never prevent all of them. There were visual bugs in production before you started and there will be visual bugs in production long after you leave. But sometimes they’re almost as quick to fix as they are to document and explain, so it can be effective to do it yourself when you spot them.
Again, common offenders are copy issues, incorrect colours, and spacing misalignments. Those are approachable problems if you understand a bit of frontend code and/or how your design system works. Getting some reps in for creating a branch, making a very easy change, opening a PR, and shipping to production will expand your understanding and build your confidence.
You’ll eventually run into complexity in the code. Maybe you can’t change something because it also affects another area (or you can’t be sure what it affects), or a line of copy is actually generated by some confusing logic, or sometimes you can’t even find the source code for what you’re looking at in the browser. Those are learning opportunities. Stretch yourself to try to make sense of these things, but know when to ask for help and also when to cut your losses.
Scaffold UI
This is one of my favourite ways to work with engineers. Before I even knew how to render a new view in Rails, I would ask someone to create one for me and push it to a branch. Then I’d populate it with actual HTML and UI components, using comments as pseudo code for all of the logic.
Here’s a super basic example.
<!-- If user is signed in -->
<div>
<p>You’re signed in</p>
<button>Do something</button>
<!-- If user is an admin -->
<button>Do an admin thing</button>
</div>
<!-- If user is not signed in -->
<p>You’re not signed in</p>
You don’t have to know how to make anything work, just how to make it look like it should. This will render all of the elements, but as real logic is layered on, it falls into place. In my experience, engineers who are less interested or skilled in building UI loved this type of collaboration because I took those tasks off their plates and they never had to deal with me raising visual bugs.
As a bonus, the code you write in this way doubles as design documentation. There are communication and efficiency benefits to speaking the same language as engineers and not having to mock up or write out all of the various states and edge cases. Learning to think about implementing designs at this level also gets your brain working like a programmer’s. When you see that logic after it’s translated to actual language syntax (maybe in a PR you’re reviewing), you start to learn how to do it yourself.
That HTML above might ship like this. Doesn’t seem so unapproachable all of a sudden.
<% if current_user.signed_in? %>
<div>
<p>You’re signed in</p>
<button>Do something</button>
<% if current_user.is_admin? %>
<button>Do an admin thing</button>
<% end %>
</div>
<% else %>
<p>You’re not signed in</p>
<% end %>
Build prototypes
It’s not always the most productive design approach, but when it feels useful, I like to create proofs of concept as low fidelity prototypes in CodePen. This can be a fun way to explore options for interactions.
In these examples, my code was written to be thrown away. (Check out that old jQuery.) The visual design isn’t polished and the content isn’t realistic. But it was the quickest way to have every stakeholder understand what the different experiences would feel like so we could discuss them from the same point of understanding.
Prototyping can be whatever you want it to be. I prefer a sandbox, others like a branch in the real codebase. At GitHub, some designers even have a React boilerplate for creating high fidelity prototypes using our design system that feel just like the real product. Because you’re just making a temporary artifact, you have the freedom to use whichever platform and tech stack you’re most comfortable with.
There can be a few gotchas I should note. These will largely depend on the engineering team you work with.
The biggest hurdle you might face is that the organisation is simply not set up to support or allow you having access to code. There are many companies where non-engineers don’t have access to necessary systems and credentials, and requests are met with restrictive policies or at least warranted friction. There’s usually nobody to have your back, either — you might have to keep pressing the issue on your own or through your manager to make progress.
The other is that engineers might be sceptical that someone else wants to be involved. Some orgs are very segregated, and engineering teams can be insular. The best teammates will welcome the interest and help but some might feel like you’re stepping on their toes.
One way to approach both of these hurdles is not asking or telling but showing what you can bring to the team if you’re involved with code. Pair with engineers; build prototypes; use your browser’s inspector to debug issues and share solutions. Earn trust and doors will open.