Designers and developers are two sides of the same coin. However, they are not always as in-sync as they could be. After many years of working in the IT industry, I’ve seen countless times how the relationship between these parties can become a lot less efficient due to minor details that snowball as the project progresses. Here’s my take on how to deal with that.
1. Think of Developers as the First Users
Designers always prioritize the users’ needs above everything else. And they should. However, it is important to consider how software development evolves before reaching the consumers’ hands. Any initial vision of the product experience must go through a programming stage first. This is the “produced” version of the product that people interact with, not the one based on design documentation.
Based on this logic, it is easy to see why developers are the first consumers of the product design draft. Mixing this into your teams’ practical workflow makes it easier to think about how you want them to approach things. Particularly, how UI designers and developers communicate with each other. Here are three topics you can take a look at right now:
- Documentation Exchange: UI designers deliver many types of design documentation to development teams. While it is their work to turn any abstract or concrete idea in there into working software, all this information can quickly pile up and get out of hand. Check how efficient are the channels through which both teams share files and comments, how often it is done, and if there are any minor details that could be improved.
- Visual and Written Balance: Design documentation can sometimes be extremely detailed on the visual side while other times it focuses a lot on the written side. While the right balance will always depend on the nature of the project, it is important to aim for a certain ballpark in which both parties are comfortable communicating. Learn what is too much and too little for both and work from there.
- No-UI Rules: Non-visual rules are not new, but still fairly recent to most. Software products are gradually leaving full-attention GUIs behind and moving towards less obtrusive interaction patterns. Designers should be able to easily communicate how No-UI rules are supposed to work within a system. This way, developers can “consume” them and align them with other elements or features of the product.
So, basically, this first step is all about coordination. The design team’s workflow must be aligned with the development team’s workflow. How you do this depends a lot on the characteristics of your team. You might want to create a specific shared space for the project (aka a wiki), include more documentation meetings in the process, or set very specific rules about what use cases are documented and how. There is no easy answer here as this is more of an iteration and experimentation process.
2. Prevent Teams from Shifting Accountability
Most non-designers believe the work of a UI designer is done once all screens and documentation are finished. In reality, completing the design of a project is only half the work. Today, the better approach to UI design is less about screens and more about the features that live behind those screens. It is a back-and-forth process that requires constant and creative involvement.
Developers, on the other hand, work the project at a parallel pace. Because of this, new rules and constraints are inevitable, especially once Quality Assurance engineers get involved. Here, preserving the initial experience of the product becomes a challenge. And here is also where shifting accountability can become a risk (I did this, because she did that, because he did what, etc).
The secret to avoiding this is to focus on the experience rather than the design or the code. The goal of both parties is to make the best possible product, which is not always what either of them envisioned at the beginning—and that’s OK. Taking a project from mockup to reality implies evolution. And, unlike material or visual elements, experiences can easily be preserved as the project evolves.
3. Embrace Change, Embrace the Bigger Picture
Since we are on the topic of evolution, let’s talk about change. Or, more specifically, flexibility to accept and make room for change. Since both designers and developers work different tasks to achieve the same goals, the workflow of both parties must also adapt to the way the project unfolds. This is going to happen whether anyone likes it or not, so it’s better to go with the current and not against it.
Designers, on one hand, need to embrace change when it comes to documentation. Most projects will require adapted or entirely new documentation from the beginning—custom software doesn’t get built twice. Having an adaptable workflow makes it easier to avoid frustrations as the project progresses and helps everyone with collaboration.
Developers, on the other hand, have to deal with their own can of worms. From unforeseen technology constraints to abrupt changes in release dates, software engineers are focused on the more functional part of things. Still, they are part of the project from start to finish. The “design something, send it to development, and launch to market” process does not work anymore. Both design and development are living practices that must put evolution at its core. Technology changes just as much as users change. It is everyone’s job to morph and grow with that.
Software Development is a Team Sport
Creating impactful digital products takes time and a collaborative effort that’s the furthest away from a linear process. The better fluency between designers and developers, the faster the development and the higher the end product’s quality and the better your team will deal with UX Debt. Today, I firmly believe that collaboration skills are more valuable than specific deliverables. Collaboration is the first step towards amazing results.
