“Be careful with the things you only get one of.” While this applies to a lot of things in life, it is especially true when it comes to how I try to execute my work here at Alley. As a scrum master and Agile Process Leader, my role is to serve a Scrum team by
Wait, design thinking in a project whose sole purpose is to preserve the look and feel of the current site while moving the content tools and infrastructure to a more modern platform? Absolutely! If we don’t understand the business goals of your platform change, we can’t help you execute properly. The process of design thinking starts with empathy — understanding the problem. Often, this is easy enough; we can look at your CMS, note that its design appears eerily reminiscent of Windows Explorer, and understand how that might not work super well for your producers.
One core challenge of projects that are meant to preserve the user experience while moving CMSes is that it is far too easy to build in the assumptions of the legacy CMS into WordPress. This is especially true if the goal of the project is to preserve the actual HTML and CSS that powers the frontend since this would require WordPress to mirror the output of the legacy CMS directly. Decoupled sites, where the frontend reads from a CMS via an API, tend to be easier to adapt to WordPress without substantial changes to the frontend itself.
Still, the challenge of building legacy CMS assumptions into WordPress persists. Content types and taxonomies drive UX elements like navigation, hierarchy, and site search. Legacy CMSes that represent content as a tree present special risks. The kinds of tools we use to deliver enterprise WordPress sites on WordPress VIP are flexible enough to replicate the functionality of nearly any CMS on the market. But rebuilding a legacy CMS in WordPress often means that you miss out on the powerful simplicity of WordPress itself. We largely throw out the assumptions of the legacy system and invent ways to solve problems that preserve the frontend experience while keeping the WordPress backend as lovable as it is out of the box.
As applied to a pure migration project that preserves the frontend IA and UX but changes the backend CMS, design thinking might look like this:
- Empathize: Understand the users and come to see why the current CMS might not be working for the organization despite the continued viability of the frontend of the site, the IA, UX, and designs.
- Define: Catalog the opportunities presented by a new system and the challenges extant in the legacy system. Here we want to pay special attention to areas of the user experience that are constrained by limitations in the backend CMS.
- Ideate: The classic design thinking paradigm calls for blue-sky thinking — really crazy ideas. Here, we question parts of the frontend that are tightly coupled to the legacy CMS, and parts of the backend that could be streamlined. When preserving the frontend directly in an enterprise migration, it’s tempting to coax WordPress into behaving more like the legacy CMS.
- Prototype: We quickly build a WordPress experience and manually add in some content so that editors can see and feel what it will be like to work in the new system.
- Test: We frequently return to our users for feedback to ensure that our solutions are meeting the needs we isolated in the definition stage.
- Implement: Once we’re satisfied with the direction of the CMS implementation, we finalize the data migration pathway and launch the site.
And if this challenge sounds familiar to you, give us a shout! We’d be happy to help.