1

Where do you store your design assets?

15 days ago from , UI/UX Designer

The team I'm on currently uses Figma for our main workflow which works very well and I'm not here to convince you why it's better than it's competitors. Regardless of what prototyping tool you use, the problem still stands: "Where do you store your design assets?".

I'm not talking about components and styles, I'm talking about images, icons, logos, etc. We currently have these on Google Drive but I feel like there should be a better way...

I know we can certainly put our assets all in one document on Figma but I like how on Drive, it's their own thing (like a photo album).

6 comments

  • Crispo Colombo, 5 days ago

    Using Google Drive from your desktop makes things a whole lot easier. The native folder structure is much easier to navigate than GDrive. IME, most companies I've worked with use GSuite so figuring out a good system there can make life much easier over the long-run as opposed to using a one-off system that another company may not likely be using.

    2 points
  • 李 大毛李 大毛, 4 days ago

    iCloud Drive.

    Upload and compress the finished project file to the archive storage regularly.

    1 point
  • Marc EdwardsMarc Edwards, 5 days ago

    For me, design assets always get stored on the Git repos with the code. This gives full history of everything, developers get notified of changes, changes are broadcast to Twist/Slack, and new assets are automatically part of new builds. It also means developers don’t need to spend time adding new assets — that’s handled for them, so they can focus on more challenging tasks.

    In a cases where I don’t have access to the main project Git repository, I’ll set up a repository just for the design.

    It may also be worth noting that I think the final assets shouldn’t have much value. If possible, asset building should be automated, so you can always recreate files if needed.

    1 point
    • , 2 days ago

      How well does this process work for the designers? Say I need to mockup some screens that are using existing icons and images, so does this mean I have to go to the repo, find where it's located, download the asset onto my local machine, and then import it to my design document? It seems like a lot of steps

      0 points
      • Marc EdwardsMarc Edwards, 2 days ago

        I think I need to start by clearly defining how I like to structure things, and what I mean by each name.

        Assets = The final deliverable parts. These are often PNGs, SVGs and other files that are included in the production product. I believe these should always be easy to regenerate in a way that’s as automated as possible.

        Slice sheets/export docs = The documents that generate assets are typically set up so they only contain elements that need to be exported as production assets. Changes needed for production are always made here. I typically put these documents on a repo as well (that’s not essential though). These documents are kept as neat as possible and maintained as the product evolves.

        Design system library = The components used to make prototypes and mockups. If things are well set up, these can also be used in the slice sheets/export docs, so everything stays in sync.

        Mockups and prototypes = These documents are treated as exploratory and temporary. They are not for production, and I don’t mind if old mockups and prototypes get left behind and are out of sync with production.

        Say I need to mockup some screens that are using existing icons and images, so does this mean I have to go to the repo, find where it's located, download the asset onto my local machine, and then import it to my design document?

        Mockups would be created using components from the design system library. There’s no situation where I’d be reimporting production assets.

        0 points
        • , 5 hours ago

          Ok, that definitely adds clarity. We're currently doing that for mockups where components are coming from the Design System. But it's also good to know where you're coming from in the sense that you don't treat mockups as the source of truth (always up to date).

          0 points