image courtesy of https://www.flickr.com/photos/svelasco/

Monocle: From Pattern Library to Prototype

A look at our team’s process for designing product UIs from a pattern library.

Previously I wrote about Cyclops, an open source UX/UI pattern library for CenturyLink Cloud. In a distributed organization of 350+ people and 30+ product teams, there are zero designers assigned to any product team. Each product team consists of a product owner, product analyst, and n number of developers and engineers. So knowing what Cyclops patterns are appropriate for which context, isn’t something that product teams inherently have the capability for.

We’ve done a great deal of internal evangelizing of Cyclops, so there is an awareness within the org that it’s a valuable resource. However, without a designer on each team, a knowledge and capability gap exists that we have to account for as teams develop their product user interface. Finding a method to scale our design team’s expertise and value — enable product teams to create simple, beautiful, and consistent customer experiences — became our mission.

When we created Cyclops, we knew it was a major step in scaling our team’s impact on the business, but our work was far from done. We couldn’t simply direct each product team that needed a UI to Cyclops and let them figure it out on their own. The outcome of such a process wouldn’t satisfy anyone, especially our customers.

To demonstrate this point internally, I’ve been explaining this gap using this cheesy metaphor:

Patterns are like groceries in a shopping bag; the bag contains everything needed to create a meal, but transforming those ingredients into a fabulous dinner rests with the skill of the chefs in the kitchen. We are the chefs, and we invited you over for dinner.

We came up with a “sibling” project to Cyclops named Monocle. It’s also the name for our collaboration process with product teams to design and develop high-fidelity prototypes. The process looks like this:

1. Product owner, product analyst, and engineering manager have a defined product vision, mission, and identified a minimum viable product feature set.
2. We have a “kickoff” meeting(s) to learn as much as we can about the product, including target market, competitors, and logistical stuff like rough timeline and team capabilities. The goal of the kickoff is knowledge cross-pollination and to come away with a list of key flows that will take the form of stubbed out HTML pages.
3. The first iteration of stubbed out pages is essentially a fully navigable site architecture, with the source hosted on Github. A standard website shell (header, footer, body background color) is applied to each page through the use of handlebars templating and partials. In the body of each page, a list of features and content is displayed as a list, in priority order. Each commit to our master branch automatically deploys the static site to an AppFog instance via Travis. This is presented to the product team and iterated upon.
4. Once there’s general agreement upon the site architecture and content items, we’ll start to apply Cyclops patterns, increasing the fidelity of the views. As we work through page designs, and find that there isn’t an existing pattern that works for certain types of content, we’ll mock them up as part of the product team’s “Monocle” prototype. If we believe other teams may benefit from the new pattern, we’ll add it to Cyclops as a new pattern. When we feel there are enough new patterns to warrant a new version, we’ll push out a new release of Cyclops and notify teams via Slack. The outcome is a high-fidelity prototype that typically demonstrates create, read, update, delete (crud) operations and four states: first-run, empty, error, populated. We’ll share the staged site and with the product team via Screenhero for feedback and iteration.
5. Once there’s agreement that the Monocle prototype has reached a point where the product team is comfortable moving forward to “wire up” the UI, we publish a final version to a github repo and a staging site. Then product teams use the actual HTML files of the prototype as reference for development in their individual development environment.
6. All teams have access to other team’s Monocle prototypes to use as reference. This has the benefit of helping us maintain consistency across teams.
7. Lastly, as product teams begin to develop their user interfaces, we have regular check-ins to offer guidance and answer. questions that come up.

So far this has been a really effective process for both product teams and my team. We’ve had as many three or four monocle projects happening at the same time. Seeing “real” content in a high-fidelity prototype almost always forces teams to consider how to design their systems to effectively “power” the desired user experience. Any gaps in thinking or inaccurate assumptions are quickly revealed through our discussions of the user experience and interface.