{"id":833,"date":"2025-12-08T20:36:40","date_gmt":"2025-12-08T20:36:40","guid":{"rendered":"https:\/\/amyoukey.com\/blog\/?p=833"},"modified":"2025-12-16T19:58:14","modified_gmt":"2025-12-16T19:58:14","slug":"when-to-use-existing-patterns-vs-when-to-create-new-ui","status":"publish","type":"post","link":"https:\/\/amyoukey.com\/blog\/when-to-use-existing-patterns-vs-when-to-create-new-ui\/","title":{"rendered":"When To Use Existing Patterns vs. When To Create New UI"},"content":{"rendered":"\n

Enterprise apps constantly pressure designers to \u201cjust make a new component\u201d when something doesn\u2019t fit perfectly. My job isn\u2019t to say yes to every request\u2014it\u2019s to maintain a system that stays coherent, predictable, and scalable as the product grows. This means knowing exactly when to reuse an existing pattern, when to slightly extend it, and when building something new is actually the right long-term move.<\/p>\n\n\n\n

I start with a simple rule: new UI is the last resort. Most enterprise bloat comes from building components that solve problems a system already solves somewhere else. I always look at the core building blocks first\u2014form fields, tables, cards, alerts, navigation structures, and layout primitives. If the request maps cleanly to an existing pattern with minimal adjustment, I reuse it. This keeps the UI consistent and protects dev teams from inheriting unnecessary maintenance.<\/p>\n\n\n\n

When a screen needs something that almost fits a component, I check whether an extension will break the logic that already exists. Extending a button variant or adding a table toolbar action is usually harmless. Extending something like a list-view structure with nonstandard spacing, nesting, or interaction patterns is usually a sign the real issue is upstream in the workflow. I fix the workflow before I touch the component library.<\/p>\n\n\n\n

There are rare times when inventing something new is the right call. It happens when a workflow introduces a distinctly different interaction model, or when the existing system simply doesn\u2019t support the complexity required. Even then, I design the new element so it follows the system\u2019s visual language\u2014tokens, spacing, states, motion, iconography\u2014so it doesn\u2019t feel bolted on. And if the new pattern works well, I document it thoroughly and add it to the library so other teams don\u2019t reinvent it later.<\/p>\n\n\n\n

This balance is core to hybrid UI + design-systems work. It protects the system, accelerates delivery, and keeps the product free of one-offs and slow, brittle UI. My approach strengthens design system cohesion, reduces redundant component creation, and speeds up delivery cycles across enterprise products. By distinguishing between when to reuse patterns and when to design new ones, I maintain scalable, predictable interfaces that minimize maintenance debt and improve system adoption across teams. Knowing when to reuse and when to create is one of the most important skills I bring to enterprise and legacy-modernization work.<\/p>\n\n\n\n

<\/p>\n\n\n\n

 <\/p>\n

\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722\u2722<\/p>\n

IC UI Designer \u2022 Design Systems Contributor \u2022 Figma Libraries, Telerik\/Kendo UI, Tokens, Component Libraries<\/p>\n\n\"Anne<\/a>\n\n\"Anne<\/a>\n\n\"Anne<\/a>\n","protected":false},"excerpt":{"rendered":"

Enterprise apps constantly pressure designers to \u201cjust make a new component\u201d when something doesn\u2019t fit perfectly. My job isn\u2019t to say yes to every request\u2014it\u2019s to maintain a system that stays coherent, predictable, and scalable as the product grows. This means knowing exactly when to reuse an existing pattern, when to slightly extend it, and […]<\/p>\n","protected":false},"author":1,"featured_media":834,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-833","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ui-design"],"_links":{"self":[{"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/posts\/833","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/comments?post=833"}],"version-history":[{"count":2,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/posts\/833\/revisions"}],"predecessor-version":[{"id":867,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/posts\/833\/revisions\/867"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/media\/834"}],"wp:attachment":[{"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/media?parent=833"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/categories?post=833"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/amyoukey.com\/blog\/wp-json\/wp\/v2\/tags?post=833"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}