Search this site
Embedded Files
shirmeir
  • Shir Meir Gannot
  • ✉️
shirmeir
  • Shir Meir Gannot
  • ✉️
  • More
    • Shir Meir Gannot
    • ✉️

⮐

WIX.COM / Editor x

Defining UI & UX guidelines for a core element in Editor X

I joined the X editor team at a time when they were working to align with the Wix Design System, which was my previous team. Up until that point, the product had been developed quickly and many compromises on design consistency had been made. 

THE PROBLEM

There were no standards, rules or specifications of what can be the UI content of one of the main components in Editor X - The GFPP (graphic floating property panel), which presents the possible actions  for every on stage component in the editor. It was necessary to create guidelines that clarified the purpose of the GPFF in the user experience and set some ground rules for the UI to meet those needs.

Wix`s Editor X with a Button component on stage

RESEARCH

I tried to discover as many of the current use cases as possible (that were designed by various UX designers over the course of two years). The challenge was that editor X has more than 200 on-stage components separated into about 50 types, and Each component´s GFPP panel was defined by the designer that created it.

Due to the overwhelming number of variations, it was decided to start from 6 main components that are fundamentally different from each other. I started mapping those components´ GFPPs in their different states, seeking repeating patterns.

Some of the common GFPP actions

MAPPING

We created a map of the common GFPP actions. Out of this map, we could recognised actions that were similar and could be combined under one use case. In order to ensure clarity and logic in the new system we was designing, the use cases had to be broad enough to encompass several actions, but not too broad (for easy application).

Parting the actions to main groups.

CASE STUDIES

After shaping a few different systems, we tested them on real flows and components, in oredr to determine whether they worked.

The question was - if we designed a GFPP for a certain component according to this set of rules - what would it look like?; Then, by showing the different options to colleagues, I was trying to see which system was creating the best GFPP´s (Those that had the best value for the users and were most intuitive).

One of the flows I created to test the hypothesis (Figma prototype).

DELIVERY

The tests we performed resulted in the understanding that while all the offered systems had issues and lacked certain features, there was one system that allowed the most flexibility and had better outcomes. I presented this system to stakeholders, sharing the case studies and tests and with their blessing, created the usage guidelines for UX designers to use when creating GFPPs in their product flows. The guidelines are now gathered in an article, used by over 100 UX designers in different groups in Wix.

Part of the article I wrote of the UX & UI guidelines,describing the usage of the GPFF in Wix´s Editor X in stage components.

Key takeaways: The value of extensive research and mapping. The importance of communicating my solutions through examples especially when defining ux rules behaviours.

Next project

 

Google Sites
Report abuse
Page details
Page updated
Google Sites
Report abuse