Recently, we had the opportunity to collaborate on a responsive redesign for the global Lenovo team. Lenovo was recently ranked the #1 PC maker in the world—a company with annual revenue of US$33 billion and monstrous online sales numbers. And though they’re also ranked the #3 supplier of smart devices worldwide, their site has not been easily accessible across devices—until now.
Lenovo web properties are managed in a decentralized, global structure—not surprisingly, and probably not uncommonly, given the brand’s global nature and reach. Lenovo employs a Global Web Team based in their principle Morrisville, North Carolina, office. This team’s primary responsibilities are to provide a flexible web framework, which can be tailored to the needs of individual countries. The Global Web Team also supports this tailoring effort, as localized web teams across the globe build upon the global work.
The involved teams are numerous, the content fluidity is critical, and the necessity for flexibility, in every sense of the word, is paramount.
We began working with Lenovo via appendTo()—our partner on the project—in early 2013. Lenovo’s Global Web Team had, at that time, recently wrapped up a site redesign that they were rolling out to the localized web teams. The site redesign restructured some of the site’s information architecture and overhauled its visual look to a more current brand feel. However, the redesign was fixed-width, having been initiated before responsive web design had really picked up steam.
An Initial Engagement
Originally, Lenovo’s Global Web Team came with a relatively small scope and straightforward goal—prove out whether the new site UI design could be visually retrofitted into a responsive solution. Understandably, there was no guarantee of a project scope including a responsive redesign or rebuild if it couldn’t be shown as a viable option.
The resulting deliverables from this initial engagement were a set of priority guides (wireframe-like plans) and design comps. However, the most significant outcomes were:
A truly collaborative relationship with the client
Confidence in the feasibility of a responsive redesign
Foundational plans for further design and development
With this, Lenovo had the opportunity to determine next steps with some proof of concept in hand. Some directions the team considered:
Usability testing with semi-interactive mock-ups based on the static comps previously created (via something like InVision)
Usability testing with a working HTML/CSS/JS prototype
Building the real thing
We had reservations about the usefulness of a study involving static mock-ups. The content of the site is so dynamic. Animations and transitions for interactive elements are key for a helpful user experience. The static test felt like a lot of effort going into a throw-away deliverable to produce unknown results. Lenovo ruled Option 1 out upon weighing the pros and cons.
Options 2 and 3 had a common starting point—a working responsive prototype that would not be throw-away code. If built properly, the prototype could even be integrated directly into Lenovo’s content management systems and rolled out as production code. What’s more, we could gain ground on the prototype and delay the decision of when and how to test based on the project needs.
In a nutshell, we could begin building a prototype, then later choose to pause and more extensively test or to push ahead toward production. Based on our recommendation and corroborating business goals, this was the path Lenovo chose.
A Responsive Prototype
With this green light came a scope smaller than the entire website (thankfully). Lenovo carved out and prioritized the most widely trafficked pages for what came to be known as “Milestone 1.” These pages included product pages and the entire shopping workflow from browsing to cart to checkout.
In addition, we had a target country to work toward at the end of Milestone 1—Australia. At such a time as the prototype was deemed ready for integration into Lenovo’s content management systems for production, Australia would be the first country in the rollout. This allowed us to focus on a definite set of content, a smaller set of needs, and a particular internal team within Lenovo with which to work. All of this was enormously helpful to have determined in this early stage of the project, though our work would later be rolled back to provide a starting point for all localized Lenovo web teams.
The Build Process
We worked with a handful of members of Lenovo’s Global Web Team who had great autonomy and ability to make decisions, which was key. Our primary points of contact were the team leads over UX/design and the lead over their internal development team. Their involvement persisted throughout the project, which allowed for later handoffs to occur with few hiccups. In addition to that, we had involvement from front-line members of those teams as well as executives over these teams. Also key.
Our build process sought to tightly involve all these teams. While we thrive on improvisation and collaboration in the Sparkbox office, we needed to extend this to the development teams of appendTo() and Lenovo. Constant contact with the appendTo() team was natural as we had worked with them before and they’re used to flexibility and speed in the development process.
Involving the Lenovo development team was critical, as their team is ultimately responsible for the long-term maintenance of the code. Admittedly, this was a challenge at first. The Lenovo development team had to continue to support the current site in its various states, which limited availability at times. While they weren’t able to participate intimately in the prototype build, we were able to begin collaboration with them (and lay the groundwork for a smoother integration later) through the examination and discussion of their markup partials and CMS structure.
As mentioned before, the Lenovo family of sites required flexibility beyond fluid CSS. The sites required a system of modular web elements to integrate into multiple third-party CMSs, each with the ability to accommodate a variety of content, architectures, languages, and workflows. Our ability to write modular code was not simply an exercise; it was the only way to succeed.
We worked with the Lenovo team early on to understand, to the best of our ability, its requirements for modularity. But in the end, we didn’t so much map our modular elements to theirs as we did simply break our elements down as much as possible. We had some refactoring once it came time to integrate, but the changes were relatively simple compared to the prototype’s size.
(Check out our Lenovo Build Process writeup for more).
The Lenovo and appendTo() teams were excellent to work with. We’re excited to have been part of such a large organization embracing the ideals of responsive web design. And, like every project before it, we learned much in our work with Lenovo. We’re excited to put this new understanding to use!