A Massive Undertaking to Rebuild Equinix Web and Mobile Experiences from the Ground, Up.
Defining a design language that assigns humanistic attributes to our products.
Problem:
Our team was missing a central reference point for design patterns and interaction guidelines across the global Equinix portal landscape. In 2016, as we began to develop new products, and improve the existing ones, we lacked comprehensive design foundations, from color and typography guidelines to well-documented interaction models and everything in between.
Solution:
We created a living Style Guide. After conducting exhaustive design studies across a wide breadth of disciplines and applications, our team documented best practices and other outcomes of our research, identifying the underlying design principles for all our work. As we continue to innovate, we document new patterns and rules, and iterate on existing ones.
My Role:
A senior role on a central team, called the Customer Experience Team…
Managing intake of design solutions from all design studies, and groom for consistent interaction patterns.
Grooming, clarifying, and expanding on all annotations produced by team at large.
Spearheading several design studies of my own.
Outcome:
Our team worked to establish a shareable resource – a living design library with repeatable patterns and controls – that developers and other designers could draw from and contribute to. This library has grown and has gone through many iterations, and is used every day to build every part of our portal.
Approach: Exhaustive Research; Thorough Design Studies
Research: Existing Solutions – Mood Boarding!
Equinix wasn’t interested in reinventing the wheel. For one thing, it is a B2B SaaS and PaaS company with a strong bottom line and growing customer base and revenue. With an aging platform and a bare-bones portal, what Equinix needed was to leverage the best, most creative, and most effective solutions to a wide range of problems comprising ecommerce UX, admin tasks, detailed technical monitoring and customization, and so much more.
Enter Mood Boards. We relied on Mood Boards heavily during the initial phases of design discovery to see what resonated with our internal customers (customer admins, product managers, developers), and to see which directions they might be interested in exploring. This was a crucial step as it allowed us to make early decisions about what styles, interactions and approaches not to pursue.
Dive In to Exploring: Design Studies
The purpose of the design study is to explore possible design solutions to both known and unknown challenges in a given feature or facet of a digital product. For example, in order for a given website to serve its most basic purpose, a transactional ordering component may need to be developed; a design study might be undertaken to experiment with various solutions, both existing and untested ones, to probe the efficacy of using a tried-and-true Cart-Checkout system to facilitate those transactions, as opposed to a more customized solution. Multiple proposals are tested and prototyped to probe which solution provides the most coverage of user needs, business requirements, and technical limitations.
We carried out 30+ design studies on every conceivable facet of Equinix’s online business and compiled and published our findings. We shared them with stakeholders in the organization all the way up to the CEO, and validated countless proposals with product managers and customer admins across every channel of the business.
Build & Present: Prototyping!
It’s difficult to overstate the value of showing someone how an idea or proposal works. The more clarity one—as a designer—can provide in making a case for an idea, the more quickly it gets validated—or challenged!
A click-through prototype can be very useful for sharing a proposal and I do this all the time, usually using Invision.
I use either After Effects or Principle as well for showcasing interaction ideas, which are often much harder to describe.
Presenting our ideas this way
pays dividends in the long run: Both product folks and developers grasp the intent of a design idea much more readily and we save on time – and on energy – by an order of magnitude greater than having even highly detailed annotations on their own.
Build, Publish, Iterate, Repeat
Building and Sharing the Component Library
In close collaboration with the rest of the Equinix design team, and through deliberate consultation with our developers, we began to produce the living library of our Equinix Design Guidelines. This would be our North Star, setting the tone for every piece of the Equinix Portal development puzzle, and forming a steel-clad repository and source of truth for our design decisions.
Unlike the design studies, these are real-life components that are, as we speak, being developed for the Equinix Customer Portal. Hence, there was a need for stellar deign execution, and also for air-tight documentation. Below are some of the critical pieces I helped produce.
Navigation and Control Components
Before handing off work to developers, we needed to think through every aspect of our designs to ensure there were no surprises, and to cut down on costly confusion and back-and-forth communication between teams.
We partnered closely with developers to discover what frameworks they were intending to use, so that we could design around their technical restraints, and also so we could leverage existing components and patterns in the framework they chose (React and Ant Design).
Extreme levels of detail were needed in producing our design library.
Diligent and thorough annotations / specifications were also paramount.
