Dealing with Site Headers in Design Systems

98% of the time I’m all about component reuse. Make components content and context agnostic, make them flexible and versatile, and make them extensible. That’s all great stuff.

The big exception for me is a site header (or global header, or masthead, or whatever you want to call it). This is a component that gets used exactly once on the page, has a big responsibility for branding & way-finding, and is often the most complex component in the entire system. Navigation collapses to a nested accordion on small screens, then transforms into a huge mega menu on large screens. There’s a bunch of sticky/fixed positioning stuff going on. There’s drawer navigations sliding out. There’s breakpoints galore to manage the complexity of the elements that live inside it.

I’m working with a few teams that are struggling with how to handle the header with respect to reuse. “How do we abstract these patterns for maximum reuse?” My answer is: don’t. It’s really the one place where I tend to advise teams to cut the cord and make the site header its own beast. I’ve lived through those pains, and realized it just isn’t worth the effort.

It’s true that the components that live within the header, such as the logo, primary navigation, search form, and utility navigation (log in, account, and so forth), may end up getting reused elsewhere. And that’s good. Design and build for that if possible. But don’t twist yourself into pretzels trying to reuse this super visible, super complicated, super specific component.