Nowadays, it's pretty much impossible to go a day without seeing someone share an article on why designers should learn how to code. What people are forgetting is that collaboration is a two-way street. Developers are also capable of learning design — and they should — as designers should learn how to code.
Pitfalls of a non-collaborative interaction:
- Communication between designer and developer is broken (or totally absent);
- Not having a shared language and shared goals;
- Ratios being very disproportionate. Sometimes there are cross-functional teams with one designer and 75 engineers. Sounds insane, but it's pretty common;
- When a feature is being planned by the Product Management, specifications are handed off to a Designer to be put in a mockup and later visuals are given to a Developer to do the coding;
- When a design question comes up, and because the designer is already moved on to the next feature — these questions are being answered on the go, by the Developers and Product Management themselves. The solution, in this case, will often be taken without thinking about consistency and accessibility matters, and most important — will be spoken from a technical (developer-minded) perspective;
- You may call yourself an Agile team but if developers are still the last in line and thought has the implementers — you are working in Waterfall.
Agile disguised as Waterfall
One of the misconceptions regarding Agile is that it automatically equals collaboration. And that is not true across disciplines. The reality is that design usually happens first. The development process is agile but the design process is waterfall until it get to development. Developers and engineers are used to working on things as small chunks but designers don't have a good foundation in that.
The development process is agile but the design process is waterfall until it get to development.
What designers usually do, is envision the entire project, whether it may be an app, a website, an admin interface or whatever they are working on, and do compositions of complete screens with all the states to get a sense of the whole thing. And that leads to designers closing themselves until they are ready to show those compositions to everyone. Designers go away to execute their vision to the project and expect everyone else to follow that vision. This can be a problem if we want to nurture real collaboration into the team. If the creation cycle is too long, products also run the risk of being killed. People start to lose interest. They may say: "Is this creating value for the business? We're spending a ton of time and energy and resources on this thing, why is it taking so long?" Designers need to think more about the cycle of business.
So the question is — how do designers break their work into smaller chunks? When designers disappear for a week the expectation is going to be very high. But if designers share something they worked for half an hour there are no expectations and it opens space for a collaborative debate. Sharing smaller things — and it's ok if they are rough — when it comes to Agile, the first step for designers is figuring out how to work smaller rather than working on the entire screens. And when designers can work smaller they can work at the same pace as developers and that puts them on an even playfield and its where they really start co-creating.
When designers disappear for a week the expectation is going to be very high. But if designers share something they worked for half an hour there are no expectations and it opens space for a collaborative debate.
Of course, all of this can be debatable if we count on the early stages of the process where design research happens — through a human-centered research methodologies to understand customer's needs, pains, and behaviors — and enables designers to effectively address the problem logically and as unambiguously as possible. That research is what supports the user experience and the design decisions. But many times what the designers want to accomplish can be done in a similar way that's easier or less messy to code. And this is where is important to know when to seek developers' input. Their logical brain might come up with a better solution than what the designer had originally planned that works both for the user and them as well. When an argument can be made either way about whether a design element or feature benefits the user, choose the path that makes the code more reusable, consistent, or clean.
When an argument can be made either way about whether a design element or feature benefits the user, choose the path that makes the code more reusable, consistent, or clean.
When in doubt consider this framework:
Collaboration and trust are a match made in heaven
When designers and developers are in sync, they can truly make great things, but the trick is getting in sync in the first place. Although humans are hardwired to collaborate it is also a learned skill developed through trusted relationships. Working together has always been key to the survival of our species but we don't always have the instincts, experience, processes, or models to know how to make it happen in practice.
In software development, there's a practice called pair programming, which advocates for pairing two developers to work on the same task. In its strictest interpretation, the two developers will share a single keyboard and monitor. The benefit of this pairing is two minds, skillsets, and perspectives tackling one problem to get to a higher quality code. When trust is present, people step forward and do their best work, together, collaboratively and efficiently. They align around a common purpose, take risks, think out of the box, have each other's backs, and communicate openly and honestly.
The same should apply to pairing designers and developers to work together to complete a given work item. Designers aren't there just to make something look pretty, and developers aren't there just to work through Jira tickets. Both sides can learn a tremendous amount from each other. Whether sketching, prototyping or coding, when done well, the results of iterating and coding more quickly guarantees higher quality deliverables. Possibly most importantly, it shows that your team values each other's superpowers and leverages them. And when things do go awry, like everything else in life, align, realign, and realign again.
Designers aren't there just to make something look pretty, and developers aren't there just to work through Jira tickets.
A golden path to improved collaboration
When you are working in a non-collaborative team, the design-to-development handoff can be a scary thing. Sending your wireframes or beautiful screens to the dev team can feel like watching your kids grow. How will they change? What will they look like when they are fully grown into adults? Will they even remember you?
If your end goal is to create a great product, designing with the development in mind is about working as a team, not merely completing a step in a procedure. Developers need to participate in the early conversations so they can influence how things are designed and what can be designed and what is technically difficult to create. And since developers have a better understanding of the capabilities and limitations of the medium, when included from the beginning they are able to make a smoother process for everyone. Without their perspective, creative teams risk investing in ideas that can't be implemented as envisioned. Bringing technology into the design process can uncover new ideas while ensuring concepts get delivered on.
Developers need to participate in the early conversations so they can influence how things are designed and what can be designed and what is technically difficult to create.
A design can improve immensely with the input of a developer, and code can be better written with the help of a designer. When both disciplines are involved, the team can better answer tough decisions through expanded knowledge of the full picture. So it is easy to see that working together and understanding where you both come from will help tremendously in achieving project goals and overcoming obstacles. It will also be a powerful way to increase the sense of shared ownership over the final product.
In terms of the work process, designers and developers need to have a basic understanding of one another's foundation. I don't mean that a designer needs to know how to code, or that developers need to master typography, but at least there should be a shared understanding.
In terms of the work process, designers and developers need to have a basic understanding of one another's foundation.
Whether a developer or a designer, you can begin to understand your partner's perspective. It doesn't mean that you have to be an expert coder as a designer. But it's not going to kill a designer if they knew a little bit about how to use Jira and how to write some HTML and CSS, maybe even a little bit of JavaScript. That's going to help designers understand how things are built and foster better designer and developer collaboration.
Developers would also do themselves a favor by learning to see designs through a "designer's eyes" rather than looking at it purely from a development perspective — mastering that skill will greatly improve their projects. This means understanding the principles behind why designers make the decisions they do. Things like the color and size of a button, a specific font, or the way borders are used. The gods wouldn't go crazy if developers started understanding the reasons behind those choices. Having a firm grasp of the principles and theories that make up a good design — things like Gestalt Principles and basic visual hierarchy — can be a great deal of advantage as a developer.
Takeaway
Hopefully, this will help you transform your design and development process and help you build great products through a connected and efficient workflow. And the next time you kick off a new project, try to spend some time with everyone involved early on. Let's start involving developers on the starting part of the process where traditionally only designers are involved and keep designers involved at the end of the process, where traditionally only developers are involved. That way, everyone is involved throughout the process. There's nothing quite like developing mutual respect for each other's disciplines from idea to implementation.
