Wix (Product Design Internship)

Overview

During my time at Wix, I was a product design intern at the Wix Style React design system team. To gain maximum exposure, I worked on various tasks and projects: 

• Storybook documentation

• Research

• Usability Testing

• Figma component library maintenance

• Icon creation

• QA

• Component definition

• Template creation

• Helping designers from other teams with any component/Figma related questions

I also spent two weeks working full-time with the Wix Blog team. I was responsible for redesigning a page and creating a flow/solution for new product functionality. Unfortunately, due to legal reasons, I'm not able to share any details about the project. However, I have to say that I enjoyed working there immensely. Even though the methodology is the same across the whole company, the type of work at Wix Blog was different from what it is at the WSR design system and, that left a big impression on me.

Role

Product Design Intern

Timeline

6 months

 Component QA

It is worth mentioning that I joined Wix during their transition from Sketch to Figma period and my first post-onboarding task was to conduct QA on the existing components in the WSR Figma component library. To administer QA in an organised and orderly manner, together with another intern, I had to come up with a list of assessment criteria that were based on WSR design guidelines: 

• Text Styles

• Color Syles

• Variants' order

• Properties' order

• Resizing behaviour

• Pixel Perfection

• Layer Names

• Emojis

• URL

• Description

Once I had a spreadsheet with the criteria ready, I could go ahead with the QA. 

Takeaways

Working on this task was a brilliant way to get familiar with the component library and help the team pinpoint any inconsistencies or bugs. It was crucial to give the components a "test drive" before the libraries' initial release to minimise help desk services.

Defining a component

Further down the timeline of my internship at Wix, it was time for me to define a component. The Sortable List component had a working mechanism called Sortable List Base. However, its UI solution and functionality haven't been determined. Therefore, it was up to me to decide how the component would work.

I began by studying the references and identifying what should go into this new component's scope. This step involved looking at how competitors handle their drag and drop components and what's in use already within Wix verticals.

I then defined the scope by making some low-fidelity sketches and sketching things out to help define what properties and functionalities the new component will cover. 

It became apparent that there would have to be two instead of one Sortable List component. The reason for that is because our users (Wix employees) use Card-based and Table List Item-based Sortable List components in their designs.

Takeaways

Designing this spec was a complicated yet exciting task. Following the conducted research, I had to come up with appropriate properties. But I also had to learn along the way about accessibility, in particular about the way screen reader works and how the component should correspond. This process involved working with the Wix accessibility guru to reach a solution. Moreover, defining animation of the element was new to me too. To understand how to define it, I had to understand its basics using an animation tool - Principle. In addition, in collaboration with the UX Lead, I worked on re-creating an improved version of the Spec Template, which allowed me to get friendly with Figma and learn how to work with the auto-layout and variants features.

Read-only State in WSR Form Components Research

WSR library is based on HTML standards, where input components have a read-only state, but other elements don’t. Also, WSR has its design language, which differs from native HTML elements. Therefore, we needed to understand if adding a read-only state for all form elements would bring any value to our library.

Research purpose: To evaluate the read-only state in WSR form components.

Internal Research

I began the research by comparing WSR form components and seeing which ones have a read-only state. Once I identified the elements with a read-only state, I could assess their behaviour and document them in a spreadsheet.

Findings:

• Cursor inconsistencies - read-only components cursor behaviour isn’t uniform

• Consistent background colour behaviour

• Certain components do not open an options list while others do

• There is a number of form components that don’t have a read-only state for unknown reasons.

Competitive Analysis

After completing internal research, it was then necessary to look at component behaviour in competitor design systems. Comparing components across ten design systems showed me the differences and commonalities concerning WSR form components. Once again, I assessed competitors' components' behaviour by a set of criteria documented in a spreadsheet.

Findings:

• Identified whether the the focus state is used

• Found out whether competitors have a hover state for their read-only state components

• Confirmed what cursor type most competitors use

• Confirmed background colour behaviour

User Interviews

Desk research gave me a lot of valuable data and material for insights. However, I wanted to hear from users with first-hand experience with read-only states in WSR form components. Luckily, I was able to find which projects had read-only form components in use. I could then contact designers from those teams and arrange 15-30min meetings with them and talk about: 

• The context in which they use read-only state in form components

• Reasons for why they choose to use a read-only state instead of a disabled state

• Their and their users' expectations of how the read-only state should work

Speaking to 4 designers gave me a clear picture of the main reasons why WSR users use the read-only state.

Insights and next steps

In combination with user interview and desk research data, I came up with these insights:

• Identified form components options list consistency issues

• Identified consistency issues with form components

• Identified the main reason users use the read-only state

• Identified an issue with hover state

Once I had defined the research insights, I could focus on the next steps. I came up with a set of recommendations/tasks that would resolve read-only state related issues.

Takeaways

There’s something about conducting research that I love in particular. If done correctly, every step brings great satisfaction, from creating a plan to working accordingly and meticulously and gaining a clear vision about the problem and the necessary steps that could lead to great insights and potential solutions. Getting to interact with real users with real problems was awesome - an experience that taught me how to conduct the interview and ask the right questions.

 WSR Component Findability Usability Test

It is a known fact that communication between designers and developers can always be improved, and it’s no different at Wix. Both designers and developers use the WSR design system, and it is sought after that all employees would be able to use it most optimally.

An internal effort for an improved version of a certain aspect in the design system required conducting usability tests to see how developers find components when presented with a UI layout in a Figma file.

Usability Test Task

I prepared a task defined by another designer at WSR where participants had to identify three components placed within the red borders. The component on top was easiest to locate and vice versa for the one on the bottom of the layout. The difficulty was defined by how deep the user needed to dig through the layers to identify the component correctly.

• Marketing layout (top)

• Statistics Widget (middle)

• Timetable (bottom)

Participants

I ran the usability test with six front-end developers who had experience using the WSR design system. Four of them were experienced users, and the other two were beginner/mid-level users. All of them shared one commonality - ~1 month of Figma experience. It’s worth noting that I observed the first two usability tests in order to learn from the process. Having an example of how the tests need to be carried out was helpful indeed. I felt confident and comfortable enough to carry out the remaining four by myself.

Usability Test Findings

Marketing Layout:

• a large portion of users found the name of the parent component in the inspect panel and proceeded to look it up in the storybook.

Statistics Widget:

• 50% of users recognised the component

Timetable:

• the majority of users saw the parent component in the inspect panel and proceeded to look it up in the storybook, while a couple could not identify it at all

Figma layers:

• users had issues when it came to navigating through Figma layers

“View Documentation” CTA:

• users didn’t use the “View Documentation” button

“Figma for Developers” guideline:

• users didn’t know about the “Figma for Developers” guideline

I documented all of the usability test data in a spreadsheet, of which I had a printed paper version during the tests to take notes in.

Insights

• Users struggle to identify the components due to the lack of awareness about Figma layers

• Users recognise components incorrectly

• Users don’t use the View Documentation button because of its unclear origin

• Users aren’t aware of Figma for Developers article’s existence

The usability research helped determine what actions need to be taken regarding larger projects ahead. Essentially, it enabled us to understand our users better and design sounder experiences for them.

Takeaways

Conducting usability tests was great fun and super insightful. I learned that there’s a fine line between being in control of the test and losing that control. As participants would sometimes go off track, I would have to maneuver the test in ways where I would still be able to get valuable data and help the participants in a way where I wouldn’t be doing the task for them. Therefore, unexpected things can happen, but as a designer, I can reduce that uncertainty by preparing for the test as much as possible and keeping a cool head.

In the video above you can watch the UX Lead speak about the usability test. Section: Testing your design system with developers. Minute: 14:33

Figma component library maintenance

A design system is a living organism that needs to be maintained all the time, especially if there are over 150 components. Some components in Figma will inevitably have issues that need to be addressed, and therefore, the component must be fixed or updated whenever such a case arises. Component maintenance has taught me how to work with variants and auto-layout efficiently.

Component Documentation

Clear documentation of components in the WSR Storybook has been one of the key projects during my time at Wix. The job required writing content that is both understood by developers and designers. But for others to understand my written content, I had to understand the component and its behaviour thoroughly. This meant that I would investigate where and how it's being used; Study competitors' approaches; Communicate with developers if in case there were questions that I wasn't able to find answers to; Adhere to guidelines and rules like: 

• Always starting to write a description with a verb

• Listing properties from least to most complex ones

• Utilising component elements to communicate available prop values

And finally, write everything up clearly and concisely using the correct vocabulary that was shared amongst the team to maintain consistency across all pieces of documentation.

Takeaways

Writing content for WSR Storybook has made me a better writer and developed my ability to deep dive into a subject matter and cover all of its details. In the past, I had experience writing content for a video game where I had to stick to a specific tone of voice, but I was essentially left to my own devices. Here I had to learn how to produce uniform content that was in sync with other designers on the team. This experience has taught me how to be a better team player, work under a clear set of rules, and remain within those boundaries.