HIGH-LEVEL FLOW
Collaborators:
Responsible | Flow | |
|---|---|---|
| 1 | Start a component proposal Identify new UI need and define the use case in a Google form submission or a Component Proposal. Bring it to the UI design team and #paragon-working-group to determine if it should be added to Paragon or a one-off solution. |
2 | Expand proposal into a component spec Share the spec with the #paragon-working-group | |
| 3 | Implement the component spec Publish the design, as well as UI, UX, and dev documentation. Request QA of the implementation. |
| 4 | QA the implementation |
| 5 | Finalize the implementation, UI UX doc, and dev (technical) doc Announce and celebrate! |
DETAILED FLOW
Step 1 – Start a component proposal
Responsible: 
Accountable: 
Consulted: 
Informed: 
If you need help creating a proposal submit a request (via Google form) to work with a designer.
If you need help creating a proposal submit a request (via Google form) to work with a UI designer.
Before starting a proposal confirm that the need is not already supported. Does a net-new pattern need creating? If there is an existing pattern, does it work for a specific application/use case?
Yes, it works (stop here if checked, and use an existing pattern)
No, it needs to get modified
Start a component proposal by creating a child page of “Component Proposals”
Use the Paragon Component template when creating the page.
The proposal should start as a . Work through the proposal states below to take your proposal from
to
to
.
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:
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:
Reviews can result in moving the proposal to | |
An accepted proposal is ready for 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 |
- Once a proposal is APPROVED TO ADD, work to should proceed to create a component specification.
Step 2 – Create a component specification
Responsible: Accountable: Consulted: Informed:
develops the proposal into a component specs, filling out the component proposal sections. This spec doubles as design documentation.
Share the component spec in the #paragon-working-group channel.
Step 3 – Implement the component specification
Responsible: Accountable: Consulted: Informed:
Based on the design doc from the previous step:
Step 4 – QA the implementation
Responsible: Accountable: Consulted: Informed:
QA: Identify bugs and design/implementation issues
Async: Use the #Paragon-working-group slack channel to review the implementation asynchronously
Sandbox (Adam has set up Paragon PR deployments)
Step 5 – Finalize the design and technical documentation & 
Responsible: Accountable: Consulted: Informed:
Based on the QA findings from the previous step:
Announce and evangelize the new design pattern throughout edX!
Share in Slack channels (which?)
Quarterly roll ups? Theme demos?
Have a drink or two (2 drinks per pattern)
See the RACI Matrix for detail on role definitions for Responsible, Accountable, Consulted, Informed.