What Developers Can Learn from Company Rebranding Announcements

By Tom Liao

Wednesday morning, I pulled out my phone to Slack my team and let them know I was running late. At first glance, Slack seemed to be missing. I scrolled through my app list twice before finally locating it.

When I got in to work, office chatter was about Slack’s new logo, with everybody asking, “Have you seen it?” and varying opinions. That’s when I realized why I had trouble finding the app.

Slack, of course, had posted about their new logo and explained the design decisions that went into making it.

Thoughts about Rebranding

I have no visual design background, not even in an amateur sense. The most I ever designed was my signature, and even that was suggested by my brother when I was in middle school.

I do, however, love to read company redesign/rebranding posts.

A company’s original designs are often a child of necessity. The company is new and simply needs a way to market itself. Eventually though, the company decides to do a redesign. Since redesigns are expensive and measuring the return on investment is difficult, they generally only happen when they reach a tipping point.

Sometimes, pain with the existing design becomes insufferable. New use cases constantly require changes, and calls for a redesign grow too loud to ignore. Other times, strong personalities at the company spend their attention and political capital to shape the public face of the company. In these situations, the new designs reflect where the personalities see the company’s place in the world.

In either case, rebranding highlights changes in the company since the existing designs were made.

What Rebranding Can Teach Us about Development

Many of the forces that impact a logo redesign do so in microcosm during development, and not just during rewrites.

The preliminary architecture is derived from an initial understanding of the product. Over time, this understanding or the product may change, and refactoring may be necessary. Personalities can also leak into the code via style, naming, and structure. Each technical lead brings their own opinions, and this can reshape much of the code.

By looking at the factors that influenced some famous redesigns, we can become more thoughtful developers.

Uber

Uber’s 2016 rebranding was Travis Kalanick’s vision for the future of his company. This event seemed driven, not by pain, but by personality. Uber was to be a mover of things, not just a transportation company. The brand needed to reflect that.

A development analogy might be a CTO deciding to switch the code base from Java to Go to show the company is polyglot. It’s an easy trap for the technology-enamored to fall into, and it teaches us, as developers, to ask what pain we are really trying to mitigate.

Interestingly, Uber’s 2018 rebranding under Dara Khosrowshahi was a repudiation of much of the 2016 approach. This “back-to-the-roots” rebrand may be most analogous to a new CTO who suggests bringing the old Java code up-to-date and releasing that.

Slack and American Express

Slack’s recent rebrand reminded me of American Express’s own rebrand last year with branding agency Pentagram. Both were driven by pain expressing the brand in various contexts.

This pain appears in development in fairly obvious ways. Websites need to look good in various form factors. Android and iOS apps needs to look similar, but behave natively.

Less obviously, this pain is felt when near-duplicate code is scattered throughout the codebase. The copies vary slightly by how they’re used, but they are intended to perform the same basic task. The design solution translates to Code Architecture 101: abstract the core functionality from the various contexts with an eye toward extensibility.

JetBrains

Although JetBrains did rebrand in 2015, their more recent 2018 icon redesign really caught my attention. A lot of the prior ideas I’ve mentioned are seen in this post as well, but the most unique part was driving the toolbar cleanup with usage statistics.

From a development perspective, this would be akin to having code path analytics and removing or otherwise reducing the prominence of outdated code. Doing so may even reveal changes in architecture that would have been impossible before.

In the Future

Companies are always redesigning various aspects of themselves. Hopefully, the next time one catches your eye, you’ll take a deeper look to see how the design solutions could apply to your development.