I’m posting this for two reasons:
- I know someone out there does this differently and will have Very Strong Opinions and I’d love to learn their methods.
- As a consultant, I've run into far worse scenarios than I’ve created for myself by using this structure. It works for me and seems to help teams I’ve advised to use it. So, here it goes.
Folder organization and naming
[my function] / [who I'm doing it for] / [what it is] / [file_name_and_version]
I tend to truncate files first by their audience and then by their function within the application. For example, If I were working on a to-do experience with users that are intended to be students, I might create a file path that looks something like this: Design > Students > To-Do > [your-awesome-design-file]. That’s not too shabby but the file name itself should probably have an articulated versioning system.
Here’s what I do: after writing the function or section name todo and followed by a separator (I use an underscore _), I’ll then add a number (1) and a letter (a). It’ll end up something like todo_1a, index_1a, or logo_1a.
As I work, I increment the numeric value when there is a significant enough change (such as a broadly impactful new functionality, an entirely different layout, a different take on the flow, etc). Usually 1a makes that bump to 2a when I’m returning to improve that part of the app in a later iteration.
I might bump 2a down a letter to 2b when I’ve made a potentially useful though much more nuanced change. This circumstance is usually when I’m unsure if the previous design might be best. If the team decides that the older version, 2a, is the right choice, I’ll put 2b in an archive folder that lives in the "what it is" section: Design > Students > To-Do > Archive > todo_2b.
This structure should allow us to work on different parts of an app without conflicts that are common of operating on a master file. It also allows us to spike on the same concepts by creating two versions and deprecating in whole (or in part) the work that isn’t going to be carried forward as the latest and greatest.
Documentation isn't any different (at least for me it isn't). When I go to create wireframes/broad strokes of that todo app (or any other preliminary work that could be considered documentation), I'd place name and place the file in Documentation > Students > To-Do > todo_wires_1a.
When the team is feeling good about an approach I'll just copy that same wireframe file into the Design folder equivalent to continue working on. Because I use Sketch for both earlier wireframes and final UI design, it makes sense to carry it over. Doing that encourages me to keep my layers and groups well organized.
Layers upon layers
The discipline of maintaining layer organization and naming is the easiest to lose. Some people hate running, others - with equal passion - hate naming and organizing layers.
From the inside-out, layers should be grouped by element, those elements then grouped into components where reasonable, and finally those groups of elements and components into a section. It's OK to have many groups within groups.
All of these should have obvious naming with the intent of creating a self-evident traversal experience for other designers and developers. If you had a masthead, for example, which embodied a heading, a subheading, and a CTA comprised of search and a search button, it could look like:
- Masthead (section)
- Heading text (layer)
- Subheading text (layer)
- CTA (component)
- Search field (search field component)
- Input field text (layer)
- Input field rectangle (layer)
- Search button (button component)
- Search button text (layer)
- Search button rectangle (layer)
- Search field (search field component)
If you're following this structure, life should become a bit easier in navigating your design files. You'll be able to both find the most up-to-date file and easily pick up where you or other designers left off.
In a future post, I'll go deeper on my ideas in sub-file versioning systems, sharing components across design files, and the struggles of maintaining a style-guide.