Page MenuHomePhabricator

Exemplify component/pattern design process
Closed, ResolvedPublic

Description

Summary

The component design process aims at providing guidance for UX designers involved in the creation or modification of system components. In the current draft, these are the steps involved in said design process are:

  1. RESEARCH & PREPARE (aka DISCOVERY): The goal is to identify and collect information on the building blocks, behavior and intent of the needed component.
  2. DESIGN (I. INTERACTION, II. VISUAL STYLE): The component’s interactive and visual features are defined following the principles documented in the Design Style Guide, and the learnings extracted during the discovery phase.
  3. EVALUATE & ITERATE: Collect feedback from designers, engineers and (ideally) users and apply the needed adjustments
  4. HANDOVER : Document design decisions thoroughly and make them fully accessible for developers
  5. VALIDATE: Test the implemented component in order to make sure it follows the interaction, visual, responsive and accessibility specifications.
  6. DOCUMENT: The visual and interactive features of the component, as well as usage recommendations, are captured in a structured way and made available for consultation.

Note: The design process documented in this ticket and to be reviewed during the workshop sessions is a consolidation of two sources:

Original documentation

Relevant links

Objective

Gather feedback on each one of the steps and activities involved in the component design process

  • Is the order of the steps logical?
    • No objections raised at designer workshop, agreed on as is
  • Are there any steps missing or extra?
    • No objections raised at designer workshop, agreed on as is
  • Are any “instructions” unclear or too vague?

See designer workshop Google doc, the feedback will be addressed in component addition guidelines and supporting Figma file.

  • Where are extra documentation or resources needed?

Same as above.

Outcomes

Process has received valuable feedback, collected in Google doc above. We'll iterate on the design process based on feedback, and share new version. Location will continue to be Figma, but we're aiming at linking to the visually supported process from DSG (CONTRIBUTING.md & main pages).

Event Timeline

Sarai-WMDE updated the task description. (Show Details)
Sarai-WMDE updated the task description. (Show Details)

Hi there, pasting my comments on the Figma here for tracking:

  • Overall this process SGTM. However, there are sections of the Design Style Guide that are fundamental to defining DS components that themselves require design review and updating. I'm thinking specifically about the typography section, and to a lesser extent the colours. One piece that is missing entirely that I would recommend working on first is defining and documenting a grid as this touches on all the other components that will be created (see https://phabricator.wikimedia.org/T90687)
  • Relating to the step in the Discovery phase of filing a Phab task - Assuming the importance of ensuring product teams who use a given component in order to drive adoption, should the Contributors and Informed parties be tagged more formally in the Phab task? Ie., name the relevant people as another field in whatever Phab task template that will be created for this step?
  • Perhaps a requirement is that for every component, at least one product is identified as the test implementation. This was the case with pilot Vue projects like search and language switcher. This would help with:
    • i. Evaluation - testing in real world case
    • ii. Engagement with product teams (at least the one team that will definitely be using it)
    • iii. Adoption - seeing it live and working on one product presumably encourages others to use it.
    • iv. A more measurable and accountable KR – This quarter, design of X component that is used by at least Y products.
  • Perhaps a requirement is that for every component, at least one product is identified as the test implementation. This was the case with pilot Vue projects like search and language switcher. This would help with:
    • i. Evaluation - testing in real world case
    • ii. Engagement with product teams (at least the one team that will definitely be using it)
    • iii. Adoption - seeing it live and working on one product presumably encourages others to use it.
    • iv. A more measurable and accountable KR – This quarter, design of X component that is used by at least Y products.

For clarifying comment above, an example product is a clear requirement for any addition to the shared components library. Without a use case in our environment the implementation, maintenance and possibly also performance costs of carrying it along are too high. And it would become a candidate for removal.

Volker_E assigned this task to Sarai-WMDE.
Volker_E updated the task description. (Show Details)