I had a discussion today with some friends about this, one of whom wrote his own entry on what we should call it. I can’t speak for all developers, but I can say that I’m frustrated. Everywhere I’ve worked, we’ve largely followed the waterfall process between design and development, regardless of whether or not we’re trying to be agile. This means that developers are usually not brought into the project until after designs are finalized. I understand that clients want to see what their resulting website will look like before it’s built. However, there are pitfalls to this process that can negatively affect development team morale, velocity and project quality over the course of implementation. And no, the solution is not to tell designers to learn to code. It feels awful that we’re still having this conversation in 2021.

Platform Constraints

Most software developers these days have to work with platforms that have their own unique sets of constraints. Examples of “platforms” in this context include web browsers and mobile operating systems. Web developers specialize in knowing browser constraints and mobile developers specialize in knowing mobile OS constraints. We need to know these things so that we know how things can be built, what we can’t do and workarounds we might need to implement to achieve a certain effect. I personally don’t expect anyone else to know these things, including designers. And because designers usually don’t know a platform’s constraints, they might design something that’s either virtually impossible or takes a lot of development time to implement. If we agree to implement it without developer input, the project’s timeline and success are jeopardized.

Additionally, developers have institutional knowledge about the systems that designers might not have. Consider this situation: Designers are brought in brand new to a system that’s been in place for years but needs a bit of a visual refresh. Because they’re the ones who write and maintain software features, developers are some of the best advocates in this situation to make sure designers account for every use case of a feature and don’t design a whole new feature that needs to be completely rewritten to match the new design.

Too Many Components/Inconsistencies

10 years ago, designers designed and developers developed entire pages. We wrote a ton of HTML and CSS and almost none of it was portable or reusable. It was messy, ugly, inefficient, and difficult to maintain. Within the last few years, web developers have taken a component-first approach. This means that we create reusable pieces that can be used anywhere on a website. This increases website performance because we’re reusing code (DRY) and consistency in how it appears. One example of this is having a finite set of buttons that have specific purposes or images with predefined finite proportion sets. Some designers I’ve worked with in recent years totally get this concept and use it religiously and I love them for it.

On the flip side, there are designers who still design per-page to be implemented into systems like content management systems. The total number of different “components” across all designs is somewhere in the dozens and each of them is only used once. This is a situation where we need a small, finite number of components because we want to keep the interface simple for the client and the system can get bloated with too many new pieces. We also don’t want to over-engineer the system so clients can build 100 different components. The more code complexity we add, the more difficult and expensive it will be to maintain.

Programming is Creative Too

Include developers in early stages of the project, including design. When developers can review the designs directly with designers—before they’ve been approved by stakeholders—we can actively ask how they expect certain features to work, how things should look on various screen sizes, etc. Conversely, we can explain that that super cool thing they want might not be done and scope might need to be reduced for launch. Developers can also point out when designs are made up of far too many components and we will have to over-engineer the system to support them. Having that synchronous communication reduces the feedback cycle time and enables developers to work with more agility. Developers can at least get started on coding a base idea of what a component should be and can continue to improve it as discussions continue.

We all know that design is a highly creative and thoughtful process. I greatly respect designers, who have deep knowledge and creative vision that I’ll never have. (You can see from any one of my creations that I’m not a visual designer.) Non-programmers I’ve spoken with think that in programming every problem is black and white and can be solved easily. Programming is a creative activity too; software architecture, algorithm design, etc. all require deep thought and creative solutions. Bring us into projects at the discovery process and you’ll end up with a product whose code and usability matches the beauty of the designs.