Page MenuHomePhabricator

Define the handover elements from UX to Devs
Closed, ResolvedPublic

Description

As a UX in a hike I want to be able to request getting a component implemented for the current hike. For that I need information about the process as well as the what the developers will need from me in order to implement what I expect.

Important for UX:

  • create/document component level tokens
  • documentation on "how to use tokens" i.e. instructions for designers
  • definition typologies of the buttons

Important for Devs:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 30 2020, 5:51 PM
darthmon_wmde renamed this task from Handover UX -> Devs to Define the handover elements from UX to Devs.Jun 30 2020, 6:10 PM
Pablo-WMDE added a subscriber: Pablo-WMDE.EditedJul 9 2020, 11:33 AM

Criteria:

  • component illustration in figma (link)
    • distinctive name for the component
    • "design specs" with used tokens (in e.g. F31857766 (T254591) we ideally expect not only px values, but token names)
    • list all (incl. name & used tokens)
      • props (flavors [e.g. neutral, progressive, destructive], possible others [e.g. size]), default values for all props
      • states & the user action leading to them (mouse, keyboard, tab, ...)
  • how to display in storybook (knobs, separate stories, ...)
  • possibly, assets, in agreed format(???), are available for download (e.g. from figma) into the code repository
  • possibly, documentation for more complex scenarios of interaction design (e.g. move upon click, ...)
  • (informal) some idea of what kind of content can be shown inside of a component (e.g. "button only ever holds text" vs "could be an image sometimes")

Questions:

  • are component level tokens created by UX or not (in the repo)?
  • is it part of the design spec how the "modifiers" are applied (e.g. via a prop, separate component, ...) or is this dev domain?

Criteria added by Pablo after the meeting:

  • possibly, mention patterns which are intentionally identical to other components (e.g. "same ratio of font size and line height like in ComponentX")
  • possibly, describe responsive behavior
  • small description of purpose which dev can attach to the code/storybook (c.f.)

Questions:

  • are component level tokens created by UX or not (in the repo)?

Sarai: I can do that but will need feedback from the designer on it to check whether they can see themselves doing it
Jakob: that may create a number of potential loops that only designers will do so that UX may become a bottleneck
Tonina: I am fine with that although in the case that devs do it we need to have certain information to name it correctly
Sarai: that is part of the structure and the naming convention
Pablo: +1 to everything

Conclusion: Devs will be the ones creating them. The relevant needed information will be provided by UX.

Questions:

  • is it part of the design spec how the "modifiers" are applied (e.g. via a prop, separate component, ...) or is this dev domain?

Sarai: for the buttons, for example, I already have a list of the modifiers

Conclusion: Sarai proposes the modifier and we see whether it works like that

I somehow think this story is covered by T257846. What do you think, @Rajagum?

Yes, if the described handover covers everything needed for developers (as indicated here), this story can be closed as well.

raja_wmde removed a subscriber: Rajagum.Aug 18 2020, 8:47 AM
Tonina_Zhelyazkova_WMDE closed this task as Resolved.Aug 18 2020, 5:16 PM