Things you could be doing instead of designing & building that card component for the umpteenth time

  • Making that card pattern more accessible
  • Making that card pattern more responsive
  • Making that card pattern more performant
  • Making that card pattern more agnostic so it can handle different content patterns
  • Making that card pattern more resilient to extreme content edge cases
  • Creating a thoughtful variation of that card pattern that addresses an important use case
  • Implementing microinteractions around the pattern
  • Defining animation behaviors for the card pattern
  • Making that card pattern work more elegantly across different input types (keyboard, touch, etc)
  • Tweaking design details around the card pattern’s various states (hover, focus, disabled, etc)
  • Writing usage guidelines to help implementors understand when they should reach for that card pattern and what they should be considering when they implement it
  • Writing documentation around the process by which teams actually implement the card pattern in their codebases
  • Writing documentation around the process by which bug fixes, enhancements, and changes to the card pattern should be made
  • Linking up industry resources and best practices around the card pattern in the style guide
  • Localizing that card pattern for other languages
  • Thoroughly commenting the card pattern’s markup, CSS, and JS code
  • Ensuring the card pattern’s code aligns with your frontend guidelines
  • Documenting the code’s anatomy in the style guide, defining which aspects are required, optional, and so on
  • Reviewing analytics for screens that utilize the card pattern to gain insights on how it could be improved
  • Testing the card pattern with real users
  • Inventorying your organization’s ecosystem to look for similar-but-not-quite-the-same instances of other card patterns
  • Inventorying your product to find other areas that could be enhanced by using the card pattern
  • Extracting the design properties used in the card pattern into abstracted design tokens
  • Creating a technology-agnostic version of the card pattern
  • Porting the card pattern into another technology that’s in use at the organization (i.e. creating a React-specific version of the card pattern)
  • Writing unit tests for the card pattern
  • Designing a proof of concept for an updated card pattern that also provides rationale for why it would be an improvement over the current pattern
  • Learning how to wield the frontend code used to create that card pattern so that you can present your concept as a working prototype rather than as a static comp
  • Focusing on the thousands of more important and pressing tasks that don’t involve the card pattern

When designers freak out about how design systems, patterns, components, atomic design, etc are “putting them out of work” or “killing creativity”, they’re really saying “I really enjoy (re)creating these patterns/screens/pages ad infinitum, I’m good at it, and I’d like to keep doing that thank you very much.” I get it; there’s a certain rush of filling up a blank Sketch artboard or a blank HTML file. But once those patterns exist there’s no need to keep repeating that process again and again.

The reality is there are thousands of other worthwhile tasks designers and developers could be tackling to make more successful products. So once a solution for a pattern is established, codify it, then iterate, improve, and enhance it over time. Solve the boring stuff that that the team can be freed up to tackle more meaningful tasks.