Mathworks Design Language

Form and Function in a Highly Technical World

MathWorks is the leading developer of mathematical computing software for engineers and scientists.
I lead the discovery, design and documentation of the Mathworks’ Design Language.

Year

2018/19

Role

Program owner and Design Lead

Team

UX Researcher, Product Designer, Project Manager

Problem Definition

Despite MATLAB and Simulink being their best known products and source of revenue, Mathworks product portfolio already exceeds 60+ applications. The organization has been developing software for 35 years supported by a very small community of designers. Obviously, design doesn’t scale, products and features have been produced organically, without clear design standards which brings challenges for both end-users and developers.

Goal

This project (still ongoing) is part of an attempt to bring customers a standard look and feel as well as a library of components available for building different applications.

Process

Research

It was early 2015 when I got very interested in improving the way we design products at Mathworks. I started reading about design systems and their value through Nathan Curtis’s Medium posts. I attended a conference and workshop with Nathan that helped me understand the process and complexity of developing a design system. I analyzed and benchmarked multiple design systems like IBM Carbon’s, Salesforce Lightning Design, Google Material Design to understand their patterns and what could we learn from them.

Who are we designing for is fundamental

Mathworks base users are scientists, engineers, educators, students and researchers that use our products everyday for long hours. We knew that we had to guide our design strategy based on a high level of clarity, precision, ease of use and comfort for these users.

Audit and Data Extraction

We started by trying to understanding the problem in the context of our organization. For that, we ran several audits. We captured a large sample of screenshots of our products, analyzed them, extracted and encoded different types of visual elements. We found a lot of variation due to either differences in underlying technology or to the fact that teams are used to working in silos designing their own solutions.

Documenting the Design Language

Data gathering was fundamental to understand the current state but also to acknowledge tradition, expectations and requirements. Instead of pursuing an absolute new language we recognized that the best route was to distill, simplify and normalize what already exists.

To document the Design Language we created a sketch library with color, typography, iconography and user interface components.

Color

We adopted a simplified palette of neutrals for surfaces and components while leveraging more vivid colors for elements, states and alerts. This aspect was fundamental to make sure we maintain the efficacy of color.

Typography

Because we were designing for desktop applications in different Operating Systems we could not recommend one unique type. We worked with development to create a font stack that could satisfy multiple OS.

Iconography

Mathworks products have different icon families that are used in different contexts. We categorized them and documented their various styles.

Components

We redesigned most of the user interface components in order to achieve consistency across workflows. We also identified patterns whose usage should be promoted across different tasks.

Applications

In order to test and iterate on the design language we decided to apply it to our Flagship products. This would guarantee that it could support the vast majority of our users.

Results

The documentation and availability of a Design Library dramatically improved our design process, consistency across teams and facilitated numerous conversations.

We are currently preparing the next phase of this project that is funding a dedicated team, with development support that can build, document, maintain and further develop the Design Language into a Design System.