.png)
I’ll be honest, the amount of coding knowledge I have can fit neatly on the back of a postcard. Sure, I can navigate the inspect tool in the browser well enough and highlight CSS issues but that's about as far as it goes.
Flipping the question around, would I, as a designer, expect a developer to be able to jump into Figma and prototype a problem flow, or layout a new type scale for a project? Definitely not!
So, would it really benefit a project if I could build my own components and suggest ways to set up the backend of a build? I don’t think so, and in fact it might lead to some icy tension between the team.
The working relationship between a designer and a developer is an important one. I’ve been incredibly lucky to have worked with some of the best developers, and I am always keen to keep this relationship working to its best.
Too often I have seen projects where a designer does their part and hands over to a developer to do their bit with very little open communication between the two. It can seem a lot like a designer chucking their designs over a wall, blindly hoping the developer will be there to catch and understand it. Once the designs are over that wall, any design decisions are then made by a developer or project manager often with little to no understanding of the design process that happened on the other side. The human-centred design thinking gets left behind.
How I like to work with developers is the polar opposite. I use Figma to create my designs and I control every element on that frame, producing pixel-perfect layouts. In reality, that’s not how the end product is going to look (the browser will see to that!). Although, my role does not stop once the static images are produced. There is no quick, simple ‘handover’ to a developer for them to start the build.
My design files are just one tool, of many, that act as a discussion piece between designers and developers. This, however, should not be the starting point for a developer to join the project. At ASquared we're a design-led digital product agency, but our developers are always involved in the project long before we reach this stage.
Most of my projects are based on the Double Diamond design process, starting with the important (and often missed) Discovery phase. The project’s developer plays a pivotal role in the initial stages by actively participating in the kick-off workshop, ensuring they understand project objectives and are aligned with the team and client.
They’re also there to take notes during user interviews, capturing valuable insights directly from stakeholders and users. Additionally, developers provide crucial input into the creation of user journey maps and ideation sketch sessions, leveraging their technical expertise to verify the proposed solutions are both feasible and aligned with development goals.
Including a developer's voice at the very start of a project leads to important conversations being had upfront saving time and resources.
In the middle stages of the design process, where we Define and Develop, effective communication is essential for delivering a successful project. Relying on just design software is not enough. Simply marking something as ‘Dev ready’ won’t cut it!
Having a variety of communication styles is essential so that everyone's preferred style is accommodated. Some of the methods I like to utilise are:
Communicating design direction through regular, early conversations with developers is key. For example, hosting design walk-through sessions before the client review not only fosters team alignment but also provides developers with an opportunity to share their insights and contribute meaningfully to the project.
During the Deliver stage, my favourite sessions are spent collaborating with developers to review builds directly in the browser or app. These sessions allow us to make refinements in the design and build that couldn’t have been anticipated from a pixel-perfect design in Figma. Working together in the code to solve problems and add those final touches is what truly elevates the product and reflects the power of open collaboration.
I look at the relationship between a designer and a developer as similar to that of an architect and engineer. Without Peter Rice’s expertise and knowledge of the great strength of cast steel, Sir Richard Roger’s design for the Pompidou Centre might have failed.
So, do I need to learn how to code in order to be a good designer? Not at all. I just need a fantastic, open team to collaborate with to bring great products to life. And that’s what I have at ASquared.
-
We try to foster a strong partnership and leverage each other's expertise at ASquared, so that our team can create cohesive, user-focused products. It’s not about knowing everything, it’s about working together effectively to bring ideas to life.
Let's see what we can make together.
From startups to scaleups and enterprise, we're always happy to talk to impact-focussed and ambitious organisations. Use our quote creator to get a better idea of scope, timescales and next steps.
