GUIDE
How designers and engineers can collaborate closer and build better digital products
Unleash designers’ & engineers’ superpower to solve the world’s most complex problems together.
Helping teams to validate business ideas quickly and build lean, user-centred products is what I am passionate about. A significant part of the job is encouraging individuals to work closer together. Oftentimes, engineers and designers, left-brainers and right-brainers have to work the hardest to find a fruitful way to collaborate.
Out of many conversations with engineers and designers as well as learnings from team retrospectives over the last years, I’ve synthesised actionable tips and smart rituals that will fuel every designer/engineer collaboration.
Why invest in this relationship?
Businesses are increasingly achieving their goals through software. They need to learn how to build great software, fast, and develop the agility rapidly react to user feedback. A proven approach to achieving this mission is establishing balanced product teams. Engineers, designers, and product managers work together in an agile manner.
As a designer, investing in your relationship with engineers helps you to understand code better, and to suggest potential solutions that will better inspire the engineers you work with. Everyone needs to be technical these days, and as a designer, it feels good to solve problems in a smarter way.
As an engineer, investing in your relationship with your team’s designer(s) helps you to understand how users interact with the code you write and to empathise with their needs. No one likes to rewrite a feature because it was poorly understood when it was first created; working closely with design allows us to reduce unnecessary work and spend more time making cool stuff.
Designers and engineers are a strong alliance, equipped to solve the world’s most complex problems together. Let’s unleash their power by fuelling their collaboration.
1. Rethink your rituals & habits
I’ve collected a couple of rituals & habits that have helped engineers/designers in the past. Some of them are well-known from agile software development, others are rather new. They’re all about moving from a world of ‘handoff’ with little collaboration to a world of ‘handshake’ with close collaboration.
Tool and technology intro
This session is a kickoff at the beginning of a product lifecycle. It’s an intro to the tools and technologies you will be using. It’s also a great opportunity to teach others the parts that are necessary for their work. This includes enabling engineers to work with Figma or whatever tool designers use to translate designs into specs. Show them how to export assets etc. Designers get access to the pre-live environment so that they can see the status quo of the product at any time.
For example, a native app differs from a website. Each platform has its unique interaction patterns, the programming language differs even more. Whilst engineers tend to be specialised in one platform, digital designers are generally not. You may well have to rely on each other’s expertise around the platform your product will be built for. It’s worth sharing knowledge and best practices from day one.
Casually hang out together
Human connection matters. A lot. Especially when working remotely, I would advise to actively plan for human connection. Building relationships with the humans you work with requires a little work upfront. So turn your video on and open up about yourself a little.
It might be a scheduled coffee break once or twice a week, or an evening hangout. I’ve also seen team breakfasts. This is work time too, so try to schedule it at a time that works for everyone. Be mindful of people that don’t work full-time. When working remotely, playing an online game like skribbl can help to get everyone laughing together.
Reach out, at any time
Daily standups are like a sport’s team huddle before a play and a great way to highlight blockers and ask for help. The team gets together and everyone briefly shares their progress and challenges for the day so that you can step up and help each other out.
However, standups are not the only time you should act upon blockers. A mature relationship between engineers and designers means that you can spontaneously reach out and get time together within a matter of minutes or hours. Not via email, not via a Jira request. Don’t hide. Afraid you’re interrupting the other person/pair? Don’t worry.
“Approach the engineer/designer with a friendly wave and a “let me know if you’ve got 5 mins”. Or a slack message, asking to jump on quick a zoom call. That way, you’re not disrupting their work. Still unsure when to best approach? Grab people on the go: for example when they are are just sitting down after lunch. If you want more structure, think about naming an “interrupt pair/person”.”
— Gagandeep Kaur, a software engineer at VMware Pivotal Labs
Dev/design pairing
This is my favorite ritual. Engineers and designers improve the design of a product, coding together, live. That way, you can accept user stories even when they are not yet visually perfect, as long as the functionality works. Small design improvements make it to the designer’s backlog for the next pairing session.
Dev/design pairing is usually driven by the designer. They closely observe what has been built and makes notes on improvements. It can take from 1–2h per week up to several hours when you are about to release your next iteration. Whatever you cannot fix during this time, will make it into a bug or story and will be prioritized later.
Dev/design pairing can be scary for engineers. You will sit in front of the same screen (or a screen share) with the designer and will try to adapt their suggestions, live. Don’t worry, the designer isn’t testing how fast you can code. They will also embrace the fact that part of your job is not knowing and researching on the internet. And if you can’t find out after some research, that’s ok too.
Designers sometimes fear these sessions because they lack the proper terminology. Don’t worry. You can use any words, the engineer will ask until they understand. Plus: over time you’ll get used to how engineers relate to things and your ability to talk in code will improve.
A little kindness can go a long way when establishing these sessions. Over time, you will get used to each other and the sessions will become more fun. And your product will benefit a great deal.
“It’s amazing how the tweaks from our dev/design pairing sessions have improved the look and feel of our product. It’s so much more fun to use now. The pairing is like a timeboxed, additional code-review, where you can optimise things that are not tied to stories, but will benefit the user. Since we are doing dev/design pairing, I have become a more active advocate for the user and their experience.”
— Maximilian Zuleger, software engineer @ Audi Software Development Center
Ideate together
Amazing ideas emerge when you include engineers in ideation sessions. It’s great a way to live shared product ownership. It will empower each team member to take an active part in where the product is heading. It’s the designer’s role to facilitate these sessions and make sure every idea is heard. They form the basis of the designer’s future work.
At VMware Pivotal Labs, we call our ideation sessions design studios. The whole team gets together to solve a clearly defined problem. The goal is to find as many solutions as possible in a short amount of time (say, 2 hours). Collectively prioritize which parts you will proceed and create actual design hypotheses for. We run 2–3 rounds of sketching and do a shareout after each round. That way, others can get inspired by ideas and think them further.
💡 Read how to run a design studio remotely.
Design critiques
Feedback from the product team is a great addition to feedback from real users. Fellow designers can provide their user centred view. Engineers can provide a more technical perspective on feasibility.
There are many ways to do a design critique. I like to do something like this: In a weekly rhythm, the designer brings what they are working on (high level user flows, visual designs, research hypothesis etc.) to a 1h session with the whole team. Print out artefacts or share them on a digital whiteboard.
I like to start by introducing the challenge in advance. I also specify what kind of feedback I’m looking for (e.g. “Is there a leaner / smarter / more user-friendly way to do this?”). Then, give everyone time to silently review and write their feedback on sticky notes. That way, you ensure everyone, not only the loud people are heard. Too many sticky notes? Ask everyone to dot vote for their top 3.
After the individual review, give everyone the same amount of time to share their feedback with the group. As a designer, listen closely and do not defend your work. Close the session by thanking everyone for their contribution, as it is an integral part for the next design iteration.
Designer/engineer retrospectives
Retrospectives are another well-known tool from agile software development. The whole team comes together after each iteration and reflects on how they can improve as a team. You can either make the engineer/designer workflow part of the team retro. Or you can introduce an additional, smaller retro, dedicated to this relationship.
Need inspiration for your retrospective? Our team at VMware Pivotal Labs has built postfacto, a remote retro tool to self-host. It’s free to use for everyone. Whatever format you choose, it’s all about the action items. The more concrete actions you have, the better. Item per item, ask people to volunteer to be responsible. If no-one is happy to volunteer re-think or delete the action.
2. Rethink your tools & workflow
Designers, have you heard of Developer Experience? It means that you consider engineers as your users, too. If you think about it, it makes total sense. They’re the very first people that work with your design before a user even sees them. I’d recommend treating the developer experience like the user experience of your product. Try to improve the engineers’ experience working with your designs.
Considerations
Engineers need to be able to extract specs, behaviours, and assets from the design file. It’s worth considering a design tool that enables them to do this independently and conveniently. In addition to the regular design needs, consider the following:
Working in the open, in real-time
Can everyone from the team see the design progressing in real-time? Can they give feedback in a convenient way? Are the design files optimised to load fast for ‘lightweight contributors’ like engineers? A web view that takes ages to load will become utterly annoying if you need to work with it on a daily basis. Working in the open is equally significant for engineers. Everyone in the product team should have access to the pre-live environment to see new user stories come to life. They will want to give feedback here, too.
Translating design into specs
How easy is it for engineers to take specs and behaviours from designs and turn them into actual code? I recommend having design and specs live in one tool so that both always reflect the latest version.
“But how do I know which version of the design I should work on if they’re not officially handed over to me?” you might ask as an engineer. That’s a legit question, considering the designer might create multiple versions to try out what works best. What has worked well for teams in the past is to create a dedicated page in the design document that only contains designs that will not be touched (for now!). A ✅ ready for backlog page with all necessary viewports, states and notes on the behaviour. From this page, I like to create links to dedicated screens that I can attach to user stories. That way, updates are reflected in real-time.
Assets, accessible for everyone
“Could you please export X for me?”. A question no-one should ever have to ask a designer again. Great design tools make assets accessible for anyone to export. To enable everyone in the team to do this, I like to run a quick “how to export assets” tutorial as part of the tool and technology intro mentioned above.
Global styles and names
Defining global rules for your designs saves time. A design system defines how elements look and behave. So that you don‘t have to invent them from scratch for every new product under the same brand. Design systems are usually manifested in guidelines as well as a library with two versions. One for designers (e.g. a Figma or Sketch file). And one for engineers (e.g. a component library)
No matter if you have a component library at hand or not. Designers and engineers should get together and agree on naming conventions for the basics like type styles, colours etc. This will save engineers a lot of time later on.
Ok, but which tool does all that?
There are several great tools out there for digital design. As design tools evolve on a constant basis, don’t get too friendly with one.
Currently, the design tool closest to my heart is Figma. They have invested a lot in making the designer/engineer collaboration smooth. They’re promoting a mindset of moving the relationship “from handoff to handshake” (Thomas Lowry, Designer Advocate at Figma).
Sketch previously relied on third party apps like Abstract or Zeplin to provide design specs to engineers. They have introduced a new developer handover function in their 2020 cloud version though. Adobe XD also enables extracting design specs as css snipets.
3. Rethink your ways of working
Teams that have the freedom to take product decisions independently and share product ownership equally have the best chances to build useful digital products. Only when designers, engineers and product managers work together on eye-level are they able to bring the various perspectives and experiences necessary to drive innovation.
Collaborate closely and share knowledge
Cross-discipline collaboration and knowledge sharing are key. I recommend you either sit in the same space or are connected via slack/zoom and talk on a daily basis. Involve the whole team (yes — engineers too!) in key product steps like user research or ideation sessions. Everyone must be able to empathize with users and contribute to where the product is heading.
For some engineers, taking part in user research might feel a bit weird at first, because it is widely considered a ‘design activity’. I always encourage fellow engineers to take part in user research though. It’s very powerful to see that what you’re building can actually affect people’s lives.
Marco Garofalo, senior software engineer at VMware Pivotal Labs
Share product ownership
As a team, you are accountable for how well customers get the job done through the product you’re building. It’s not about how beautiful the design is, how many lines of codes you have written, features shipped or bugs fixed.
These things only matter if they have a measurable positive impact on the product. Make sure you set goals that everyone understands and works towards. Measure the progress diligently and have it visible for everyone in the team at any time. You are all equally accountable for reaching them.
Cherish both perspectives
The value that it brings to it’s users is what makes or brakes a product and the designer is the person responsible for finding and framing this value. Designers often misinterpret the technical complexity of their ideas though. And that’s ok. Inviting engineers to the table from the start will help you come up with better ideas that are also feasible in a reasonable amount of time.
Build great software by equally valuing both perspectives. The designers’ impact to make it useful and the engineers’ impact to find a feasible way of building it.
Build, measure, learn 🖤
I believe the lean startup feedback cycle is not only helpful for building products but also for building teams. I’d encourage you to check your workflow and rituals regularly and thoroughly. I’ve adapted rituals and switched design tools so many times in my career, constantly on the lookout for which tool or format will enable the team to do their job even smoother in the future.
What has helped you to improve the engineer/designer relationship? I appreciate your constructive feedback and am happy to have a conversation about this topic. Find me on LinkedIn. A big thanks to Gagandeep Kaur, Marco Garofalo, Maximilian Zuleger, Tim Jarratt and Froso Ellina for sharing your thoughts and feedback. They form the basis of this article 💚
