You’re the first design hire at a high-growth startup. You're eager to get started and sink your teeth into the work. It's just you, so you can focus on designing at hyper-growth speed, right? Not quite.
Even as a designer of one, you are responsible for establishing an internal design process so your team will remain efficient as you grow.
I get it. As creatives, we use our right brain far more than our left. It feels almost unnatural to prioritize or have a plan — especially in a high-growth startup moving at the speed of light. It’s essential to keep in mind that you are not the only person who will engage with your files. Think of this almost as another communication channel between teams.
Okay, let's talk about what I mean by this. Below are three foundational — yet straightforward — areas to focus on when developing an internal design process to make the highest impact.
File and Folder structure
"group-476.png"
"promo-101021-final.sketch"
"untitled-17.fig"
We've all been there and used names like these before.
As designers, we solve problems, right? So, think of your file and folder structure as a user problem. How might another designer find a file in the shortest amount of time possible?
Sure, we have global search, but that only works as intended when we name things rationally. Here are a few tips on how to set up a flexible folder structure and file naming convention:
Folders
We always want to make sure we're working from the current version of any file. So, the best way to approach this is by storing the most recent working file in the root of the particular project folder. Then, use the start date as the prefix to the folder name. Here's an example folder structure:
Feature Name
- YYYY-MM-DD - Brief description of the project
- _archive
- Assets
- PNGs
_archive: Move older working files into this folder, so the most current working version lives in the root of the project folder.
Assets: Save any supporting assets such as icons, photos, or system models supporting this project.
PNGs: If you need to export static images for sharing, put them here.
A real-world example of this might look like this:
Payment Portal (logged in)
- 2020-05-12 - Payment Plans
- _archive
- Assets
- PNGs
- *[current working file]*
This structure provides a well-organized view of all the pieces of a project and gives any newcomer quick, scannable access to what they’re looking for.
Files
Okay, we've helped a team member easily find the right place; now it's about giving them the confidence they can find the right file.
Chances are the engineering team at your new company uses a tool to track their work (E.g., Jira, Trello, Github). Whatever they use, find out if they have a numbering system for their stories. Why? Because if they do, you can connect your working filename to the story that will relate to the development story.
For example, *PAY-1036 - Payment Plan Flow*.
If they don't yet, that's okay. I'd suggest starting the filename with the start date again (e.g., *2020-05-12 - Payment Plan Flow*).
When you put all of this together, it creates a hierarchy that I've found to be immensely practical across various team sizes and organizations:
- Brand & Marketing
- DES-194 - Website Redesign
- Product
- Payment Portal
- PAY-1036 - Payment Plan Flow
- _archive
- Assets
- PNGs
- PAY-1049 - Onetime Payments
- PAY-1052 - Plaid Integration
Artboards and Assets
No, this does not mean you have to take yourself out of the flow of designing to rename a layer or group. This means being intentional with naming your screens (aka, artboards, aka frames) and assets you intend to export. This may seem ticky-tacky, but it's a critical component when you're exporting assets, especially for your engineering team.
The structure for this is similar to how we think about folders and filenames. Artboards (Sketch) or Frames (Figma) within a file like "PAY-1036 - Payment Plan Flow" should begin with a shorthand prefix of its project. For example, *payPlans-*.
Once you have a prefix figured, stick with it. Then, after the prefix, include a shortened descriptor of the part of the flow that is being designed. Here’s an example:
"payPlans-setup-add-card."
Having a consistent naming convention for your artboards is a straightforward way to help designers unfamiliar with the product understand what they're looking at.
Assets
Your engineers will hold you up on a pedestal if you supply them with assets named in a way that they know what it is without opening it. #designHero
One of the biggest things you can do here is stick with a prefix convention that defines the element you're delivering to them. Here are a few examples:
- Buttons: btn-
- Images: img-
- Icons: ico-
- Logos: id-
Once you've set your prefix pattern, what should follow is a short descriptor of the asset. Let's pretend you have two different-sized buttons in your product. Here's how that could look:
- btn-lrg-primary-fill
- btn-lrg-secondary-outline
- btn-sml-primary-fill
- btn-sml-secondary-outline
Or a series of icons could look like this:
- ico-16px-search
- ico-16px-edit
- ico-32px-search
- ico-32px-edit
Using a consistent naming convention like this makes it incredibly easy to find a specific asset and assign it in code. And it'll also help you organize your Sketch/Figma library file.
Clean Libraries
Nice segue to our last item, eh?
At a high-growth startup, it's unlikely that you have seen progress on a design library. So how should you start? I'll rely on one of my favorite phrases: be intentional.
The best way to think about starting a library is to treat adding styles and components to it as if you'll never edit them again. Unlikely, I know, but hear me out.
Early on, there's so much exploration and ideation that if you start adding and creating components right away, your library will become bloated, and your engineering team will get confused — or worse, build unnecessary elements — about what you actually intend to build.
Allow yourself time to explore different typestyles, buttons, input fields — all the most commonly reused components. Once you realize you've begun to reuse certain elements, you can be confident that it's time to start your library.
I recommend you start with type. Copy all your typestyles into a new document and discern how many you have and how different they are. Begin to consolidate styles that are similar and then commit to this list. Ask yourself, do you really need a 24px header and a 26px header? Probably not.
Now, move to colors. Pluck out all the different HEX codes into your document, then do the same thing you did with type—consolidate. Define your palette, and then stick to it.
Similar to every other area we covered in this post, but intentional with your naming conventions. Establish patterns that would make sense to other designers as they onboard.
Here's a sample Sketch file you can download and use as a starting point for your library:
Click here to download the Sketch file
Be mindful of your hierarchy, how you name files, assets, and components. Most important of all – commit and be consistent. It doesn't mean you can't change down the road, but committing and then iterating as the product matures in these early stages is more valuable.
