In one of our previous insights, we discussed why designers should learn to code (if you’re curious, the answer was instead a solution: pursuing a holistic approach to specialization and encouraging designers to widen their skillsets, should they wish to do so). At Mäd, we approach projects with a few key priorities in mind: Enhance Empathy. Improve Designs. Streamline Project Management.
To do that, we try to reach a mutual understanding between our design and development teams. The first step in doing that is to set a shared goal – this goal should take into consideration the abilities and limitations of both sides before attempting to take action.
A product design team is responsible for conceptualizing a user interface that is both functional and visually refined. They spend the majority of their time balancing function and form to create user-centric solutions on different platforms. Their goal is to organize and design all the necessary elements of the product in a way that allows for the best possible user experience (UX). In summary, designers work on the usability, layout, and visual appearance of the digital product or platform.
On the other side of the digital product are developers. They deal with the behind-the-scenes job – writing the code, which, essentially, makes the product work. If there is no code, there is no functionality in the product, and it is virtually inoperable. Developers convert the design into a usable application, building features and functionality via code to create the final working product.
This is why design and development may often be divided into consecutive but separate stages in the project timeline.
As designers and developers have different responsibilities and use different software throughout a project's lifecycle, it can be challenging for them to fully understand each other’s methods, tools, and capabilities. Designers can relatively quickly create a visually engaging interface that fulfills user experience objectives, but they often lack the understanding of the complexity of coding this in the final product.
Alongside some of these broader differences between designers and developers, it’s important to note that a digital product team may be made up of designers and developers within the same consultancy (i.e in-house) or two separate teams from two (or more!) different companies.
However, whether we’re helping clients on a digital transformation project or collaborating internally, the relationship between design and development can make or break the end product and the success of its implementation.
One commonly recurring issue when we work on digital development projects is the communication gap between design and development.
In the grand scheme of things, design and development have a shared objective: to bring a complete, workable, and smooth digital product to life.
Some of the challenges we’ve encountered in our own work tend to highlight communication difficulties between design and development teams. Often, companies follow a process in which design begins the project, and later hands this over to developers to complete. Typically, the two teams don’t get to sit down together to come up with a shared strategy – they work separately, in stages.
Oftentimes design and development responsibilities may be split between different companies. In these situations, it's even more important to clearly establish the goals and any intricacies of the project from either side. The developers on the client (or vendor) side can’t start or complete their work unless designers give them all the requirements they need to do so.
The designers may also struggle to communicate specific user goals to the developers in an efficient way. Finally, it is not uncommon that designers may conceive things that are difficult or unrealistic to develop in practice.
This just slows the progress of the entire project and reduces the quality of the work.
Communication should be a focal point from the early stages of the project. When briefing clients, it’s vital to already involve both design and development at this phase and establish clear-cut objectives. Keeping all parties in the loop will help reduce the inevitable back-and-forth of feedback on deliverables, requests for additional features, and so on. It will also help designers avoid over-designing because they will know exactly what the developers need. Sharing perspectives prevents unrealistic expectations for the product and helps your team avoid unnecessary work in the long run.
Here’s an effective way to go about this. At the start of the project, developers (whether internal or external) need to set tasks by order of priority. They should provide a list of the most immediate flows they need – this would simplify the design process by allowing designers to hand over in batches, following a timeline set by priority.
Both teams (and the client!) should then catch up frequently to review what has already been done and make any adjustments based on the comments and feedback. Meeting while the work is still ongoing also lets both parties test the product together: for instance, designers can track how the UX/UI features will translate onto the website or app and use this to structure further design elements. Regular interaction will streamline all stages of the project, from scoping and design to development and testing.
Using the term “handoff” implies that the designer is handing over their work and their job is done here – when it is really not. Both designers and developers need to continue working together until the product is shippable.
In hindsight, there shouldn’t even be a gap like this between both teams, that they are working one at a time, not simultaneously. As we’ve established earlier, they should be collaborating from the early stages of the project to set broader goals that encompass the objectives of both the design of the product and its development. That way, they will have each other’s best interests in mind from the start, and have better awareness of each other’s needs until completion.
Try to define at which point of the design process the developers should be involved. We generally recommend having both teams work together during UX wireframing, which is where designers are visualizing and drafting the “skeleton” of the digital product.
Having this communication structure set up early on is likely to result in a design and code that are both more practical and efficient. And if we are still having a “handoff”, designers should try to keep their work as tidy and comprehensive as possible. This will make it easier for the development team to grasp and organize the files and work on their part.
At Mäd, we champion a “lean” approach to design and development, versus the more commonly used“waterfall” methodology. This is something that you might find useful when dealing with the “design handoff” issues mentioned above.
The “waterfall” approach requires low customer involvement and a clear list of requirements. The entire scope is defined upfront, and the assumption here is that projects have a linear structure with milestones that are passed one after another in sequence. There is little-to-no feedback or communication. Therefore, the design and development teams (especially if not under the same company) end up working separately: designers complete their part and hand it over to the developers without any further collaboration. In our experience, this approach simply doesn’t work as the expectations of the final product cannot be effectively communicated to all stakeholders.
Within the “lean” method, however, projects have an iterative structure, meaning that our designers and developers will work together from start to finish to create, test, and revise the product until they're satisfied with the end result. In doing this, it’s much easier for designers and developers to collaborate and better manage the product requirements and expectations. Oftentimes, by adopting a lean approach anything that doesn’t improve the functionality of the final product can be removed or quickly adjusted as the designers and developers are working in tandem.
To support this lean approach, we favor splitting projects into batches. By breaking down the requirements of a particular project into manageable chunks, it allows designers and developers to work in parallel and encourages higher involvement from both teams.
While it’s important to avoid being too rigid when working on creative digital projects with clients, it’s also helpful to consider how to improve processes to optimize time and resources spent.
Something that we’ve covered in our insight about why designers should learn to code is using tools that integrate development components into design tools. There are some really great platforms that let designers share work with the development team more efficiently, such as Figma and InVision. Utilizing these allows the design team to define particular features to developers in a faster, more structured way.
Having a tool that both teams can openly collaborate on is really useful in the implementation process. But it is also helpful for both departments to learn a little about one another’s tools. Discuss the basic concepts and requirements – this will help to understand the thought process behind each decision.
At Mäd, we think in terms of human-centered design, which is generally a core principle embraced by design teams already. However, it may need to be further reinforced for developers.
Consider the human quality of empathy. In design, empathy surfaces when we consider that design is always about end-users and for end-users. The objective now is to translate this empathy to the development team, as they are responsible for optimizing so many crucial features of the user experience. Having the ability to empathize will hugely enhance the relationship between design and development, which will be noticeable both in the product that they’re working on, and in the office.
With empathy comes the need for open-mindedness. Designers and developers will inevitably see things differently – but all the more reason to be open to each other’s ideas. Often someone will miss a key feature or include an unnecessary element, and it’s important to share suggestions and ideas in constructive discussions.
It can be tricky to navigate the relationship between design and development, especially if your team is already accustomed to a particular way of doing things. Whether you are a designer, developer, or project leader, you may struggle with figuring out how to get things done in the proper order.
Our main piece of advice is – early and continuous communication.
Collaborating effectively will help ensure that by the time you need to ship the product, it is not only functional but also well-designed with regards to aesthetics and user experience. As you begin working on a project, make sure to provide enough clarity on the scope, timelines, and priorities, and separate the stages of work among all parties involved. This will help avoid miscommunication.
Regardless of your role, be open-minded and proactive. Realize that both designers and developers have a lot to teach each other, and so it is really worthwhile to share opinions and perspectives if you want to launch a stunning product.
In the next part of this series, we’ll explore design systems, diving into their structure in-depth to discover how they can enhance the collaborative process between design and development. You’ll find out why design systems are essential to creating a great product, and learn how they are built, organized, and managed.
