It’s pretty rare nowadays to see an electronic design project done entirely by a single person, or even by a small, centralized team. More commonly, a large team of designers and engineers stretched out across the globe are working together to meet this goal. And as you can guess, coordinating and collaborating on a single design this way is no small task. The question is: how do we cut through the practical barriers to allow true design collaboration?
To clarify, true collaboration means that designers are able to work together on a single project as they choose, whether this is in parallel across different areas of a design, or in tandem, comparing and merging as necessary to complete a single product. Of course, realizing true collaboration requires a set of capable tools, which are characterized by some notable features: visibility, differencing, and merging.
I Can See Clearly Now
Having insight into what other team members are doing gives a perspective of the design as a whole. This is especially true when several people are working in parallel, where visibility into each design area can help prevent them from stepping on each other’s toes.
Figure 1: Visibility into other designers’ work helps give perspective on the design as a whole.
The obvious analogy for this is a map showing the locations of various people. In place of a map however, we have a high-level view of the design project, and instead of each person’s location, we have the changes they’ve made to the design. The usefulness of this feature in a collaboration tool is entirely dependent on just how responsive it is. Do designers see others’ changes in real-time? Or only after committing their own changes to the final design?
Ebony and Ivory
It’s not enough just being able to see what everyone else is doing. Collaboration really doesn’t work unless the changes made by each designer are compared against one another, as well as previous iterations of the project, to see how the design has developed. For a collaboration tool, this boils down to differencing, that is, comparing design changes and recognizing their differences.
Figure 2: Seeing the differences between a design and its previous versions helps tracks how it has developed.
Differencing in collaboration should work much like it does in a Version Control System, with a bit of added intelligence. As mentioned, design collaboration can be separated by how designers interact with each other. This means prior to starting the project, they can be assigned a specific area to work on, either based on physical location or functional area. Splitting up a project in this way allows designers to work in parallel, and makes identifying differences a much more manageable task.
We Can Work It Out
The final step to true collaboration is merging the changes made by each designer into a single master copy. Assuming tasks have been split up beforehand, merging is then just a matter of conflict resolution in the overlapping areas.
Figure 3: Merging is the final step in collaboration, where differences are resolved and combined into a single design for everyone.
Conflict resolution during collaboration again works just like a Version Control System. If a designer runs into a conflict when committing changes, they can proceed by either abandoning the changes they’ve made, or overwriting others’ work with their own. How granular this conflict resolution is directly relates to how useful the collaboration tools are in general. For instance, being able to examine, add, or remove individual primitives from overlapping areas can greatly enhance the effectiveness of collaboration tools.
Design collaboration doesn’t have to stay in a single domain. Work can be done between people in different locations, across different pieces of software, or even in entirely different organizations!
- PCB - Most likely, this is the scenario that comes to mind first, but is largely the most limited view of collaboration. It’s pretty common to see a situation where multiple designers are working together to layout and route the same board at the same time.
- SCH/PCB - Also a common scenario, collaboration across the schematic and PCB is an essential part of the design flow. While this doesn’t traditionally fall under the term collaboration, it still represents multiple designers working on the same project. The difference is that this type of collaboration happens across two domains, even though they are usually part of the same software package.
- ECAD/MCAD - Taking the concept to higher level of abstraction, this type of collaboration also takes place across two domains, but is usually achieved by two different software packages. The key to this is how well those programs interface with each other.
- Supply Chain - The ultimate form of collaboration happens across several different domains, and across multiple organizations. Working with component suppliers, engineers, board designers, fabrication and assembly houses, as well as any other relevant parties requires effective and useful collaboration tools.
Whether or not it you’re aware of it, design collaboration is happening in one form or another during your product cycle. Having a useful collaboration toolset can help save some of that time-consuming back and forth dialog between designers. In the next part of this blog series, we’ll get into the gritty details about collaboration and some of the best practices for using it.
About the AuthorMore Content by Max Clemons