Design and technical leadership for Paragon occurs within 2U/edX. Adam has transitioned to a new role, Product Design Manager for Engagement Theme and no longer has bandwidth to serve as the technical owner for Paragon.
Adam Stankiewicz is the technical lead. Gabriel Weinberg is the design lead. This document outlines the state of Paragon and its roadmap, followed by the responsibilities of the ,
,
,
, and
.
Paragon contains over 50 components (depending on how you count) and a full featured SASS styling framework expanded from Bootstrap. It is documented in Figma and on the technical doc site.
Paragon’s maturity as a design system falls somewhere around stage 3. We’re probably seeing an acceleration in development, but given all the work we’ve put in it might not feel like it yet. We still have a large body of work we can invest in to continue to get more efficiency using the design system.
We currently have about 47 stable components in Paragon. For comparison, there are about 72 stable components in Polaris and a rough count of about 60 in Material React. Additions to Paragon are currently proposed at a rate of about 2 components per month. Adam Butterworth (Deactivated): I expect this rate of additions to continue for the next year or two.
Source data: Paragon Components Status Google Sheet
The architectural roadmap needs more definition and prioritization, but avenues of investment are currently envisioned under a handful of larger initiatives:
Ease of Access
Ease of Use
Increased Power and Value
|
|
|---|---|
|
|
|
|
Ensure Paragon support Webpack 5 module federation | |
Increase awareness of Paragon’s offerings |
|
|
|
|---|---|
|
|
Make the Paragon component api easier to use |
|
Improve the clarity in design specs about where Paragon components are used
|
|
Increase the frequency that there is a component that matches our needs
|
|
|
Add i18n support with no dependency on frontend-platform |
|---|---|
Add analytics features to clickable components |
|
Reduce the risk of making changes to components |
|
Componentize common a11y needs
| |
Make it easier to write a new component in Paragon (linting/code generators) |
Adam Butterworth (Deactivated)
Drives the design direction of the system.
Supports designers using and contributing to Paragon
Helps to facilitate Paragon Working Group meeting
Fixes or improves design documentation
Triage and resolve design bugs
Directs the architectural roadmap
Implements the architectural direction: individually, via blended development, or may escalate to theme leadership to assemble a tiger team.
Ensures incoming Paragon bugs are triaged and resolved, as needed
Leveraging time from the working group to triage and support the design system.
Helping to facilitate Paragon Working Group meeting
Ensures engineers are supported in contributing to Paragon
Ensures pull requests are reviewed in a timely manner. Any frontend engineer at edX is permitted to perform code reviews at the discretion of the .
May implement new component designs when appropriate
(informal group of engineers and designers)
Provides feedback and approval on proposed design additions, technical additions, and architectural changes
May also assist with the responsibilities of the design owner and technical owner
Participate in a support and triage rotation to continue to maintain the design system.
Writing and maintaining UI components is a core part of User Interface Development. We want to foster and encourage a culture of writing components needed by a given team, to a standard level of maturity, and then introducing those components directly into the Paragon ecosystem for sharing and re-use.
This development should be done in tandem with, and under the design and technical guidance of the design team and Paragon Technical Owner to ensure that components are as mature and effective as possible.
Squads are responsible for the development of components they need.
If a squad does not have the frontend expertise to build a component that they need, they should escalate the need to their theme leadership. We recommend that each theme should have at least one frontend expert. Other options for development include: blended development or negotiation with other squads.
Reviews pull requests. Any frontend engineer at edX is permitted to perform code reviews at the discretion of the .
Identify needed components in the course of squad work
Design and document new or updated components or design system features in Figma
Support engineers building components and design system features from specs in Figma
Identify Paragon components and design system features used in design specifications
Make it possible to use Paragon in as many codebases as possible