Skip to content
This repository has been archived by the owner on Jun 29, 2023. It is now read-only.

Component Design and Development Process

Katy Robinson edited this page Nov 22, 2019 · 2 revisions

draft

Goal

Document and define some formalized processes for the design and development process for components.

Term Definitions

  • user story - Example: As a [role] I want to [adverb]+[task] so that [outcome].. -- should be part of planning issue.
  • wireframe - Define the UX for the component. This doesn't include the environment the component lives in unless it's relevant.
  • API Design Draft - Typescript interface with properties, methods, events. Defining which are public for documentation. Ensure API is consistent with other APIs.

Project Team Roles

  1. PE
  2. UI Designer
  3. Developer
  4. UX Architect

Process

1. Kick-off meeting

  • Meeting Organizer: [PE]
  • Goal:
    • give key contributors a good idea of what the broad story is.
    • ensure design has enough to start ideating and to produce ✨ if available, walk through initial design/wire-frame(s).
  • Activities:
    • Intro - people meet. Tell people about component. - Knowledge transfer - from SMEs (optional)
    • Brainstorming - Ideas for component features brew.
    • Identify source information to inform user stories
  • Tasks to be assigned: - Comparative Research [PE & UI] - Research user stories [PE & UI]
    • Write user stories : [PE & UI] meeting
    • Document requirements and user stories in planning issue [PE]
    • Gather any additional requirements and add to planning issue. [PE]
    • Any necessary dev Research [DEV]
    • Create new issues [PE]
    • A TypeScript interface rough draft should be produced. [DEV]
    • ✨ If no initial design/wireframe was presented, produce preliminary wireframes/designs [UI]
      • Designs should approach a broader epic story (which may not yet be defined) and should also be modular enough to accommodate release planning.

2. Wire-frame Review

  • Meeting Organizer: [PE]
  • Goal:
    • Ensure dev has enough info to finish (or at least begin with understood follow up) assigned issues
    • Designer gets feedback on designs and accessibility features
    • Ensure developer has enough info for creating the initial API draft
      • interface
      • defaults
  • Tasks to be assigned:
    • Update wireframes with feedback [UI]
    • Submit API Design rough draft for review in separate issue to be reviewed by component devs. [DEV]
      • ✨ Simpler API changes can be submitted via the origin issue or its respective PR.
    • Issues are divided into logical tasks. [PE and DEV]
    • Issues are fully fleshed out and assigned to dev when ready [PE]

3. Status Updates

  • Goal
    • At the weekly recurring sync, provide relevant status info and note any blockers.