As explained here, Editor Elements can be built and delivered using different tools & technologies.
This article only describes the process of building an Editor Element in React and distributing it as part of the built-in Editor ecosystem (consisting of the Editor, Corvid, Content Manager, Media Manager, Multilingual and more).

This process does not cover:

Building a composite Editor Element as an App Builder widget; neither does it describe how to build an App Market third-party app.

We refer to this type of Editor Elements as "Native". We believe our process would have turned useful for these other groups as well, so we are therefore documenting it.

During 2020 we would like to introduce an additional process - for a contribution model in which another group builds a Native Editor Element and our group functions as a guide and gatekeeper.
This new process will be based on our existing process, as well as on our experience with contribution models in the world of Design Systems.

Important!

Development a native component requires review of components team, from kickoff phase to post-development.

Before reading about our process from the moment it's been decided to start a project, you may wish to read about how we decide what projects to work on.

The process in steps

Here are all stages of our process, with an emphasis on when, who, how and what

This process is followed in full when building a new Native Editor Element from scratch.
It may be followed in full, or in part, when adding new capabilities or when fixing an existing element.

01 - Kickoff

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)

Responsibility:

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:

Understand the goal and underlying motivation
Define high-level scope
Describe the timeline
Meet the planned and agreed 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, what should be their deliverables, and when these are expected - including external dependencies
Rough time estimations by each member

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

02 - Research

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

Responsibility:

PM - Lead and direct the research efforts. Participate in all efforts and focus on the functional aspects of the user needs, the market, and existing solutions and workarounds
UX & Content Designer - Lead these efforts: User expectations & needs, UX solutions and patterns, Internal Consumers and Design Systems, Competitors Analysis and usability issues. Web inspirations and Trends, content & layout.
Dev - How do the capabilities and limitations of the Editor ecosystem affect this product?
Support - Lead and User Voice effort

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

Goals:

Gather as much information as is helpful to decide on the product definitions and scope.
Analyses all this information to obtain a broad overview of the user needs and the market.

Outcomes:

Each person presents his/her findings, insights and conclusions to the team.
Raw Material and Analyses:
- User Voice Analysis: Support Tickets & Calls, Corvid Forum Posts, Posts on Social Media, previous analyses conducted by other team (e.g. Editor or Corvid)
- Internal Consumers: Platform Apps (e.g. Wix Forms), WxW projects, all Design Systems (but most importantly the on-stage one)
- User Workarounds: Corvid, HTML Element and others
- Web and Web Trends Analysis: Studio and in-house
- Competitor Analysis
- Element History: if improving/fixing an existing element or if previous work was done
- Similar Editor Elements
- Data Analysis: mostly on feature usage in an existing element, or similar elements

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.

03 - Tractor (product definitions)

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:

Obviously you need to draw all the product screen
Obviously it is best to draw them in the order the user see them
Obviously the best way to start is by drawing the screens in tractor mode
Obviously some screens are very easy to draw and they should be drawn first
Obviously it is best to write comments upon this collection of screens

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:

Define the scope, and why this is the exact scope.
PM Draws and describes a rough product tractor, including features and all use cases.
User flows include descriptions.
Some tractors can be broken down to first version and future version, if scope is too big.
If this product includes integration, then PM should also create a flowchart.
Meet the planned and agreed upon release times

Outcomes:

Unique link to the product definitions.
Team members clearly see the scope and the requirements of the product.
External dependencies see it as well, and can raise red flags.
Each member defines 65% estimation (how long it should take)
External dependencies should give an effort estimate and a delivery date estimate.
Development of server side and logical mechanisms (if any) can start.
Analyst can define KPIs and BI events

04 - Wireframe

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:

Draw the flow, layout, interaction and behavior. Present how the user will achieve the product goal.
Cover all cases (+edge) include all devices (Desktop, Mobile, TV etc.), and displays required capabilities for the dev. team
breakdown all parts by behaviors, functional and interactive and maintain these settings throughout the product use to create consistency and development efficiency.
Define all the properties and values for the component (colors wiring, paddings, spacing, size and layout).
Meet the planned and agreed upon release times

Outcomes:

Unique link to wireframes (from now and on this is will be the final unique link to the product definitions, this link will be updated as long as needed).
Each band member define 100% estimation (how long it should take now we can see the whole scope of the product)
Internal Consumers can provide feedback
Dev team can start developing the infra and the fronted layout (before style & design).

Use Wireframe template:

The Wireframe template is a standard checklist collection to make sure we cover every subject and aspect in the product. Especially to create transparency and cover many topics that can be reviewed from all teams involved in the product.

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

Overview
Editor Experience
Viewer Experience
A11y
Base UI
SEO
Data Binding & Corvid
Add Panel
Site Templates
Support
Marketing
BI Events
Right Click
App Builder
Wix Forms
ADI abilities
Multilingual
Translations
Browser OS Specific Behavior

Example for Wireframe template:

04A - API specifications

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:

Define the Corvid API of the element, as well as any other API that needs to be updated.
Get a green light from the platformization team.

Outcomes:

Corvid API specification document (see examples).
API Status changed from "Corvid Review" to "Dev" on the platformization Monday board.

Examples for API spec:

05 - Design & Style 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):

Meet the quality of the design, maintain the unique and uniform language, and wrap up the complementary design experience that meets all challenges such as different skins, many resolutions, different devices and colors wiring.
Meet the planned and agreed upon release times

Outcomes:

Visual mock-ups with the final updated design, with resolution braking point & devices (link).
User flow by design (If needed)
Unique link to design specs (such as Zeplin etc.)

Checkpoint: align with external dependencies

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

Responsibility: PM

Goals:

Verify all external dependencies understand exactly what are their tasks
Obtain final time estimations from all external dependencies (now that specs are final they should be able to provide accurate estimates)
Transfer responsibility of meeting the deadlines to the Operations Manager

Outcomes:

Timeline of integration milestones (Use this template, this is the same spreadsheet from step 01 - kickoff)

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:

08 - handover for development

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:

Allow developers access to all up-to-date and information, assets and specified contacts for any questions or clarifications.
Meet the planned and agreed upon release times.

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).

Development - Done

QA

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:

Check the code and structure.
Check API by the spec.
Test performance.
Test with real data.
Simulate a real user experience / flow according to the UX & Design spec.
Create and test edge cases.
Go over all settings panels design.
Test all settings.
Check both edit mode and live mode behaviour. (Desktop & Mobile)
Check the product on all devices.
Check A11y definitions.
Check help articles.
Compare presets to specs.

Outcomes:

Create a QA Document.
Assign tasks to fix bugs.
Improve the product before launch.

Release to Production

Role list

PM - Product Manager
UX - User Experience
CPD - Content Product Designer
UXR - User Experience Writer
CCE - Customer Care Experts (also responsible on support tickets)
DEV - Developer
BA - Business Analyst Experts (also responsible on BI events)
QA - Quality Assurance Experts
A11Y - Accessibility Experts
SEO - Search Engine Optimization Experts
OPS - Organization of planned activities
P13N - Personalization Experts
PLTF - Platformization Experts
BLC - Blocks Experts
WD - Wix Data Experts
CRV - Corvid Experts
COR3 - Core 3 Experts

Looking for Answers?

Browse our articles to find the answers you need

How to work with the Editor Elements team?

External

Internal