- Atomic design systems are a lot of work but the payback is exponential as the design system grows
- Designing for scalability is challenging. Without having a crystal ball, you can only see so far.
- Accept that even if you test all the edge case scenarios, someone will come up with a new one that you didn’t plan for after the component goes live.
- It’s important that the team agrees on the naming of things so we speak the same language
- File hygiene is important. Tidiness and the naming conventions for symbols / layers / artboards / files / projects is important to the process even though it is tedious. The switch from Sketch to Figma has given my hours back just for the auto labeling of layers to match auto layouts.
- Bad design requirements often become bad user experience. As much as I love a UX challenge, eliminate unreasonable scope in the creative brief. (I am thinking of the stakeholder who in complete seriousness responded “infinity” when asked “how much copy should I plan for?” in regards to a hero banner caption)
- Make sure the intended purpose of each component is clear. Otherwise you will end up with design bloat and too many similar components.
- Make sure that artboards have enough width outside of the embedded breakpoint to communicate which components stay within the page well, which extend past, and which go full-browser width.
- Bake accessibility into the product
- Edge case and usage testing should start in wireframes
- Create consistency wherever possible. Everything will go more smoothly.
- Product design is an iterative process, best to work agile
Recent Comments