Our UX designer uses Adobe XD to mock up and communicate look, layout and behavior to the dev team.
UX dev has everything in a single art board, which (AFAIK) is encapsulated in a single binary format .xd file on disk.
- Coders are assigned to specific screens/pages, and would like a more granular means of watching for changes to UI elements that they’re responsible for. With a single file, they all have to watch for any changes, then read commit comments to determine whether their components were affected. This is tedious and error-prone.
- Source code control systems lose a lot of their value when dealing with binary files; e.g. diffs, deltas, merging, etc.
- What happens when multiple UX designers want to collaborate on a single art board?
- By default, corporate IT policy often doesn’t allow intellectual property (like new product designs) to be stored on the cloud.
- Third-party solutions (e.g. Zeplin) also imply that our code/assets are no longer in a single place.
I saw at least one cloud-based collaboration tool used with XD (don’t recall whether it was part of Adobe CC ecosystem or from a 3rd-party), but it didn’t seem like it integrated with any source code control systems that a software organization might use.
Turns out that Adobe XD (.xd) files are just zip files (a zipped up copy of the project directory, I think), which is just what I’d expect to have checked into source control.
A quick-and-dirty short-term solution might be to have some automation on the source control server that triggers when the .xd file changes, unzips it to a staging dir, and then commits those files (keeping the commit comment) to what is essentially a read-only copy in source control.
Does anyone use XD in conjunction with a source code control system like Git, SVN, TFS, GitLab, Mercurial, etc?
I’ve been using git-xd-filter, which you can set up to run when files are staged for a commit (clean) and when files are checked out from a branch (smudge).
It takes care of automatically zipping/unzipping the .xd file for you and base64-encodes binary files embedded within. Obviously you won’t be able to diff images you’ve imported into the XD file, but the file that actually gets stored to the git repository will be a flat, diffable JSON file.
It’s not a perfect solution. I’ve found that small changes in an XD file can lead to massive differences in the stored JSON file, but it’s better than nothing.