This is super helpful, thanks @Volker_E!

Couple questions:

1. Do our components ever consider iOS or Android? If not are their style guide choices documented in a different way?
2. I still don't totally understand step 3 and the process of these new components getting built. Who do we hand over these recommendations to? Are there engineers specifically working on helping us implement these new components? Or do we put it into a queue for when a team needs it and then they implement it?

@mwilliams

1. Once upon a time when Design team was not as being and resources where even scarcer, we've decided that we care only about web components and orient on Android's and [[ mw-pt-languages-list | Apples ]] own guidelines for component design. A missing part in current Design Style Guide is to explicitly clearly paint the boundary of different platforms.
2. As far as the current resources plan is clear, components will be implemented alongside product team plans within those teams. This task should help to make product teams identify the correct process in designing and implementing components, that are consistent and aligned to our Design Style Guide.

two questions that came up for me during our meeting today:

1. should there be an initial step where someone looks at the product and identifies common elements that are not yet components? Perhaps this is only relevant for for our internal process

2. should there be a final step that requires one to identify all the places in the product where the component should be implemented, and then contact the various teams to let them know the new thing is ready for them to use?

I am perhaps missing some context regarding 3rd party usage of our styleguide, but I am also wondering: do we want components in the styleguide that are not in use in our product? How would would we evaluate them and keep an eye on them over time?

Updated with additional feedback by @lucyblackwell.

In T266335#6600773, @alexhollender wrote:

two questions that came up for me during our meeting today:

1. should there be an initial step where someone looks at the product and identifies common elements that are not yet components? Perhaps this is only relevant for for our internal process

From my understanding that is a precondition to the whole list. As designer you identify an element that should be a component from your point of view.
Then you make sure, that there's not such component already defined where this component would fit in as subtype or lone-standing.

2. should there be a final step that requires one to identify all the places in the product where the component should be implemented, and then contact the various teams to let them know the new thing is ready for them to use?

This is now covered in point “Research” by providing the overview of current similar, but sub-par implementations by tagging the new component task with the products with already available related ones.

I am perhaps missing some context regarding 3rd party usage of our styleguide, but I am also wondering: do we want components in the styleguide that are not in use in our product? How would would we evaluate them and keep an eye on them over time?

Those should be evaluated case by case. Similar work was accomplished in OOUI. Prioritization is clearly on Wikimedia Product teams needs. One way beyond could be that the contributor(s) are fully going through the process with lil needs from our side besides a rough clearance on reviewing. We should defer this question until we've got an exemplary use case.

As a food for thought for defining your ideal proces you may want to look into the process of Designing Components that @Sarai-WMDE has created.

@raja_wmde @Sarai-WMDE Designing Components is very detailed and in parts less generally phrased, which makes sense as it applies to the Wikidata prototypical components process.
Similarities are found

• in the overall process
• the research vs discover phase
• the design phase with less detailed approach here
• the document phase (interaction states are important and task description process will be updated after this comment), whereas here it's sub-summed in “design”

Differences are found

• design tokens usage details, that's strongly on the implementation side more for developer audience, we have been focussing on designer and design volunteer audience here
• responsive behaviour and design is further up in our approach, as it's essential for cross-product component success and shouldn't come as a “brush-up” afterthought
• Testing and quality assurance are explicitly mentioned as we want to ensure user satisfaction from first rollout and these two important points will help us with this.

I've already provided this feedback to @Volker_E on Slack, but am adding here for documentation purposes:

1. Storybook should be represented in the first step (and explained in relationship to OOUI demos)
2. I'd avoid using acronyms or define them because it can get confusing here
3. I know that I would get tripped up when I started to read step 4 (handover to development and would ask for help.

Hi @Volker_E, thanks for your analysis and outlining similarities and differences. Though I must say I wouldn't see them as such big differences, more as different approaches and in order to get to ONE shared component library we should discuss how to get to the same approaches. Here are some points to consider how to come to one process:

• The design tokens section on this page is not meant for the developer audience, the idea is that designers REUSE tokens that developers and system designers have created and that's why this section exists. We believe that this is also the exciting part that can make the handover between design and development easier and less ambiguous. When designers use existing tokens in the intended way, they can be much more specific on their designs and achieve overall consistency. If this section appears to be meant for the developer audience, we probably need to work on the description to make it easy to understand. We are happy to get feedback from WMF designers and volunteer designers (do you have contacts?) which information they need to reuse tokens. (Of course, this also needs to be aligned with the developers whether we want to use tokens or not, but I think we should get to answer from design side whether it's feasible and useful for us)
• Responsiveness and accessibility aren't only considered afterwards, we just listed the "Design Definition of Done" as a kind of checklist at the end. But it's a good point to include it in the list earlier as well
• I like your testing and quality assurance points and would be interested to learn in which context and with whom you'll test the components. We are currently envisioning to test the components together with the first application they are used in, but testing earlier would of course be better. Same for Quality Assurance: How do you do that?

When researching for the progress indicator component, I've seen a worth exploring way of going about point 2 “Design” in this task description's list in Adobe's Spectrum. It includes the mentioned points very similar, but in a per-component design checklist.
Still need to figure out if that's redundant information or if it's necessary to have such list at each and every component in contrast to one exemplary component list.

In T266335#6640135, @raja_wmde wrote:

Hi @Volker_E, thanks for your analysis and outlining similarities and differences. Though I must say I wouldn't see them as such big differences, more as different approaches and in order to get to ONE shared component library we should discuss how to get to the same approaches. Here are some points to consider how to come to one process:

• The design tokens section on this page is not meant for the developer audience, the idea is that designers REUSE tokens that developers and system designers have created and that's why this section exists. We believe that this is also the exciting part that can make the handover between design and development easier and less ambiguous. When designers use existing tokens in the intended way, they can be much more specific on their designs and achieve overall consistency. If this section appears to be meant for the developer audience, we probably need to work on the description to make it easy to understand. We are happy to get feedback from WMF designers and volunteer designers (do you have contacts?) which information they need to reuse tokens. (Of course, this also needs to be aligned with the developers whether we want to use tokens or not, but I think we should get to answer from design side whether it's feasible and useful for us)

Ok, fair. From my experience devs are more than happy to use any design-specified variables/tokens when available and aligned with the design they receive. Therefore the focus here was more limited from process in the Foundation in building user-interfaces.

• Responsiveness and accessibility aren't only considered afterwards, we just listed the "Design Definition of Done" as a kind of checklist at the end. But it's a good point to include it in the list earlier as well

Just to be clear, this wasn't meant as negative pointer. More about explaining how we prioritized, having dealt with a “design is sufficiently be called towards end of product design lifecycle” attitude sometimes in the past.

• I like your testing and quality assurance points and would be interested to learn in which context and with whom you'll test the components. We are currently envisioning to test the components together with the first application they are used in, but testing earlier would of course be better. Same for Quality Assurance: How do you do that?

We've got dedicated QA resources for component development in-house. When requested appropriately and provided with acceptance criteria alongside such checklist, they are able to catch a great number of issues before releasing them into the wild.

Information for subscribers, there's currently a technical misconfiguration that hinders updating our Wikimedia-server instance with latest Design Style Guide master from GitHub repo. Until this is figured out, updates will not be online.

Added current, once more extended process list to DSG's CONTRIBUTING.md file in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/445

Will keep this task open for further discussions and iterations, specifically re-visiting some of the development handover parts with further activities on the Vue.js Migration team.