BUI Contribution Process

Contribution with Base UI

The purpose of the contribution is to allow the development of a component that has been approved by us (the Base UI team, in terms of both product and development) in order to allow the re-use of that component by additional teams in WIX and thus to share the component in the Base UI library. Contribution is a process of product that somebody else is doing, and we give the guidelines and resources (if needed), and the components will be shared into the Base UI library for reuse across Wix. 
Important!
Independent component development without sharing it to BaseUI library is not allowed!
Exceptions can be made only if approved by BaseUI team.
The more we get involved in the early stages as kickoff, the better we can make the contribution process, and so we can prioritise it as part of our backlog and part of our roadmap. However, the contribution process is a binding process to meet the times and meet the reuse components requirements for all the company's products. It is important to understand that we may not be able to comply with the contribution process if we know about it just before development for example, in this case, we may request to repeat the entire process with the aim of preventing the development of a component that has no meaning of reuse and sharing with the whole company.

Principles for contribution

Inform
We need to know that a process starts, to understand its purpose and schedule. On our part, we will add the project to our backlog list and prepare according to the schedule.
Review
We go through the process together with the other group, raise important points to continue, and agree with the following.
Approval
Get our approval for product and UX decisions that affect the products and components in the shared library.
Commitment
Agree on the schedule and deliverables and the list of components and who is developing it and how. This list can share responsibility between the Base UI team and the Vertical / company both in looking at the resource and times.

The Process for contribution

To simplify the process, we've outlined a standard product-making process here at Wix. At each step in the process, we specify what it takes to work with the Base UI team to develop components into the library. To learn about the full process of making a product in WIX, see an example from Editor native components.

00 - Kickoff - Inform Base UI team (soon)


Who
PM & UX (from the vertical/company) are responsible for informing the Base UI team that a process is starting for a new product or an update to an existing product.


What we need from you?
  • Send Kickoff summary link to base UI team.

We (Base UI)
  • We'll add this project to our backlog list to keep track of the project

01 - Research - Inform Base UI & get review from Base UI (soon)


It's important to understand which issues will be very relevant to the Base UI team and so it would be worthwhile to include those topics in the research. This can help us all to move forward with the product.

What we need from you?
  • Link to the research to review it ASAP by Base UI team.  

Note: By reviewing the research we begin to get an idea of the product, its use and perhaps what components can be used in the product. In addition, it gives us an understanding with other teams that may make similar products and need the same components.

We (Base UI)
  • We'll update this project in our backlog list to keep track of the project.

02 - Product Spec - Get Review from Base UI (soon)


What we need from you?
  • Link to the product spec. to review it ASAP by base UI team.
  • List of components (if exists at this stage) that may be affected by the product and ideas about what is needed from Base UI point of view.

Note: Base UI will review it and will add our notes with regard to components.

We (Base UI)
  • We'll update this project in our backlog list and we will prioritize it if needed together with you.
  • We will assign UX & Dev lead from Base UI to support or commitment for this project.

03 - UX & Design - Get a Review & Approval from Base UI


At this point, it is possible to accurately understand which new components are required, which components require updating, etc. This step requires Base UI approval with the process.

What we need from you?
  • Link to UX flow & Spec
  • Setup meeting with Base Ui team, we will review it together we will add our requests and notes.

Notes:
  1. Precise decision, who is developing the new component, how the Base UI team will help with the UX & development (if needed), or take part in the UX & development including a clear schedule.
  2. Jira tickets for the tasks.
  3. The approval phase here can be effected from the UX review. Only after the UX review cycle, we (Base UI) can see the fixes and improvements to get the approval done. 
  4. Agreeing on the list of components, assignment of tasks (if required), including escorting the process by the Base UI team and a time commitment. In this session everyone understands how the development is going to be and how the components are shared with the Base UI library.

03A - Closing the specs & design - Get Approval & Commitment (if needed) from Base UI


At this point, we are working together on all the parts that will be submitted for development, and here it's approval from the Base UI team. Sometimes there is also a commitment from the Base UI team (If the Base UI team is part of the project execution).

What we need from you? 
  • The vertical/company team working on an agreed list of tasks for the components.
  • Review the Jira task together and assign them.
  • Zeplin Specs & Links
  • Dev. infrastructure for the components

We (Base UI):
  • The Base UI team working on agreed list of tasks for the components (if needed by Base UI team)
  • Agreed upon release times

03B - Base UI Design System Gatekeeping - Get Approval & Commitment (if needed) from Base UI


This is a short phase in which designers from the outside group submit the materials for the Spec test to be compatible with the design system. Even if the designer comes from the Base UI team, this step is necessary for approval by those responsible for the Base UI library.

What we need from you? 
  • Zeplin Specs & Links

Who (from Base UI):
UX Base UI library & components domain, Dev from Base UI

Responsibility:
UX Designers from the external team need to send materials to UX Base UI to check it and approve it before sending it to development.

Goal:
To avoid mistakes and to be aligned with our design system index and quality, every UX or UI that has finished the component (or any other part) in the design system, must send it first to DS gatekeeping. the UX Base UI designers will check it and they will give their view according to our guidelines.

Outcomes:
  • Fixes or approved to dev. This is the outcome in this phase.
  • This phase should take only a few hours
  • Meet the planned and agreed upon release times

Note: Before sending the spec. to dev team, all materials go first to our Zeplin buffer to check by the DS gatekeeping. Only after that, they approve it in our Jira system.

04 - Ready for Development - Get Approval & Commitment from Base UI


At this point we want to know that the materials are ready for development. In addition, we may be part of this development at this stage, whether it is with help or support.


What we need from you?
Epic Jira ticket should appear with all links to spec. (Product spec, UX Design, Zeplin, link to source files in drive and any source as needed. Also to subscribe to all team members who are working on it (Jira).

05 - Development - Commitment (if needed) from Base UI


Development is our last part of the process of finishing the product. We must all enlist in tight communication at this stage to provide answers, solutions and most importantly to meet the quality of the product designed.

What we need from you?
  • Communication! 
  • And please raise any questions or concerns regarding the development of Component so that we can get involved and help with the solutions.

06 - User and Design System QA - Get Approval & Commitment from Base UI


At this point it is important to understand who is doing the QA so that we will also join the effort before the component enters the library for the use of additional teams.

What we need from you?
List all problems and bugs and their prioritization before launching the product. Once the solutions have been agreed upon, assignments must be made.