Rebranding Is Hard

A few years ago my company went through a rebranding excercise and got themselves a shiny new logo.

All of the new applications that my team was working on were fully reworked with this logo and all of the associated branding in mind. However, no time was allocated to rebrand my project, our oldest and most used application, partly due to other development demands, and partly due to the fact that as our oldest application, it barely met the previous branding standards (as it predated them as well) and really didn’t mesh visually with anything else in the company anyway.

We were asked to simply drop the new logo in and be done with it. The colours of the new logo had been slightly tweaked, but were mostly the same, so while marketing wasn’t happy about it, it didn’t look too different than before.

Rebranding is always much more work than people at first think.

I mentioned that it would probably be more effort than simply swapping the logo in one file, but was mostly ignored. We used page templates, so they thought it would be a one line change in a couple of template files at most.

Of course, our application was 10 years old, had had a dozen or two different people touch it over the years, had vastly increased from its original scope, and had had some partial rewrites and refactorings that touched some areas, but not others.

With this sort of history, it’s only a very very well-controlled project that won’t have redundancy, inconistancy, and odd bypasses and cludges. There are going to be pages that were added later in an application’s life that didn’t or couldn’t use the original templates for whatever reason and have the logo on them somewhere. Or even better you may find a page rendered entirely from a servlet making no use of templates whatsoever with its own logo instance. An application may have bloated to include several logo files hidden around in different folders, with odd rarely visited pages linking to one here or there. There may also be other things that you wouldn’t even think of, like an external link to another barely maintained site filled with old static content. To make things worse, everyone’s used to seeing the old logo and so remaining instances of it don’t neccessarily jump out at you on random pages where it should no longer be.

These are all good examples of why it’s good to keep your code clean. But, as I said, most applications that have been through a lot of years and a lot of change will be like this.

It wasn’t much actual work for us catching all of these logo instances, but it c ertainly wasn’t something that happened overnight.

For a couple of months during the developement, it seemed that every time we passed something to QA, or gave a demo to the bussiness folk, someone would notice an old logo sitting somewhere on the page. In fact, some of the instances weren’t caught until after the release rolled out.

For instance there was a help documents page where a modified logo had been used as a list bullet point. It wasn’t the general logo file, and it was small and innocent on the page, so it wasn’t noticed. And then there were the help documents themselves, which were pdfs and loaded with uses of the logo. No one had thought about those (and they weren’t in the actual code so searches missed them). The same thing happened with some crystal report template files.

Eventually the process was done, but it was not the 5 minute job that had been given to us, and think how much more it would have been had we ACTUALLY rebranded things rather than dropping a new logo over an old.

So, why do I bring this up? Hockey season has started, an I am in a fantasy hockey league. Yahoo has done a makeover in the off-season and things look a little newer.

They’ve updated the fantasy site and also the logo to their new one.

Rebranded Yahoo Fantasy Hockey logo

However, the other night I opened up the live StatTracker and…

Old Yahoo Fantasy Hockey logo where it shouldn't be

Bam! Old logo.

Rebranding is always much more work than people at first think.