Designing the HMX design system

Harvard Medical School — HMX online learning: course platform, interactives, Partner Dashboard, and marketing site

Role: Lead UI Designer, Product Development
Built by: Development team, from my prototypes and against the system.
Tools: Sketch, HTML/CSS/JS, edX, WordPress

Where it started

HMX is Harvard Medical School’s online learning, delivered through edX. I was hired in part to improve the UX of the course platform, right as traffic was increasing because of the pandemic.

Most of that work was new designs for components that already existed, with a particular focus on accessibility. The edX components came with the platform, so we couldn’t replace them, only improve them, and some of them, drag and drop included, weren’t accessible at all.

Courses also ran on interactives, which were the gamified sections of course content and the more UI-heavy pieces like a step-by-step player and a hotspot viewer. Those were one-off builds, and each one drew on the same components as the rest of the platform.

Two other surfaces came with the job. One was a marketing site on WordPress, where I standardized the components. The other was a Partner Dashboard the developers had built, a tool course owners, corporate managers and professors could log into to track how their groups were doing in courses, where I made UX and UI improvements. None of these shared anything with each other, so I proposed the design system.

What I built

Namespace	Symbols	Purpose
LMS	207	Course player, assessments, navigation, outline
Global	167	Shared foundation — footers, accordions, pagination, inputs
Partner dashboard	80	Admin cards, reports, callouts
WordPress	76	Marketing pages, staff cards, site navigation

Accessibility in the system

Part of the focus was getting accessibility decided while we were designing, rather than catching it later in review.

Focus, hover, disabled and active states were all built as components, which mattered because a developer normally picks a focus ring during implementation and it ends up different depending on who wrote it. Designing the states meant keyboard users got the same thing mouse users got, everywhere, by default.

Each brand color got nine shades and nine tints in 10% steps, used by some components and by some content. The point was to get those increments made as variables, instead of designers and developers each picking whatever looked good.

One of three color ramps. Every step is rated against black, white, 50% black and the base color, and left blank where the pairing isn't accessible.

A specification sheet for interaction states. Six copies of the same navigation bar show default, hover, focus, active when the page is in use, the active pseudo-class, and hover combined with focus — each labelled, several annotated with their behaviour: the hover line animates into place from left to right over 0.5 seconds; the focus line starts as a point and draws a circle around the focused object. Below, a button is specified in default, hover, active, focus, long-copy, minimum-width and disabled states. — A few of the components in the system.

The system in use

Two of the four surfaces, built from the same library.

The partner agreements list rendered as cards — each agreement a white panel listing type, status, term, start, end, seats and a partner contact link, with an expand control at its right edge. — Partner Dashboard. The same agreements as a table and as cards, switched by the control at top right. The table shows more at once, the cards work on a narrow screen. Same search, same buttons, same pagination under both.

The same agreements rendered as a table, with a dark blue header row of sortable columns and one row expanded into a full-width detail panel holding a description, an ID, a View Invoice button and a nested table of the courses that agreement covers. — Partner Dashboard. The same agreements as a table and as cards, switched by the control at top right. The table shows more at once, the cards work on a narrow screen. Same search, same buttons, same pagination under both.

A course assessment with nothing answered: a scenario table whose rows each end in a “select an option” dropdown, a diagram question with a tray of shapes to place, and a free-text question, each with its own Submit. — The LMS. One assessment component untouched, graded, and out of attempts. The mark, the wording and the score all change together, so nothing depends on color alone. In the last one Submit is greyed out and Show Answer has taken over as the main button.

Checkbox and radio questions after submission. Each chosen answer carries a green check or a red cross at the end of its row, the question heading carries the same mark, and an explanation has opened beneath. — The LMS. One assessment component untouched, graded, and out of attempts. The mark, the wording and the score all change together, so nothing depends on color alone. In the last one Submit is greyed out and Show Answer has taken over as the main button.

Rebuilding drag and drop

edX shipped a drag-and-drop component that courses used heavily, for sorting items, labelling diagrams and matching text to parts of an image, but it couldn’t be done on a keyboard or with a screen reader, and on a phone the drag fought with scrolling. I rebuilt it to be accessible and prototyped it in working HTML, CSS and JavaScript for the development team to build, and that version is what courses used afterward.

The genetics pedigree is that same component, just heavily skinned for the genealogy content. Each family member is a <select> and the connector lines are CSS, so it reflows on a small screen instead of needing pinch and zoom. Because every node is an input rather than a picture, it can also be graded — pick a status for each person, submit, and each one comes back right or wrong.

The rebuilt drag and drop, skinned as a genetics pedigree. Every family member is a native select, the connector lines are CSS, and submitting marks each node right or wrong.

Outcome

Courses adopted the components, and the system became what the team checked against whenever the LMS moved to a new version of edX, so upgrades didn’t undo design and accessibility decisions on the way through.

The Partner Dashboard was eventually dropped, and the HMX team was later reorganized into a product development group, which is where my title came from.