file architecture

Ask the community
1

Please search for existing topics before posting! Press :mag: at the upper right to search.

Hello, my name is Ernest Son, I am a Lead UX Designer with Honeywell. We are in the process of creating/revamping processes and structure for our Design group, and had a few questions. Our objectives are not unlike many other design teams: enable easy search/findability, file stability and performance, system scalability, consistency within our team (which will benefit other groups as well). Our current file structure is detailed on the attached file “current file architecture”.

Some background on our current structure:

  • “Active Files” basically houses all files, so it is difficult to navigate and find files

  • Files typically include “all things product related” (mood boards, research docs, ideation sessions, feature work, etc.)

  • We have one file “Demo” which houses all the main screens from most of the Active Files. Its main purpose is

  1. to demonstrate the functionality of the entire “Warehouse Performance +” product suite in a (large) prototype.

  2. To house a copy of all components created from Active Files. The team did this because they found that components behaved more reliably when they resided in the same file as the prototype

  • “Deprecated Files” contains legacy work, work that never saw the light of day, etc.

  • Currently, pages within the files are not regulated, but we are moving toward standardizing that

We have two approaches (detailed visually in attachments “file arch-1" and “file arch-2") that we wanted your feedback on: which one is better suited to meet our objectives? Is there a better layout we haven’t considered?

Some background on “file arch-1":

  • Files will fall into 2 categories: “working” and “handoff” (see the attached images for greater detail)

  • The “Demo” model remains intact

  1. One large prototype that grabs screens from handoff files

  2. A copy of all components created from Active Files.

  • All working files would employ “demo & components-x" as a library(s)

Some background on “file arch-2":

  • Files will fall into 2 categories: “working” and “handoff” (see the attached images for greater detail)

  • The “demo” model is changed by

  1. Large prototype lives in “Demo”

  2. Components are moved, not copied, from working files when they are in complete-nearComplete form and pasted into “Components-{x}”

  • All working files would employ “Components-{x}" as a library

  • Demo would employ Components as a library

Any suggestions or feedback on these two approaches would be greatly appreciated!

2

Sorry, will upload images when able!

3

file arch-1
file arch-11483Ă—1138 93.3 KB

4

file arch-2
file arch-21485Ă—1144 93.3 KB

5

current file architecture
current file architecture1435Ă—963 62 KB

6

this is the current architecture

current file architecture
current file architecture1435Ă—963 62 KB

7

Sorry, need to remove figma screenshot of “Demo”

8

I’m on board with the concept of the demo file. At my company we also make large prototypes whose purpose is to be a reliable place to find and reference work that has actually made it into production. But these prototypes come with a lot of maintenance overhead and I think the trick is to minimize how much extra time it costs designers to maintain them. Looking at the big screenshot of your file, it seems really messy and confusing to me to have all of those elements living on one page.

I know you mentioned that the team found component performance to be more reliable when they live in the same file but I have not found that to be the case and prefer that most of my components live in external libraries if they need to be used across multiple files. This keeps the big prototypes as clean as possible. If you don’t want to use libraries to separate these things I might at least consider moving your components to a local components page in the demo file.

9

@Brian_Saunders thank you for responding! Do you have a preference between “file arch-1” and “file arch-2”?

10

If those are the only two options, I prefer arch-2 because it keeps the components on separate page in the file, if I’m reading the diagram correctly.

1 Like
11

Yes, you are reading it correctly. Is there an alternate option you would recommend?

12

I agree with @Brian_Saunders on preferring arch-2 based on your description and diagrams. Also based on personal experience! I support a design team that at one point had multiple library files in use. They had a “main library” (the “source of truth” many of us think of when we think about a Figma component library) but then auxiliary libraries that housed the same components but were more experimental, or the designs hadn’t been fully settled on yet. This created a lot of confusion, because while the auxiliary libraries had some unique components in them, we also wound up with components that looked and behaved identically between the two files. Figma’s assets panel search obscures the source of a component (folks on our team often use search). Having 1 library is ideal, or, if you must have multiple, my advice would be to be very explicit about the difference between them and how they should be used.

I’m curious about what specific dilemmas your team has run into with prototyping that has folks wanting to keep main components close to the demo file prototype?

13

Thank you Alice for contributing to the thread, we value your insight! The main complaint was that interactive components would not retain their interactive properties consistently.