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, Development, Accessibility

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 the organization.

Goal

This project is part of an attempt to providing Mathwork’s customers a standard product design language as well as enabling significant product development time and quality optimization.

Some high-level objectives:

  • Improve overall user experience by reducing aspects such as cognitive load and error.
  • Optimize design and development time
  • Increase product scalability and maintainability.
  • Reduce software hard drive footprint size.

My role

In 2018, after have pitched the advantages of a Design System in the context of our product development to leadership, I was made the owner of this initiative. I lead the strategy, activity coordination and communication aspects of the program as well as worked along with fellow designers, developers, researchers and accessibility specialists on the execution, approval, development and documentation of the design.

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 and consistency of color usage.

These colors were then documented as tokens in a variable system and made available in the development kit.

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.

We worked with a development team to implement an icon repository tool that allows developers to quickly insert icons into their projects, consequently reducing duplication of files.

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.

Working with a dedicated development team we helped create a fully accessibility compliant (AA+) UI component library available to product teams.

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, supported by a development component library, dramatically improved our design and development process. More consistency across teams, less time spending “reinventing wheels”, means more time focusing on value to our customers and to ultimately to the business.

 

Some numbers:

  • 60+% reduction UX and UI Design time.
  • Massive reduction on visual design variation (e.g. selection uses 3 colors when before we observed 32 different values)
  • 75% reduction of development time, especially In UI heavy, releasing dev. capacity to new features and quality improvement tasks.
  • Icon repository and shared UI components alone were responsible for an estimated 35% reduction in application hard drive footprint.