Step 1 – Start a component proposal

RESPONSIBLE: (Anyone! And you, I presume)

Before starting a proposal confirm that the need is not already supported. Does a new pattern need creating? If there is an existing pattern, does it work for a specific application/use case? 

If appropriate, you may create a proposal in Confluence instead of Figma

In Figma:

State

Description

The proposal is just an idea. Discussions on the draft serve to gather feedback and help prepare the idea to be .

The proposal is ready for a review when it has: A succinct use case and purpose, a general description of behavior or variants, and a design reflected in at least a wireframe level fidelity.

Proposal Reviews start in person in the Paragon Working Group meeting and continue on Slack if needed. To get on the meeting agenda make a post in the #paragon-working-group channel on Slack.

The group will consider the following:

  • Review the use case from the and perspectives and come to an understanding of the need.

  • Should this component live in Paragon?

  • Determine if the use case is unique. If so, it should remain be a one-off solution.

  • Do we agree on what to name this component?

Reviews move the proposal to , , or

An accepted proposal is ready for further design and engineering work. A proposal is accepted with three approvals (minus the proposer), one from each UX, UI, A11y, and Eng. Once accepted the proposer should begin building out the component spec with UX/UI/Eng/A11y (if they have not already).

A deferred proposal should be designed and built as a one-off where it is needed. Move the proposal to a new folder in this space (TODO: when this happens the first time add a folder in the wiki in an appropriate location)

A proposal needs changes to become again.


Step 2 – Get your proposal approved at the Paragon Working Group

RESPONSIBLE:

Step 3 – Complete the component design specification

RESPONSIBLE:

Step 4 – Create a Jira ticket to implement the component

RESPONSIBLE:

Engineering resourcing for implementing Paragon components is currently ad-hoc. Squads that need the component are ideally responsible for the work, but some times it’s too much work to take on in the near term. This is an ongoing challenge to be aware of.


Step 5 – Implement the component in React

RESPONSIBLE:

Tip: Before you start implementing your component, it us helpful to write example of how you would want to use this component as if you had already written it then and share that with others. Getting feedback on props api or component naming early on can reveal key concerns you may have missed and save time.


Step 6 – Finalize the design and technical documentation & (blue star)

Based on the QA findings from design

Announce and evangelize the new design pattern throughout edX!