HIGH-LEVEL FLOW
Collaborators: UI UX A11Y ENG PM PROPOSER DESIGN MGR
Responsible | Flow | |
|---|---|---|
PROPOSER | 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. |
UI | 2 | Expand proposal into a component spec Share the spec with the #paragon-working-group |
ENG UI | 3 | Implement the component spec Publish the design, as well as UI, UX, and dev documentation. Request QA of the implementation. |
UI UX A11Y | 4 | QA the implementation |
ENG UI | 5 | Finalize the implementation, UI UX doc, and dev (technical) doc Announce and celebrate! |
DETAILED FLOW
Step 1 – Start a component proposal
Responsible: PROPOSER Accountable: DESIGN MGR Consulted: UI A11Y Informed: UX ENG PM
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 Proposal template when creating the page.
The proposal should start as a DRAFT. Work through the proposal states below to take your proposal from DRAFT to READY FOR REVIEW to APPROVED TO ADD.
State | Description |
|---|---|
DRAFT | The proposal is just an idea. Discussions on the draft serve to gather feedback and help prepare the idea to be READY FOR REVIEW. |
READY FOR REVIEW | 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 APPROVED TO ADD, DEFERRED, or NEEDS CHANGES |
APPROVED TO ADD | 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). |
DEFERRED | 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) |
NEEDS CHANGES | A proposal needs changes to become READY FOR REVIEW again. |
- Once a proposal is APPROVED TO ADD, work to should proceed to create a component specification.
Step 2 – Create a component specification
Responsible: UI Accountable: DESIGN MGR Consulted: UX A11Y ENG Informed: PM
UI 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: ENG Accountable: DESIGN MGR Consulted: UI A11Y Informed: PM UX
Based on the design doc from the previous step:
ENG: Implements the proposed design and creates dev doc
ENG: Sends a link to the implementation for designer review
UI: Updates the design doc
Step 4 – QA the implementation
Responsible: UI A11Y UX Accountable: DESIGN MGR Consulted: ENG Informed: PM
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: ENG UI Accountable: DESIGN MGR Consulted: UX A11Y Informed: PM
Based on the QA findings from the previous step:
ENG: Fixes bugs/design implementation issues, and ships
UI: Makes any needed updates to design spec for documentation, confirming with UX and A11Y
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.