Redesign with Drupal 8 In Mind

Drupal 8


website redesign

July 25
blog author

Appno Blogger

Appnovation Coop

More often than not with nearly all the projects I work on with Appnovation, we're tasked with some degree of updating, redesigning and modernizing an existing web presence, whether that be a dated website, re-modelling a business web presence inline with its evolution or de-commissioning legacy data services. The target result being something new and shiny. Additionally, now with the dawn of Drupal 8, a lot more requests to port a site into the latest and greatest version of Drupal. 

Ideally this task would be made simple if the existing system had been built in a sensible way, with a clear separation between content and presentation, a clear information architecture approach and a minimal dependency tree. However, our ideals are never really reality, and in my experience redesigns are never really just redesigns in the sense that replacement or a few updates to the CSS would suffice.

When our clients look to consider a significant change to their website, like a re-branding refresh, it's often a good opportunity to think about their audience, their needs, goals and motivations and reflect that back into their content and business models, as to improve not just the look of a site but also its positive impact in whatever measure they wish to monitor that. Additionally considering some of the benefits that the new version of Drupal brings that in previous versions may have been difficult to implement or never even considered.

With that in mind, a ‘redesign’ is now much more than just updating or replacing a theme and moving to Drupal 8. With a little luck (and for those non-Appnovation readers) your sales team would have correctly guided the client into not thinking that it’s just re-skinning and will be a quick and simple job, with a fast turnaround. When inheriting a new redesign, it's always wise to take a look under the hood as early as possible. This will ensure that the potential nasty mess of hideous hacks and unstable code that needs a new paint job will be highlighted in the client / vendor relationship and the changing of its look and feel will be better understood, scoped and sized accordingly and all parties to be crystal clear on the challenges ahead.

To add a little context and the rationale behind a desire to redesign, these are then often coupled to a wider project of re-branding and are often associated with timescales and expensive deadlines that are often always agreed upon way in advance of any real knowledge of scale being made aware. Now herald this warning, for whatever reason, it’s not unlikely that redesign projects will find themselves behind schedule, or over budget, usually because a schedule has been guessed at, and agreed by non-technical sources way before the size and scope of the redesign is truly known. In this situation the perceived agile wisdom is that time and resources are fixed, so you know the scope will need to be changed or reduced. But what about an MVP (minimal viable product) for a redesign? When you’ve got an existing product, how much of it do you need to rework before you put the new design live?

Let's consider a few variables in this, and thinking purely in a Drupal orientated site: How dated is the existing site? Is it responsive? What’s the underlying platform version powering it? Are the contrib modules available for direct replacement and so on? These are all on top of the foreseen desired redesign scope; this assumes the proper UX and visual design streams have both spun up and are in advanced stages.

With interesting challenges, a lot of varying answers and paths present themselves; you could begin with sizing the impact of each request and weighting them in priority of importance to focus on the most important tasks first. For that to be an efficient delivery, you'll need to have a good feel for the current burn down, or in the instance of a nearly formed team, what is their potential burn down (this is where having experienced resources in place helps as they can usually provide a pretty accurate estimate range). That way you can be confident on what can be achieved in a given time frame.

Next up comes more brave decisions, once the fantasy deadline is a known distant dream. What features can be shelved or possibly dropped? What value are new features bringing that are worth keeping? In other words, a redesign can (and should) be an opportunity for a business to look at their content strategy and consider rationalising the site. If you’ve got a section on your site that isn’t adding any value, or isn’t getting any traffic, and the development team will need to spend time making it work in the new design, perhaps that’s a candidate for the chop?

Let's also consider prioritizing elements that will get us most of the way to ultimate completion. This fits back into the Agile development principles where each sprint should deliver a shippable, potentially production ready features. I would interpret this to mean that we should make sure that the site as a whole doesn’t look broken, and then we can layer on the bells and whistles afterwards, similar to the progressive enhancement approach when dealing with legacy browsers. If you're not sure whether you’ll have time to get everything done, don’t spend an excessive amount of time perfecting one section of the site to the detriment of basic layout and styling that will make the whole site look reasonably good.

Try starting with a simple set of styles that cover all common HTML elements, then put these into known common components (like forms / navigations etc.). This will become the foundation to build the rest of the site up on and will ensure all the components that build a page up are presentable and uniform. You can even test these components against their real contexts of use, user motivations and persona driven user flows driven out by the UX sessions. Also, by this point, the content audit should have highlighted the depth, variety and count of different layouts the site will be accommodating, so you should be able to validate whether these look good and are presentable enough to ship.

There is another option though, its slightly more radical but can work for the largest of redesign projects. Ask do you have to deliver all the changes at once? Can you (and should you) do a partial go-live with a redesign? (Depending on how significant the redesign change is, the attitudes to these changes and capability of continuous delivery within your development team and of course the client’s appetite.) Also consider the technology stack involved; it may make sense to deliver changes incrementally. In other words, put the new sections of the site live as they’re ready, and keep serving the more important old bits from the existing soon to be legacy system. This could deliver some inconsistency in the look and feel and a little bit of awkwardness in user flows through the site, but if there are obvious stand alone sections of the site that users have been identified to stay exclusively within, then chances are they won't even be hitting the new stuff anyway.

To close… We shouldn’t fall into the trap of thinking of redesigns as big-bang events that sit outside the day-to-day running of a site. Along with software upgrades, redesigns should be considered as part of a business’ long-term strategy, and they should be just one part of a plan to keep making improvements through continuous delivery.