Driving trust in our applications by creating a consistent, intuitive visual system.

RedShelf is an application suite to help institutions in higher ed procure, distribute and manage digital textbooks for their courses. It has seven applications that have been built in separate silos without any clear design direction. My first priority when I got to RedShelf was to address these issues with a design system.

We defined a number of sub-goals for the project, but at the core of it, the main question we asked ourselves was, "How do users know what to do next?"

Team

I led design along with a contract designer and our in-house and contract engineers.

Timeline

Initially designed in summer 2020; implementation was still in progress at the time of my departure in spring 2021.

Before

As a result of siloed application development without clear design direction, the system felt outdated, slow, and inconsistent, and users weren’t entirely clear how to manage various data types in various statuses all at once.

Process

Before you start rebuilding pieces, you need to know what you've got. We did an extensive audit of the various pieces and patterns existing in the current RedShelf applications (Dialog example, below). Concurrently, we did an audit of a few existing design systems of various types and sizes.

Knowing that we needed to iterate into an updated system due to resourcing constraints, we started with updating color and type.

Using Google's Material Design as a reference, we built a color palette with a bright blue as a base, and using an HSL scale to create lightness and saturation variants for a unified palette. We applied the same theory to create a set of bright (but not overwhelming) status colors.

After that, we used Roboto to build a type palette; we used Owen Gregory's concept of a musical type scale to create a minor third scale for a strong hierarchy that would work well on desktop and mobile.

Components

We created an ad hoc group called the Front End Design Squad, composed of myself, our freelance designer, six front-end engineers, and our Director of Accessibility to prioritize components and build a process. Largely the process involves a designer saying, "I need something in my project that does...this kind of thing." Then I can take that concept - whether it's a sketch, a process map, or a low-res wireframe - and shape it from a visual and functional perspective, thinking about how it might work in different contexts, viewports, with dynamic content, etc, again keeping in mind that one of the goals is to reuse as many components as possible. It goes back through the initial designers, product managers, accessibility, engineers, and finally to a cross-team Experience Review board before being built in RSUI (RedShelf UI) Talon.

How...AND Why: Patterns and Processes

Because I was the only designer (of three total) who works across multiple teams, I needed to bring a 30,000-foot view to the project and provide contexts that other designers or engineers might not be aware of. As we made decisions about how something should look and work, we kept flexibility and reusability, as well as accessibility, at the forefront.

Additionally, because our applications often have many of the same basic processes, it was very important for design and engineering to collaborate to define the core functionality of these processes. For example, how does bulk uploading work, beyond just the interface: how do we validate data, how do users access it and edit it, and how do we communicate those flows to our users? All of this work goes far beyond the pixel level, but is extremely important to creating a cohesive system.

Additionally, often our product and engineering teams hadn't had the bandwidth to completely tear down and rebuild an experience from the ground up. In these instances (as you'll see below), we did visual facelifts on components while also beginning to design experience improvements to prioritize in future sprints.

The updated system - Talon - demonstrates a faster and poppier feel, while more effectively drawing the eye towards action and status items.

Progress

The design system continued to evolve as we learned lessons while putting pages and templates together and as we dragged multiple code bases and concepts into visual consistency. Since we were building a clear and concise system, it was easy to roll out minor changes on the fly as we gained more knowledge about how to create the clearest experience for our users.

Additionally, we used Figma's component features and AutoLayout functionality to save tons of design time by building in ways to reduce "pixel management" tasks such as resizing containers, as scopes and requirements inevitably change.

Thanks for reading!