Data Over Dogma

When working on design at scale one of the largest speedbumps you’re likely to encounter is a designer that feels like a design needs to change. Whether it’s something relatively small like the padding on a button or a heading’s font size, or something much larger like the layout of a card or the size of a drawer. More often than not, these designers are coming from a place of good intentions., they truly feel like their change would improve the overall experience for the user.

The Problem with Dogma

The problem with I Feel statements is that they are by nature, tied to an individual’s own sense of taste or understanding. This doesn’t make these feelings wrong, and there are times when I’ve agreed with the designer bringing up the change. The issue is that we’re not designing for our own understanding or our own taste; we are not our users.

This distinction becomes even more important when working on large-scale design work. Often a change request, even when well intentioned, does not take into account the sweeping effects that change may have across the entire product (or multiple products). If you want to make a localized change to a bit of UI or product interface that you or your team owns, I still think you should run a test and validate the idea, but by all means go for it. However, if you’re looking to make a change to a component or pattern that is used across multiple interfaces, teams, and user touchpoints, well the bar just got set much higher.

If we’re going to make a change to a system, we need to know how that system, and the systems it’s a part of are going to respond to that change. We need to move slower, test, validate, test again, and make absolutely sure that we’re not going to negatively impact one part of the business in order to support another. Big Medium put out an excellent article last year on the idea of Pace Layers that is worth a read if you’re not familiar.

The Solution in Data

As I mentioned in the previous section; the solution to the dogma problem is simple, collect and analyze data. Run small-to-medium scale experiments, see how users and other systems react to those changes, and implement what works. Sometimes this will mean rejecting proposals that may work for one part of a product or system but fail others, the previous example of changing a heading’s font-size for example; this is a change that likely can’t or won’t be done to solve a single product or interface’s issue, because that heading is used across multiple interfaces and user touchpoints.

Shifting Focus

While some designers who are especially production or visually focused may cry foul as this sort of design at scale is “stifling their creativity,” I believe this is a sign of a larger issue with the role of design at this level. By the time your design practice needs to be concerned with “enterprise-level” scale and consistency issues your designers should not be overly indexing on the visuals of an interface in the first place. If requesting your designer(s) run an experiment to validate a change request is ruffling feathers it’s likely that the change is not where they should be focusing their time or energy.

If the visual identity of a design is being changed the designer(s) working on it should be able to clearly and confidently show and explain why those changes are directly tied to an improvement in a user outcome. If we can’t answer “how does this help the user complete their job?” it’s likely not something that is providing direct value to the user or business, and should not be the focus of our time or attention.

Working with product teams, I see this as a fairly simple and powerful analysis tool for what the team is focused on, and whether or not those are the right things. Whether we’ve onboarded a new designer who does not have the background or understanding for why decisions were made, or if we’ve got a designer who is just extremely passionate about how they feel the product should look or work; if we look at every proposal through the lens of “How does this help the user,” we can ensure we’re remaining focused on what is truly important for them and the business.

Adam Sedwick

I work on Design systems and Advocate for Accessibility on the web.

Tennessee

Blogging

Design Systems

Design Tokens

Web Accessibility

Web Design

Web Development

Open Web Standards