Jeremy Elder, Staff Product Designer at GitLab


What’s your relationship to visual design?

I’ve been designing as a career since 1999. Before that I loosely studied fine art. I’m self-taught and started with Adobe Photoshop 5. Not long after, I started using more Adobe apps, like Illustrator and GoLive.

I was a graphic designer → interactive/digital designer → XD designer → product designer. For about 13 years I also did freelance, alongside my day job, where I took on projects that provided experience I wasn’t getting otherwise.

I’ve always focused on the UI and have done plenty of frontend to implement it. I love working with CSS and semantic HTML. Today I focus primarily on the design system for GitLab, but also the UI and all things accessibility and product illustration.

So my relationship with visual design is wrapped up in a lot of things to say the least. In my day-to-day, getting deep in complex design is my favorite thing to do.

Do you think your earlier experience in graphic design influences your software design approach?

Absolutely. Mostly as it relates to the relationship of elements and guiding the user with hierarchy and visual cues, but I’m sure there are many subconscious ways too.

What role did visual design play in your freelance work?

Visual design holistically played a role in my freelance work. I worked on a lot of logo/brand projects, packaging, and web design.

How did your freelance clients seem to think about visual design?

I think most of the clients knew that good design would provide value, but ultimately I think they thought of it as the expression of the passion that fueled their business to begin with. It was something that made their vision tangible. A way to package (for lack of better term) their product or value to their prospects or market.

When you design reusable interface elements for the GitLab design system, how does that affect visual design choices?

Great question. Recently, we updated the design of our family of dropdown components after some development efforts to make the components more accessible and semantically correct. Think listbox with options, and disclosure widget. The development updates provided us the runway to push the design further away from the previous Bootstrap-inspired design. This isn’t a knock on Bootstrap, but we want something that feels more proprietary while working in the construct of GitLab’s condensed UI.

One of our values at GitLab is iteration and we break work into smaller pieces, like working on one component at a time. This meant that there’s a type of elasticity between any visual update and the components that remain unchanged. Push a design update too far and the visual relationships have too much tension and can break. Likewise, not pushing a design update far enough means that there’s not enough tension to spring other components forward.

So today it might be an update to the dropdown family, and tomorrow it might be buttons, but there’s always this leapfrogging or ripple effect happening to drive the design forward because visual design choices aren’t made in isolation.

Are there any uncommon or controversial visual design principles that you stick to at Gitlab?

There are a few that might be more category specific and could be controversial depending on what perspective you’re coming from. Three that come to mind are design considerations for a condensed UI, desktop-first, and convention vs. consistency. Before joining GitLab my experience was more around e-commerce and marketing sites, so the transition to application design took a bit. There are still some things about it that I try to shift for various reasons, but I think there’s always going to be some healthy tension. The constraints and opportunities that come from it create a pretty interesting space to work in.

One other thing comes to mind that is more generally tied to the industry than my specific role, and that’s design and semantic parity. This is mostly encountered when trying to design with accessibility in mind and ensuring that all users would perceive parts of the UI in the same way. For example, maybe something looks like a form element, but semantically it’s something else. In that case it just requires some deeper work, exploration, and research to clear any controversial fog. This isn’t something I’ve fully solved for, and continue to learn and work through it.

Why do you think that applications tend to be plainer than, for example, marketing websites?

In marketing, I think visual design is used to guide a decision, while in applications it’s to isolate a decision. A marketing site might have one task in a flow, while an application can have many. With marketing, I might see it once, so a more liberal use of color or embellishment drives a more memorable or emotional guidance. In an application I (potentially) use it more frequently and am more task driven than emotionally driven, so something more plain is less fatiguing over time.

Another thing that plays a role is that a marketing landing page is often designed as a single comp with a unified story, but in application design the focus is often on one partial in a template that gets assembled at runtime. Simplicity here helps ensure a baseline of conformity while emphasizing known tasks over exploratory ones.

There’s always opportunity for crossover though, like highlighting a new feature or promoting an upgrade path.

It’s nuanced, but I feel there’s always a tipping point where in application design the visual attributes can begin to detract from the experience more than add to it.

I think the most successful tools do both well, and understand the complimentary relationship. Take Linear’s recent popularity in the design community for example. The app is considerably plainer than the marketing site, but there’s a common undercurrent and degree of polish that is present in both and when you use the application there’s a degree of subliminal appreciation for how the design is simplified.

At GitLab, something I’ve been working towards is “sophisticated simplicity.” We started with naive simplicity and currently have a high degree of sophisticated complexity, but the next level is sophisticated simplicity which aims to strike the right balance between structure, discovery, and capability in our visual design. You can read more about that here.

Is there anything else you’d like to say that I haven’t covered?

The first is trends. I think trends are important to help inform usability and mindset patterns and direction more than aesthetics. For example, I believe recent macOS and iPadOS updates directionally point towards touch interaction and easier context switching more than they point towards the importance of “glassmorphism” or a soft and friendly vibe with larger border radius. Similarly, the return of skeuomorphism can hint at the need for more affordance. Focusing on the lighting, material effect, noise, or composition without understanding why they’re being used just leads to chasing aesthetics, but not usability.

The second is accessibility. It plays a massive role in my visual design. Like a sculpture might start with a wire armature to build on, I try to layer design on correct semantics. Doing so also ties what can be subjective to something more objective. A button element is immutable, but the design can either reinforce or detract from the usability. So much more to say here, but I’ll leave it at that for now.