E2open Design System

I'll bet this looks familiar.

June 8 – March 31, 2017 (10 months)


I wrote more about this project here: Designing a Design System.

So you want a design system, huh?

E2open develops a collection of software products that manage the supply chain of worldwide companies including L’Oreal, Boeing, and Kimberly-Clark. It was with a sober sense of responsibility that we were retained to create a consistent visual and interaction system of patterns for their portfolio of products, which — as is often the case in large organizations — were acquired over many years, maintained by different teams, and (clearly) shared no common UI that would identify all the software as belonging to the same suite of solutions.

OK, fine. So what components do we need?

Some of these were obvious. There were basic UI components that all applications need. From the product demos we received, there were also some more complicated components that were clearly in heavy usage.

Still, we needed to identify, discuss, and prioritize a set of components so that we could maintain a realistic scope of work. To do this, we selected a handful of the most critical software and printed out many of their key screens. Dividing up into teams, we blended the projekt202 and E2open teams to begin cutting out and physically grouping the same & similar components. We had some starter categories to begin, and any team could create new groupings as they were discovered. This exercise not only revealed some component needs that we did not know about, but it also helped E2open get a bracing view of the disparity between their software designs.

Cutting out & grouping UI components
Cutting out & grouping UI components.

With a more comprehensive view of the components already in use, the team went through a prioritization exercise to determine which components we would design and the general order in which we would do them. This exercise seeded the backlog, and team estimation of each component’s effort gave us a pretty good idea of where the budget would cut off.

A worksheet for prioritizing UI components
We developed a worksheet to help identify all necessary components and vote up the most important ones.

Stylistic exploration

I wrote about this process here. In summary, there was pressure to briskly arrive at a visual style so that component design could begin in earnest, and developers could start getting engaged. We reached a stylistic concuss pretty quickly, but spent more time getting the color palette right — it had to compliment the brand colors, but not in too literal a way, since branding comes and goes. We wanted the design system to weather those changes well.

Style explorations
Some of the stylistic options developed for the design system. As you can see, the variations were... subtle. :)

22 sprints!

Though some of my 10 months on this project was spent helping to apply the design system to key screens, most of my time was spent on the design system and its accompanying documentation site. This was my first proper design system, and it was a doozy. In particular, all of the products the system would be applied to used extremely robust tables, which we called Grids (to match the client’s vernacular). Grids were very much like Excel spreadsheets in that they could often be edited at the cell level. There were a lot of cell state styles to figure out, not to mention perennial table design problems, like: “If this table is paginated, and there’s a ‘Select All’ button, does that select all rows across all pages, or just the current page?” Fun stuff.

Grid design
The Grid component was so complicated that I created a "playground" artboard every sprint to make sure that new developments would play well with previous decisions.
Grid editor design
The Grid had an Editor to allow it to be customized by each user.

© Jared Christensen

Subscribe to this website if you're still down with RSS


Bringing back that OG Livejournal vibe