If you’re ever working with other designers, it is so important that you keep your file clean and organized. You should be doing this anyway for your own sanity, but especially if you’re working with other designers.

Our experienced sales staff will assist you with every detail of your project, our design & production team will review your designs ideas, and or production team will see your project through to the final delivery.

Yep, product managers usually have a great eye for design. They’ve seen it all…just like you. Brainstorm with them! Let them hold the whiteboard markers! Solve problems with them. They’re great at what they do, and they will help you. They want to help you.

Be respectful to developers. If their deadline is Friday, don’t wait until Wednesday to get them the design. You’d be surprised how little a dev needs to get started on database or architecture work, so the sooner you can get them a blockframe or wireframe, the better.

When you’re not unveiling a grand new design, it’s usually the PM who communicates back and forth with the client. Be thorough in your designs and make sure you satisfy all requirements. Don’t make your PM look bad; it’s your fault if you miss something, not theirs. But the client doesn’t know better. Make them look good, and they’ll return the favor!

You don’t have to know how to code it yourself, but it’s beneficial to have a basic understanding of the technology stack your team is using to build the product. If user data is dispersed across several tables in the database, instantaneous-app-wide-global-search probably isn’t in the cards. Design thoughtfully, and be willing to compromise with development. Given infinite time, just about every developer would love to do it exactly to spec. Unfortunately, time isn’t infinite.

Developers are great at following the design spec…even to a fault! If your spec shows 14px margins and they’re supposed to be 16px, guess how much spacing the developer will put in the code? And guess whose fault it is when it’s wrong? I’ll give you a hint: Yours. To combat these small inconsistencies, I’ll have a meeting with the dev team before implementation begins to have a high-level discussion around design philosophy.

Spacing: Everything is designed on an 8px spacing grid. Paddings and margins should always be multiples of eight: 8, 16, 24, 32, 40, 48, …<br /> Typography: Everything is designed using a text style from my Sketch stylesheet. These make for great CSS classes. Grey text is never hex grey — it’s always the base black with a transparency applied so it’s tinted toward the color it’s over.

Typography: Everything is designed using a text style from my Sketch stylesheet. These make for great CSS classes. Grey text is never hex grey — it’s always the base black with a transparency applied so it’s tinted toward the color it’s over.

Icons: Every icon comes from the same set. “Here’s an icon font. Use this instead of pulling individual SVGs from Zeplin or InVision.”<br /> Spacing: Everything is designed on an 8px spacing grid. Paddings and margins should always be multiples of eight: 8, 16, 24, 32, 40, 48, …

No one likes sifting through “Group 65” and finding your misspelled text or detached symbols. Do yourself and everyone else a favor and keep a clean kitchen. You’ll love yourself, and your team will, too. Everyone wins.

What good is your design if no one ever uses it? Designing for practice is all well and good, but at some point, you’re gonna want to get the thing built. That’s what pays the bills, right?