Story Page Migration + Design System

Read my original Medium story on my process here.

Designing for a Tech-Stack Migration

Up until this project, my role as a product designer had been fairly straight-forward. This project presented a new challenge. I had never been through a migration before, so I was discovering and defining my role in all of this along the way.

I broke it down into the following objectives:

• Ensure that the new story page looks and feels identical to the original
• Identify where we can make improvements
• Unify and consolidate where possible; be intentional about differences
• Advance and integrate design system components

Designing a Design System Through a Migration

When this project began, we needed a design system using the updated code stack. This meant I was simultaneously designing a system while we were building it.

Typography

I began a comprehensive type style audit in advance of the migration to determine if we had an opportunity to improve our type system. After assessing my audit, I proposed a new model for organizing our type styles and collaborated with our design system committee to refine and stress-test it.

The difference is in its organization: the old system is scale-first, and the new is function-first. This makes choosing type more intuitive. For example: 'Title' is primarily used for titles and 'subtitle' always accompanies the title.

Documentation

One of my goals with the migration was to advance and integrate design system components. A large part of that is creating documentation and resources for all users of the components: both engineers and designers. I set up a comprehensive Figma design library for our team and worked with engineers to create corresponding documentation.

Components

Before the migration, we were using 15 avatar scales and multiple author byline components that varied in avatar size, spacing, and type treatment depending on the page. I created a system for how we apply certain author bylines, documented where they're used, what their variants are, and applied consistent spacing and type treatments.

Grid System

Before the grid update, most pages on Medium didn't follow a cohesive grid system. I did an audit on all of our major pages to get a sense of what patterns exist as far as content width, grid, and global layouts.

Goals of the new system: Establish a framework optimized for our highest-traffic surface (the post page) that can be used as we migrate other surfaces. Create more space and breathing-room for UI. Carefully consider responsiveness and serving content across all breakpoints.

Key Takeaways

1. Migrating a page on the internet is not simply replicating the original — and that's a good thing.

Something kind of nice happens when you create ~20 anatomical blueprints for a page on the internet: you become intimately familiar with it. It forces you to observe the thing from all angles — hold it up to the light with a magnifying glass to examine its purpose, turn it inside out with tweezers, and then inspect it with the minds of your colleagues.

2. Establishing clear design standards is essential, especially when working in Agile.

Medium uses Agile for software development. Working within this method as a designer means constantly asking: Does this implementation meet our design standard? What exactly is our design standard and how do we preserve its integrity while working within sprints? At what point is a design requirement blocking?

3. People feel more invested when you involve them early.

As our updated design system started to take on a firmer shape, I encouraged engineers to participate in its formation — as they are also users of the system. Engineers would join our design system syncs and offer their input for typographic nomenclature, logic, or architecture. Their input and involvement led to more clarity and ultimately a stronger framework.