Kickoff is the start of a project before the process begins. At this point, it is important to inform all parties before the PM has started working on the spec to allow all parties to express their views and to get focus on the goals. At this point, it is important that all parties get the opportunity to do minimal research to allow the PM to get as broad a picture as possible about the product and needs.

Who:

Mandatory: PM, UX, PCD, UXR, CCE, DEV, QA, A11Y, SEO, P13N, OPS, PLTF, BLC, COR3, CRV

These people are necessary to create full product definitions.

 

Also mandatory: PM of each relevant external dependency

(typically from: Editor, Wix Data, Media Manager, Corvid, Core3, Editor X, ADI)

 

Optional: KB-TL, CRVD-W-TL, CRVD-XMPL-TL, COM

These people are necessary as part of the release process.

 

Also optional: SUP, BA

They monitor the product post-release.

 

Also optional: PM of internal consumers (typically Wix Forms and WxW projects)

PM to set up this short meeting and inform the team about the new product, before he start working on this product (before product 'tractor').

Goals:

Outcomes:

Work with this kickoff template for every product (duplicate the file)

PM: After the Kickoff meeting, establish 'To Do' list for this project, use this template (duplicate the file) and share it with the team:


Next Step: Research if needed

The goal of the research is to collect any information that is helpful to decide on the product definitions and scope.
It should not be confused with research aimed at prioritizing our projects backlog. This should be done on a regular basis and precede the kickoff of any project.

Who: PM, UX, UXR, PCD, DEV, CCE, BA

Before you start the research, work with this template (pls duplicate it) and answer on these questions inside this doc.

Goals: 

 

Example for research outcome can be found here:
Note: The research depends on the size of the project, the knowledge we have about the product and our ability to complete gaps. Not every product or feature requires thorough and extensive research. The goal is to fill in gaps that we don't know about.

Tractor is a common term in our Wix culture while we start to work on a product. The tractor is a unique phase for the PM. 

Here is the Wix way for product tractor:

It is recommended that business analysts who understand the user requirements, create a basic tractor and then work with designers to further improve the wireframes (next phase).
For more examples, see this doc.

Who: PM (UX, UXR, & PCD if available to help)

Responsibility: PM

Goals: 

Wire framing is a way to design a product at the structural and functional level. A wireframe is commonly used to lay out content and functionality on a page which takes into account user needs and user journeys. Wireframes are used early in the development process to establish all details structure and functional of product before visual design is added (presets).

Wireframes should be used early in a project to get manager approval on the layout of key pages/products, interactive, functionality and the navigation. This will provide the project team, specifically the designers and developers, confidence in moving forward. Wireframes will also save considerable time and money in the testing and amends phase later in the project. Working with wireframes may be a collaborative effort since it bridges the information architecture to the visual.

Wireframe is our spec for development. We write the product behavior for details including how the design settings (CSS properties) will work for each component. We are currently defining how we make the component accessible to the user who builds the site (Editor side include on stage & settings), and how it will affect the users of the site it is building (UoU). In performing this wire framing we do not provide full design presets, but only the settings to achieve the first user goal (site builder).

Note: UX designers & Content designers have different role in Wix. to read more about the role, see here. However, we believe in heterogeneous teamwork in which anyone can improve the product by early collaboration between team members. Currently, all interactive and functional for product definition will be based on the UX Guild methodologies unless otherwise defined. All the research and design materials for content will be based on the Studio design Guild unless otherwise defined.

Who: UX & PCD
Responsibility: UX & PCD
Goals: 

Outcomes:

Use Wireframe template:

In the wireframe we cover these subjects as specification in each component:

Example for Wireframe template:

Defined in parallel to the Wireframes.

Wix is an API-first company. Every new product is expected to have an API. The API should be defined as early as possible in the lifecycle of the product.
Editor Elements have Corvid APIs under $w.

The Platformization team is responsible for reviewing every API, and have a well-defined process for it. The reviews are tracked on their Monday board.

Who: PM & Developer

Responsibility: PM

Goals: 

Outcomes:

Examples for API spec:

Who:
PCD, UX, UXR
Responsibility:
PCD, UX, UXR

Content Designer and UX Designer work together to bring our product to life by visual, styling, typography, spacing, grid, sizes, layout and the whole user interface based on the Wireframe and the prototype (if exists).

Note: The content designer in the responsible on the component style and presets for UoU environment design spec. The UX designer in the responsible on the component environment by edit it in the editor. Both are together responsible for the behavior of the component.

Goals (for presets & panels): 

Outcomes:

Who: PM, UX, PCD, OPS, + PM & OPS of each external dep

Responsibility: PM

Goals: 

Outcomes:

Example for timeline we are doing for each product separately to make sure all the teams are involve in the product, will meet the timeline with commitment:

Who:
PM, UX, PCD, UXR, DEV, OPS

Responsibility:
UX, UXR & PCD - Have all filled specs templates organized in one project.
PM -  Define the Jira tickets with the relevant specs and send it to devs. (see here how to work with our Jira board)

Goals: 

Outcomes:
Epic Jira ticket should appear with all links to spec. (Product spec, Wireframe, Zeplin, link to source files in drive and any source as needed. Also to subscribe all team members who are working on it (Jira).

Who: QA, PM, UX, PCD, UXR, DEV
Responsibility: 

QA, PM, UX, PDC, UXR, DEV, OPS - All departments are responsible together for testing the product, each in its own field. Communicate and fix problems to meet quality and product timelines.
PM - Prioritise bugs according to product timeline.

Goals: 

Outcomes: