Contribution with WSR

The purpose of the contribution is to allow the development of a component that has been approved by us (the WSR 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 WSR 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 our WSR library for reuse across Wix.

Important!

Independent component development for back-office page without sharing it to WSR library is not allowed! Exceptions can be made only if approved by us.

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, 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 the whole company.

Principles for Contribution

In the collaboration process, we specify where required: Inform, Review, Approval, Commitment

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 WSR team and the Vertical / company both in looking at the resource and times.

1 - Share Your Kickoff

After your new project kickoff you should:

Inform us that you are starting a new project, and send the kickoff summary.

Set a future meeting us in order to go over wireframes.

Note: the PM or UX (from the vertical/company) are responsible for informing the WSR team that a process is starting for a new product or an update to an existing product

2 - Product Review

After creating the product wireframes, before getting into design details -

Review wireframes with the DS, in order to see component status.

Create a new component with WSR

A new component or adjustments to existing component can come from:

1. Wix Style React Team

Within the WSR team, while identifying needs from users or verticals which lead to, improvement, adding or updating components.

2. Vertical team

A Requirement comes from a vertical, then the process of collaboration with us begins.

On this page you will find the process of both options clearly.

When to contact
Contact us in the most early stage of the process - in the research or wireframe stage, when you think you won’t be able to use an existing WSR component.

Why to contact
A. You think you might need a new component
B. You think you might need an adjustment to an existing component.

The process

Here you can learn about the full process for creating a new component – what your part is, where we do a review, when get approval by us and where is our commitment.

You can see here the flowchart showing our full process: https://wix.invisionapp.com/share/NUW98YVJ4BE

01 - Kickoff (Request)

(Inform)

When starting to work on a research or wireframe for a new project, and you think you can’t use existing components, Set a meeting with us to review the project.

This meeting needs to happen in the research or wireframe stage.

At this meeting we will talk about the product, its purpose, and your needs.

We will review the product together, get opinions from others in the team (PM etc.), and decide on one of these solutions:

A. Use an existing component

B. Adjust an existing component

C. Define a new component

In general the vertical will design and define the component with our review. We are a small team and need your contribution to be able to provide all the requests across WIx.

Who

UX from Vertical & WSR
(UI, PM, Support, BA, QA, Dev - if needed)

Responsibility
UX from vertical - setup this meeting and explain the needs.

Goals

Understanding the goal and motivation
Agree on one of the solutions:

A. Use an existing component
B. Adjust an existing component
C. Define a new component

Define high-level scope
Describe the timeline
Understand and agree upon release times

Outcomes

Everyone knows why we are doing this
Everyone has an idea of what this product is about
Everyone understands what is their responsibility in the product, and what should be their deliverables
List of components that may be affected by the product
!Rough time estimations by each member (I think it's more clear when research is done - domas)
Sent kickoff summary to all participants

02 - Research

(Inform)

Goal of the research is to
1. Collect relevant information to your needs
2. Understand the capabilities of the component
3. Define all edge cases and foresee possible problems.
4. Understand the scope of the project.

You should check existing Wix products as well as competitors products and patterns.
If this component will also be used by other verticals, it is also important to understand which issues will be relevant to them.

Who

Vertical's UX, PM
(If needed, consult with: Dev, UI, Support, BA, QA)

Responsibility

Vertical's PM, UX - collect all the feedback and information, and get the info needed from other teammates.

Goals

Gather helpful information to decide on the product definitions and scope.
Analyse all this information to obtain a broad overview of the user needs and the market.
!Four goals that are described in the beginning (domas's comment)

Outcomes:

Research file (or something similar), the ideal research should include:
- User Voice analysis: support tickets & calls
- Relevant BA (if exist)
- Competitive analysis (Libraries and products)
- Wix product analysis (if exist)
Share findings with the team. Insights and conclusions should be clear and accessible to all team members.
!Clear scope and timeline (Domas's comment)

03 - Design & Test

(Inform, Review)

Who

Vertical's UX
(Consult with: PM, WSR UX & Devs)

Responsibility

Vertical's UX - design & test solution, and schedule a meeting with us to go over the design.

Goals:

Define a quality, consistent and functional design for all the component needs.
Check different options considering all the research findings.
Test with real life scenarios on existing or future products to understand which design solution works.
Define animation for the component (if needed)
Present BI data supporting the design (if exist)
Meet the planned and agreed release time

Outcomes:

Visual file with the finalized design, user flow, prototype and mockup if needed.
Some components can be broken down to phases, if scope is too big.
If this product includes integration, PM should map them.
If this is an adjustment to an existing component: a list of the additional adjustments needed.
All the members in the team see clearly the scope of the product and the requirements of the product.

Note:
At this step UX from vertical and WSR need to share and sync.

04 - Review

(Review, Approve, Commitment)

Review meeting between vertical and WSR, including all the parties involved, UX, PM, Dev etc. Main goals are to go over the final design, understand which side is going to do the development, understand the timeline and get time estimation from dev.

Who (from vertical):

UX, PM (Dev - if needed)

Who (from WSR):

UX & Dev

Responsibility (from vertical and WSR):

UX, PM, Dev

Goals:

Go over the final design and understand the requirements.
Get EST from Dev (how long should it take looking at the whole scope of the product)
Discuss who is going to develop the component: Vertical or WSR.
Agreeing on the list of components, assignment of tasks (if required), including escorting the process by the WSR team and a time commitment.

Outcomes:

Agreeing on the component design and abilities.
Precise decision on who is developing the new component, how the WSR team will help with the development (if needed), or take part in the development including a clear schedule.
In this session, everyone understands how the development is going to be and how the components are shared with the WSR library.

05 - Spec & Jira Task

(Review) (Approval)

At this point, we will define accurately all component required properties, structure, constraints, behaviours, effects and animation. and also create Jira tickets for dev.
This step requires WSR approval to proceed with the process.

Who (from vertical):

UX
(PM, Dev - if needed)

Who (from WSR):

UX
(Dev - if needed)

Responsibility (from vertical & WSR):

UX & Dev to define the design spec and Jira tickets.

Goals:

Allow developers to access all up-to-date information neatly.
Cover all cases and edge cases, and define required capabilities for the developers.
Agree on the component’s abilities, properties, etc.
Adjust and approve the spec according to dev.
Validate and agree upon release times.

Outcomes:

Link to Zeplin spec (Zeplin template)
Link to UX flow
Open Jira tickets that include:
- Detailed description
- Zeplin link
- PNGs of Main screens
- Flow link if needed
- All relevant people as watchers

Notes:
1. Spec is approve only after WSR UX review & fixing cycle.
2. Review the spec with WSR Dev, and get developer requests and notes.

06 - Development

(Commitment)

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. It is the responsibility of the development to notify product and design teams of any issues that arise at this time. It is also the responsibility of the development to deliver to the product teams, design and QA any initial version that can be tested on it to reveal as many problems as possible at this time.

Who (from vertical):

Development

Who (from WSR):

Development

Responsibility:

Development

Goals:

Develop the product and components according to product spec, design, performance, and data.
Reach the quality of the product/component defined along the way

Outcomes:

Developed component
Component’s documentation in Storybook
Feature protected link to our UX, PM, QA teams to play with the product and test it before going live. Give access to play with the product.

07 - QA

(Approval) (Commitment)

All Dev, UX & PM are responsible together for testing the product, each in its own field.
The challenge is to combine forces with excellent communication to meet quality and product timelines.

Who (from verticals/Company):

UX, PM, Dev, QA

Who (from WSR):

UX, Dev

Responsibility:

Dev, PM, UX, UI

Goals:

Check the code and structure with our Design System parameters
Compare API to the spec and make sure the product meets the UX & UI guidelines
Check all UX props and behaviours in the component
Check accessibility settings in the component
Find bugs in the component
Check all edge cases
Experience the product in the user aspect (Try to interfere with the product in any way that users might do if intended or by chance)
Improve the product while testing

Outcomes:

List all problems and bugs and their prioritisation before launching the product for dev to fix.
Update Jira tickets accordingly to the tasks/problems, or open new Jira tickets for bugs.
After fixes, release the product 🎉

Contribution with WSR

Principles for Contribution

Sharing the process with WSR

1 - Share Your Kickoff

2 - Product Review

Create a new component with WSR

The process

01 - Kickoff (Request)

02 - Research

03 - Design & Test

04 - Review

05 - Spec & Jira Task

06 - Development

07 - QA

Looking for Answers?

Browse our articles to find the answers you need

If You Need New Component / Review / Found a bug