Lately at work I’ve been helping out with some light Scotts work. The Scotts Miracle-Gro Company is a huge client, with several different microsites and campaigns. The recent redesign of scotts.com (disclaimer: I only performed perfunctory copy changes for the redesign) reminded me of much of the work I did at LexisNexis: scotts.com was the equivalent of a flagship product like lexis.com or nexis.com. The challenge from a branding perspective is how to maintain a consistent look and feel for subsidiaries, while still allowing them to maintain their own identity. I’ve donned both a developer’s and a business analyst’s hat in looking at these projects, and it’s a good exercise to identify the opportunities for consistency as well as for variation. This was truly where we were going with our common UX initiatives at LexisNexis before I left. How do we enhance the usability of all the sites by introducing consistent functionality, while ensuring each site meets its specific target audience’s needs?
Before I left LexisNexis, I was the UX representative on the architectural advisory board and I sat on the brand spirit (branding and identity) committee. There, we had three flagships and literally hundreds of projects a year that had some level of association with at least one of the three. It was absolutely imperative that design or development decisions were not made in isolation. The User Experience department I was a part of held design reviews every week to push for consistent user interaction and design across our products.
Coming to Resource late last June, I was thrown into agency life. It’s quite different dealing with different clients, who are paying for the development of their own unique brand and user experience. While there are always benefits in developing code libraries of common components that can be reused, the nature of the challenges we dealt with in a huge beast of an application like lexis or nexis simply don’t compare.
It’s actually fun for me to look at Scotts and see those patterns and consistent elements. In developing one microsite, I’m stretching my “build for the future” muscles again in anticipating potential future additions. It’s interesting how I can build this into my work both as a developer (coding in anticipation of reuse), and as a business analyst (explicitly identifying requirements that have shown up elsewhere or may be of significance moving forward). At LexisNexis, some of these considerations (as well as others) would be made by the system architect or a portfolio manager, but those are roles we don’t particularly have at Resource, due to the nature of most of our client engagements.
It’s interesting that considerations into the creation of a robust, usable, expandable site occur throughout the design and development process. I guess I consider it the difference between creating a web site, or developing the architecture for a web application. You can make a web site to achieve a specific purpose, or you can create a framework that supports as-yet-unknown functionality.
This is why I once felt I wanted to get into architecture: rather than putting square pegs in square holes, I want to consider the fact that I may not know what pegs I’ll be given down the road. I hope that in the movement to BA or IA, I will also be able to anticipate these unknowns and ensure we continue to deliver engaging user experiences that are also robust, usable and extensible.