For my research, I jumped on customer calls with the Custom Support team to understand their needs and expectations, I analysed customer feedback coming from different channels like Zendesk, our Community Forum, Twitter, etc. I also analysed data such as the number of scenes created, the number of devices added in a Scene, the most used controls. From the research I've done, I learnt that customers were expecting something close to a WYSIWYG experience and needed to be able to customize both controls and pages of controls to make Smart Remote their main and only remote.

The main challenge in designing this feature was how to design the screen listing controls on the Smart Remote interface. From the research I've done, I knew customers were expecting a WYSIWYG experience but this feature was a big project so I also had to use native components or custom components already developed to reduce development cost. I first used cells to represent controls, and I used tabs to navigate through pages of controls as it is the same paradigm on Smart Remote.

Realizing this feature is quite difficult to use for a new customer, I started to improve celles to make the experience more visual.

After reviewing the mockups with the team, we decided to go deeper in the WYSIWYG approach and create custom components so I started experimenting with an accurate representation of Smart Remote layout and grid.

I needed to keep a light UI to be consistent with the design of the app, so I made an outline version of the remote, which also makes the controls stand out. For the page of inputs controls, we kept cells as inputs are listed in the same way on Smart Remote.

After validating the main screen, I designed the entire flow and made an interactive prototype in Figma to communicate with the team.

We also wrote detailed specifications in Confluence to address all corner cases and technical limitations. For example, for the first version released (beta) we had a constraint of 10 devices customizations per user. Writing specifications with engineers allows to rise this kind of problems and to address them in the product experience.

Here's a screen recording of the final product delivered, which includes additional screens like a popup alerting users about the beta version limitations or a walkthrough to help them understand the feature capabilities.

After launching the beta version, we started collecting feedback from users from our community forum, zendesk and other channels to learn what worked well and what needed to improve. I also sometimes participated in the community forum to help and educate users on the feature possibilities and future improvements.