Introduction

As a designer, I’ve learned quite a lot from my time spent working with developers. I’ve come to realise that there are some things that I can do to make the relationship between myself as a designer and the development team I am working with a little less stressful.

It’s easy to see why development and design are a quintessential duo. They’re two sides of the same coin – each working in tandem, but focusing on different deliverables of the same product.

Although both skillsets are required to build a product that meets the needs of the people that will be using it; in a practical sense, a developer and a designer do not always work side by side, but rather one after the other. For example, a designer needs to consult a developer early on in the process. This is ideal not only for establishing relevant constraints, but also to ensure that what the designer has in mind can, in fact, be built. 

This is not to say that they work completely isolated from each other, but rather simultaneously helping one another during the process, ensuring that each other’s knowledge helps inform the solution.

In this sense, designers and developers work together like a tag team: each focuses on their own task before passing off (or handing over) to the other.

What are the main challenges between designers and developers?

There are many challenges that occur when developers and designers work together and it’s not always smooth sailing. Like with many things in life, communication is the most vital key to the success of the relationship, and the product in question.

The earlier a designer sounds out their ideas with the development team, the more prepared both parties will be for the task at hand. This will better enable the development team to be able to accurately predict and prepare for any technical hurdles or problems the designer might not have thought of.

Similarly, a developer cannot begin building a product without first having an in-depth discussion with the designer. If this discussion does not take place, there may be a disconnect between the designs and what is built, assumptions being made and functionality missed, which may lead to more iterations and extended build time.

Without the developer, the designer would merely have theories, research and ideas for optimising the product. Conversely, without the designer, the developer would have a product that doesn’t fully meet the needs of the people using it.

Should designers learn to code?

As a designer, you’ll often hear things like “learning to code will enrich your design work and make you a better collaborator”. While this statement may be true under certain circumstances, there are various other ways to consider development while designing.

Don’t get me wrong – as a designer, learning more about the development world can be interesting and empowering. But just like the design world, the development world is equally as diverse. You can find yourself going down many rabbit holes while familiarising yourself with the different tech stacks, which can be time-consuming and overwhelming.

Therefore, as a designer, a more practical and efficient approach is to learn from your developers. This can be achieved by keeping communication at the forefront of the process, rather than trying to become a developer yourself. 

“A designer learning how to code, or a developer learning how to design is like having a washer-dryer combo – neither end up being much good at either task. It’s better to have both a washer and a dryer. That way, each one can focus on their respective roles effectively and efficiently”

BL. Coskey, 2022

Some tools to bridge the gap

There are a number of tools that were created in order to enable designers and developers to work more cohesively. These tools help to ensure that developers and designers stay on the same page, so to speak – it enables their collaborative efforts to function more practically and effectively.

For example, Storybook is an open source tool for building UI components and pages in isolation. It streamlines UI development, testing, and documentation. There are also a number of component libraries, like Mantine, that offer the chance to standardise development, reduce code duplications, improve collaboration between teams, and drive scalability. A designer can ask the development team for access to any available pre existing component of the project. This way, the designer can more accurately plan their strategy. It can also serve as a powerful catalyst for the designer’s inspiration.

Deciding which problem to solve

As designers, we are driven by curiosity, coupled with an enthusiasm to solve problems. The more insights you uncover, the more problems you’ll identify — and the harder it becomes to settle on solving just one. Even projects with a well-defined problem statement can be difficult; as you dive into it, you want to solve every single problem that arises in user and stakeholder interviews. But there’s only so much time available, and there are only so many problems that are solvable within the scope of a particular project.

It’s inevitable that you’ll uncover new pain-points along the way, but you can’t change tactics every time this occurs. The challenge lies in staying focused, and your problem statement will help you to sustain this focus. 

Right at the start of any project, it’s generally best to take the time to define your problem statement. A good problem statement focuses on the user, and their needs (a rule of thumb is to avoid using “we” when framing your problem). A good problem statement addresses just one or two of those needs. Setting a manageable problem statement will help keep your wandering eye in check when you discover shiny new problems along the way.

As designers, we are continuously looking for ways to refine the experience of our users. Designing with consistency and purpose can help us to achieve this. However, it is not only important for the user — this also creates an effective workflow for designers and developers alike, and may even reduce the development time on a project and prevent scope creep.

Final thoughts

The best way to avoid discord between design and development is to communicate early on in the process, and frequently. Involve the developers as soon as possible. This way, they’ll be able to identify (and hopefully resolve) any potential issues long before the handoff phase.

Sharing knowledge is also key – while you don’t necessarily need to learn how to code, it’s worth taking the time to understand how the developers work, as well as the challenges that they face.

I think that in terms of design, we can focus on more than what the user needs and their experience. This is, of course, important and the main reason why we design, but we can also focus on the needs of the team, and how effectively the project can be developed overall. When your team lacks effective communication, efficiency and consistency, these challenges can affect how the project is developed, as well as the user’s experience.

What You Should Do Now

If you’d like to find out more about our capabilities and what we can do for you, or you’d like to join our team, get in touch.

Want to learn more about Storybook? Here’s Storybook in 100 Seconds.  
If you’re interested in component libraries but are not sure where to start, click here.