There’s no such thing as a website “re-skin”
Here at Blenderbox, we design and build experiences on the web. (In other words, we make websites).
Our projects run the gamut, sometimes we work on small marketing websites, sometimes we undertake wholesale web redesign projects for rather large institutions. The latter often take 8–9 months and start with research, strategy, stakeholder interviews and a deep dive into content and site architecture.
We love our website and our back-end. We’re just looking for a quick “design refresh”
Occasionally, we’ll get a project that isn’t necessarily looking for either a small new design or a large wholesale redesign. They’re looking for a “face-lift” or “re-skin” of their existing website. This happens for a variety of reasons. It could be for budget reasons, or it could be because the client feels the existing architecture and underlying CMS are fine — they just feel that the design is a little dated and perhaps it’s not yet responsive on mobile. So they’re just looking for a quick “design refresh”
When this happens, we price the project accordingly. We assure our developers that we don’t need to throw out the baby with the bathwater, we’ll preserve the existing CMS (made by someone else), and just toil in the presentation layer (HTML/CSS).
WELL, DON’T BELIEVE THE HYPE!
What starts out as an earnest attempt to salvage an existing back-end and simply re-skin the front-end, will more often than not backfire, and here’s how and why.
From the client’s perspective, the only thing that is changing is the visual design. Perhaps the logo is being swapped out, the fonts are changing, some minor tweaks to the layout are requested. They claim that the way the site works, the CMS, the site-map, and the content organization are all fine.
Meanwhile, from the developer’s perspective, the project is starting with the assumption that they must reuse (not refactor) any existing code. What’s more, they are being asked to reuse code that someone else has written.
The moment this happens, the developer has added “technical debt” to the project
Invariably, the client will request some minor design tweaks that will actually affect logic. Not in a severe way, but enough so that the design change can’t be affected exclusively at the template or view level. So now the developer has to delve into some of the back-end logic that they didn’t write.
This is all fine, the designer mocks up the change, and the developer attempts to implement the change without refactoring any of the underlying code. The moment this happens, the developer has added “technical debt” to the project.
Incurring technical debt is bad. On a normal project, the impetus would be to refactor as you go, however, on this project the developer has been told, there’s very little budget — we can’t reinvent the wheel, it’s only a “re-skin” so the project moves forward incurring technical debt.
Before you know it, what started out as a modicum of technical debt has built up into a mountain of technical debt
The project continues and minor tweaks continue at the suggestion of both our designers and the client. “Wouldn’t it be better if it worked this way?” “Doesn’t it make more sense if this links to that?” All good suggestions, but minor departures from the way the legacy site worked.
Before you know it, what started out as a modicum of technical debt has built up into a mountain of technical debt and an emergency internal stand-up meeting is called to debate the pros and cons of refactoring entire sections of the site. The development team quickly realizes that it would have taken less time to build certain sections from scratch than it ultimately took to tweak the existing functionality in order to realize the new design.
an emergency internal stand-up meeting is called to debate the pros and cons of refactoring…
In reality, it may be possible to implement a true “re-skin,” however, it would be imperative that both the client and agency understand its limitations. A true “re-skin” would mean that all changes are limited strictly to those that could be achieved with CSS/HTML and the swapping out of images that are the exact same dimensions and proportions to what is already there. Nothing about the grid/columns, number of promo boxes/widgets etc. can change. This is particularly challenging because it’s much more difficult for a client to understand what you can and can’t change at the presentation level than it is for the experts at an agency.
Conclusion
In sixteen years, we have yet to witness a design “re-skin” that didn’t require some degree of code refactoring. The conclusion is that we must start with the assumption that code refactoring will be necessary (especially if we didn’t write the original code), and estimate accordingly. Despite all good intentions, a “re-skin” is never as simple as making minor tweaks exclusively at the thematic or template level.
There will be underlying code changes! There’s no such thing as a website “re-skin!”
