How to keep track of all your design project edits
Tags: design, uiweekly
Published: 2021-12-14 12:47:04

Designing an app is not easy. And sometimes we focus so much on what we’re creating, that design files become very disorganized. After all, you're getting the job done, right? Why would we need to put time into getting the design organized? Well, as you might have discovered (the hard way), having a messy design file makes it very difficult to find things when you really need them.
&nbsp;


We’ve previously talked about [being organized in Figma](https://updivision.com/blog/post/design-workflows-getting-your-s-t-together-in-figma), and the best workflows in terms of design file tidiness. In this article, we wanted to address a more specific issue in UI/UX design: what happens when you make several different versions to a design, whilst keeping every single screen? Chaos. But that’s what we’re trying to avoid.
&nbsp;


A lot of times, we make minor changes to a design that need to be applied to multiple screens. The original screens are kept in case the clients change their minds and want to go back to the original design. But oftentimes we end up having 5 slightly different versions of the same screens.
&nbsp;


So how do we navigate that?
&nbsp;


###It’s all in the naming.###

The easiest and most basic thing to do is giving each page iteration a different name. It can be as simple as a “V1, V2” -type thing. This, of course, means keeping all the different iterations of your screens in separate pages. And make sure everything in one iteration’s page actually belongs there - if it’s centered around a specific design modification, make sure all the screens in said page have that element.
&nbsp;


Now, just adding a V1 or V2 to a page name might not be enough. So here comes another suggestion: add big headlines in your design document to explain what sets that page apart from others. It doesn’t have to be complicated: just a paragraph of text should be enough. Think of it as a post-it you’re putting next to a specific item as a reminder - “These pages contain a different color scheme than Ver. 2” or “An alternate version of the header across all screens”.
&nbsp;


This doesn’t only apply to document page names. It’s also good practice to name your screens accordingly: if you used a different color scheme on some screens, put them next to the original ones (for comparison sake) and include “alternate colors” (or anything that makes sense to you) in the screen’s title. Don’t leave the same title on multiple screens, and definitely don’t just call them “v2”, “v3” and so on - it’s too unspecific and is bound to create confusion when you return to these screens.
&nbsp;

###Keep a separate page for non-final designs###
Let’s first discuss a more basic part of UI/UX design file organization: what’s the best way to sort screens into design document pages? We’ve come to discover that it’s best to keep all the screens in one page - that is, unless the app you’re designing has A LOT of screens (in which case it’s best to divide them by subject or menu items). And when you do this, you get a lot of room to sort “non-final” designs, or “trial runs”, if you may. 
&nbsp;


What we do is keep a separate page called ‘Archive’ for old screens that won’t go into the final app but which we decided to keep, just in case. We also create another page called “Trial and error”, where we keep screens that we’re making new versions of - and which aren’t final or “good enough” to go into the main design file page. By doing this, there’s no confusion about which screens can head into development and which ones are just ideas.
&nbsp;


A simple way to divide these pages visually is by using emojis: a checkmark for approved screens and a hand holding a pen for pages in progress can go a long way.
&nbsp;



![Example of using emojis to divide pages in a design](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g8spt7z7qi64noiqnh6m.png)
*Photo source: [Smashing Magazine](https://www.smashingmagazine.com/2019/08/figma-tips-kick-start-design-workflow/)*
&nbsp;


In short, make sure you divide screens that are final or approved from screens that are still in progress. And we know what you’re thinking - the word “final” has lost its meaning in design. Nothing is ever final. But what we mean is: separate the designs that have been approved from the ones that haven’t.
&nbsp;


###It’s about the small things###
You don’t have to switch up your entire design framework in order to keep better track of project edits. There are a couple of small things you can do to avoid getting lost in your own design files:
* Don’t make a different file for each design iteration. Keep everything under the same file, but on separate pages.
* When making a new version of an existing screen, or editing a thing or two about it, don’t do it on the same one frame - make copies of said screen and don’t be shy to make as many as you need. You never know when you might want to return to the old version.
* When screens have been approved, make sure to keep pages like “Archive” or “Trial and error” at the bottom of the list. This way, when your development team or your client uses the design document, they won’t accidentally go on those pages.
* When making an alternate version of multiple screens, keep them on a separate page and add an emoji to the title. Our suggestion is to use number emojis - 1️⃣ for the original version and 2️⃣ for the additional one. 
* Use colored circle emojis (examples: 🔴 🟠 🟡 🟢 🔵) in page titles to show what state they’re in. For instance, if the screens in a given page are still in progress but close to being done, use the yellow circle emoji. Since these colors are pretty suggestive on their own, it’ll be easy for your clients as well - they (hopefully) won’t get lost in your design document.


There you have it - now you know how to keep better track of design project edits. Naming, dividing screens, instructions from you to you: they’re small things, but they go a long way. After all, making a well organized design file is not only helpful to you, but also to your clients and development team.