The way we customize
How rethinking the way we enable full code customization of our end user’s flow changed the way we approach brand customization.
Summary
As part of the Product Design Team, focused on creating a seamless experience for the configuration and customization of Auth0 features, one of the flows we worked on is the login widget customization.
This project started as part of an exploration to improve the experience of customizing the login flow using CSS for the widget and HTML for the background with the amazing Javier Centurion, Principal Engineer at Auth0. Our initial goal was to create a playground that would make the customization process with code easier.
So what happened within the process, and why did we put together a no-code customization tool? Well, that is what we are going to try to unravel in this post.
Full-code
We have an end-user login experience called “Classic experience” that uses JS and is customized by editing the HTML. Then, we have another end-user login experience, called “New Universal experience,” that does not use JS and cannot be easily customized. In both cases, you can change the primary color and the logo through a configuration without code.
From a functional perspective, the New Experience has much better support for Localization, WebAuthn support, a better MFA experience, support for Organizations. However, it has less flexibility regarding customization. While this is good as it makes it a more secure experience, at the same time, applying your brand branding is not so simple.
To solve this problem, we had two approaches at the product level. CSS customization and background customization. This is the starting point of this story.
Customize has the complexity of how to visualize what one is editing. In this case, it is not as simple as it sounds. Therefore, during our ideation process, we decided to explore the possibility of providing a sandbox.
Timeline full-code exploration
User testing
User Testing means that we can target the real problem right away, so we don’t spend time ‘fixing’ the wrong thing. We try to carry out something as early in the project cycle as possible and as often throughout.
In this case, we carry out several internal tests with employees and customers to understand how users would use this tool and gather insights on user expectations when customizing the widget. We found the following issues regarding the tool:
- Not all developers are comfortable customizing the CSS.
- Participants tried directly editing the HTML.
- Participants didn’t understand what was supported and what was not, so they tried hacking the obfuscated classes.
In an attempt to solve the CSS issues, we started to obfuscate classes. Which, while avoiding customizing components with the risk of breaking, made the situation more complex.
We wonder what we can do to gradually move forward with a customization process without putting our customers at risk.
Our approach
What can we do to give our customers the possibility of customizing the login experience without the risk of breaking the widget?
To solve this problem, we knew that we needed a more holistic solution. After a lengthy discovery process, we decided to explore a no-code solution that would allow us to create an overlay over our current CSS while improving the CSS structure.
Timeline No-code exploration
User testing round II
After exploring the idea of integrating no-code and low-code on the same tool, we did another round to answer the following questions:
- Which are the things that are a must-have for this tool to be valuable/usable for customers?
- What are the things that they were willing to trade-off?
- Gather insights on other functionalities that the tool was missing.
Some of the main issues we saw were:
- Companies seem to vary widely on how often they customize UL: some set it and forget it, others seem to change it often.
— The desire to have/save multiple different “themes” and be able to apply them was consistent throughout. - Logo, colors, fonts, and backgrounds seem important elements for customized branding.
- Participants had a strong inclination to interact directly with the preview instead of combing through the UI to find the relevant field.
— They loved the WYSIWYG functionality but found frustration trying to figure out what controlled what (versus clicking on the thing they wanted to change).
— Participants only discovered you could edit content when they tried to change the language. - It’s not clear that there are multiple screens available and that changes in one impact all of them.
— Overall, discoverability was very low for the tool.
Our first MVP
Although there were many things to adjust, we validated that a significant % of customers could solve their problems of customization of the new experience through a no-code tool with a certain level of flexibility. We started by defining that for our first MVP in the dashboard; we were going to need the following things:
- A color palette that allows you to change the color of all the components at a generic level.
- Add a logo, change the position and size
- The ability to change the corner radius and border weight of the components.
- Adding a font, and modifying weight and size
- Underline option for links
- Modify widget layout and remove the shadow
- Basic customization for the background
We decided to leave the background low-code integration for the following iteration since it has greater flexibility to be customized using HTML directly.
Some thoughts
- Prototyping helped us envision the final tool and assess risks before implementing it in the Dashboard.
- No-code tools are simpler and straightforward when accomplishing some sort of task like customization.
- By developing a tool targeting non-technical people we are also simplifying technical people’s work and reducing the effort.
Coming next…user testing loop and tool improvements.
