top of page

Melody design system

(with a lens on accessibility)

melody-sticker_edited.png

Overview

 

In June 2017, the Zappos UX team started work on Melody, the Zappos design system, which was created to mirror the makeup of Brad Frost's, Atomic Design.

  • Notes = Elements

  • Chords = Groups of elements

  • Measures = Components

  • Keys = Templates

  • Scores = Pages

​

I'd always been a systems thinker, curious about how things affect one another, how they interact with each other, always advocating for the holistic approach. So it was not a surprise to any of my teammates when I jumped on the opportunity to lead this initiative. 

Phase 1 

​

Our process

  • Omnichannel audit of the colors, elements, components, typography, interactions, etc.

    • We delegated areas of the experience across the team, collected, printed, and posted our findings on giant artboards to take it all in​.

  • Research

    • Competitive analysis ​

      • We dispersed and aggregated mood boards of colors, components, and typography from various sites and apps we drew inspiration from​.

    • Usability study

      • Our User research team conducted a series of studies to gather qualitative feedback around user sentiment.

        • One study was solely focused on users with various disabilities.

    • Customer Journey Map 

      • I took this work upon myself to help us gather a full picture of our customer journey​​ across our different channels.

    • WebAim onsite

      • I arranged to have WebAim come onsite for a two day training for all of our product practitioners​​ to gain a base-level understanding of the work they could to improve the accessibility of our experiences.

  • Prioritize the work to be done

    • I worked alongside our Project Manager to understand the business requirements and goals to help inform our system roadmap.

  • Design

Zappos customer journey map

Our customer journey map

My role​

  • Built out and maintained the Melody Library sketch file

    • I was the owner of the file until we onboarded to Abstract (a year later), which allowed everyone to branch off, contribute their work, and merge to Master.​

    • Accessibility wins:

      • Defined the semantic heading structure, color combinations, typography styles and form elements

  • Designed our first set of responsive landing page components

    • This was a business request to help inch us toward a more responsive site, as well as provide our site operations team more choice in layout and styling of the page.

    • ​Accessibility wins: 

      • Replaced text-based images with live text

        • Text could now adapt to different viewports and user zoom, without losing quality.

        • Text color and size could now be customized by users (if they had tools to enable them to do so).

        • Screen Reader users could now quickly scan and navigate through a page that was logical in structure.

        • SEO had more text to index content.

      • Defined descriptive link guidelines

        • Screen Reader users could now quickly scan the links within the page, and be informed where those links would take them.​

  • Designed a template system for our triggered transactional emails

    • ​In order to create a more cohesive journey for our users, we needed to revisit our email experience to reflect the updated styling our site was transitioning to.

    • Accessibility wins:

      • Defined a reusable semantic heading structure​

        • This created a clear visual hierarchy for our sighted users, as well as a navigable hierarchy for our SR users.​

      • Defined alt text for reusable imagery

        • This eliminated the misuse of alt text​.

      • Defined a system to visually and programmatically display critical label: value associations

        • This created a cleaner, more navigable UI, both for our sighted and SR users.

​

Phase 1 Work

Melody UI Stickersheet

Slide 1: Melody UI Library   / Slide 2: Landing page components / Slide 3: Email templates

Phase 1 retrospective

​

Highlights

  • Set us up to transition the rest of the site to be responsive

  • The new landing page components drastically improved efficiency for time to site for our Site Operations team.

    • Opened the door to future segmentation with the introduction of live text​

  • Everyone wanted an updated experience for their own merchandising verticals

  • Email click-through rate increased 12%

  • We remediated a ton of existing Accessibility issues

  • Our team and project became viral within the organization

​

Areas of opportunity​

  • Lack of documentation created unexpected usage

    • ​I had discovered that my customer (the site operations team making site updates) were getting creative with the components, using them in ways that were breaking the accessibility and visual display at different viewports.​

  • Developers couldn't decide how to package the system

    • This created inefficient workflows and inconsistencies in implementation (Snowflakes)​

    • As the components started to be used across different site teams, developers were ​building one-offs, completely mitigating the purpose behind the system. 

  • Naming conventions needed more finesse and consideration​

    • As the system began to grow, individual contributors started making their own naming decisions, often too specific to span the spectrum of the full system.

  • We needed to establish principles to guide our decision making.

    • Design and front-end conversations were becoming increasingly frustrating and cyclical. ​

  • Due to popularity, an influx of requests came through and we discovered a need for a governance process.

  • We realized establishing success metrics and setting milestones would be beneficial in raising awareness and buy-in around the initiative. 

Phase 2 overview

Phase 2 happened much more slowly, as we lost our project manager, and were encouraged to put Melody on the backburner in order to prioritize other business requests.

​

Next steps

  • I worked with the site operations lead to document best practices guidelines for our new components​​​.

  • I worked with the front-end lead to re-audit our new components to build a case for code and naming consolidation​.

  • We established a design system governance process

  • I created my first round of accessibility documentation for our new components.

  • I began to address global accessibility issues such as:

    • Site-wide descriptive​ labels

    • Focus management 

      • Tab/swipe order​

      • Styled/visible focus indicator

    • Closed captioning

    • Site-wide semantic heading structure

    • Skip to main content link

Phase 2 Work

Slide 1: Design system governance process   / Slide 2: Melody component documentation / Slide 3: Component best practices / Slide 4: Landing page component accessibility 

design system governance process

Phase 2 retrospective

​

Highlights

  • I implemented site-wide usage of our semantic headings.

  • I worked with our various platform teams to swap out our video player (which wasn't accessible), and replace it with Youtube in order to leverage dynamic closed captioning.

  • I worked closely with front-end teams to iterate on the accessibility of our existing components.

  • The more we scaled Melody out to additional pages, the more Accessible our site became.

  • The work I did helped to build the case to create a full-time Accessibility role

 

Areas of opportunity​

  • Need to figure out a way to better incorporate accessibility into the beginning of a project

  • Need to figure out ways to catch accessibility issues before they become customer facing

Slide 1: Design system governance process   / Slide 2: Melody component documentation / Slide 3: Component best practices / Slide 4: Landing page component accessibility 

Phase 3 (happening now)

Phase 3 has been focused on site experience innovation 

​

My work thus far

  • I'm enriching our accessibility documentation by including:

    • Suggested markup

    • Suggested ARIA use

    • Screen reader and keyboard guidance 

  • ​I've worked with product owners to integrate automated accessibility scans into our pipelines to help catch issues before code deployment.

  • ​I've created a customer-facing Accessibility Feedback Survey to gather qualitative and quantitative data around the accessibility of our experiences.

  • I've established a set of success metrics to inform the effectiveness of the accessibility of the system:

    • ​Reducing Level A and Level AA success criteria violations​​

    • Reducing the number of issues caught with with integrated testing

    • Reducing the number of negative feedback responses via accessibility survey and customer support

    • Being upstream of new projects and product discussions

  • Accessibility template iteration

    • I've been experimenting with different ways to combine accessibility notations into prototyped flows (one example below). 

Phase 3 Work

radio button component example documentation

Slide 1: Accessibility component documentation example   / Slide 2: Static annotation example / Slide 3: Video of component prototype for accessibility

bottom of page