Vision Direct

Vision Direct is part of Luxottica and it slowly migrated to their main E-commerce platform, which hosts a series of websites as David Clulow, LensCrafters, Pearle Vision, Spectacle Hut, Ray Ban among others.

So they needed a Design System Specialist to assist for component migration and restructuring, as well as some redesign of some features like prescriptions, payments, address saving, shopping bundles, reset passwords and account updates.

The work started with IT version, then UK, followed by all Vidion Direct markets like ES, FR, IE, NL and IE.

We worked in a fast-paced team along with a Lead Designer, Technical Director, Project MAnager and multiple copyrighters for each respective market.

💡

Because we were tied to a strict design system we’re wireframed directly with components, additionally detaching and creating mockups. As every project is differnet, this worked best for this specific project which reused all over gaian the same components for 7+ markets

Plugins used

Instance Finder - Gives Figma a much-needed feature: Backward search a component to see where is it used. Particularly good when restructuring a DS made by another team of designers.

Builder - Snaps an editable instance of a page with great accuracy, especially when grabbing multilingual content that fails with OCR methods and it’s too scattered for copying and pasting.

Lottie files - Synch animations made in AF in a cloud and generated GIF/MPEG assets ready for Figma prototypes

DS Housekeeper - Powerful reverse search for stuff like fonts, layer styles, colours and instances.

Table to Figma - We used this to populate components with data from excel docs

Button arrangement

The initial taxonomy was based on the old version of Figma, without variables so a good start was to group them into a one component called ‘Button’.

Price Components

As we created the Homepage and PDP pages up to seven markets we run into an issue of how to display prices on product tiles. Even if we had the price euro sign ⟨€⟩, the display was slightly different in some eurozone countries. For example in Ireland, the euro sign comes before the price with no space (similar to how pounds are displayed in the UK), the dutch (and BENL) version is the same but has a space between while the rest of eurozone has the sign.

Manually copying and pasting for each instance would have been intensive and would modify too much the components that would create issues in the future, so the realistic solution would be create variants of the product label section which is was already a component.

Updating the component over 477+ instances required a bit of planning, naming for the price was kept the same to match the current price and the extra currency symbol were deleted using the search and replace feature in Figma.

Original vs New Layer Setup. The new directories and text layers are highlighted in green

The result was a set of tiles that would easily interchange maintaining the edited price, while switching the currency symbol in the appropriate place depending of the market.

💡

* A note was created to push the component further by using the new variables feature in figma to create a close to realistic conversion between Pound → Euro by multiplying £ x 0.87 ** The decimal separator varies from country to country as well, it defied the purpose to separate the integer from the fractional part of a number, so after the component variants were changed, we searched and replaced the dots with commas or the other way when necessary.

Autosave

As we added features we stacked all of them into a page and split them into sections rather than a multitude of separate pages. However, one inconvenience was we had to create a logic of how these sections would be individually saved.

So we talked with the tech team and the best solution was having autosave on all input fields without the need to hit a save button every time. This required a thorough evaluation for all input fields and thinking over where signposting is needed.

What we’ve learned: Naming

We’ve made a set of rules when things are wrong before throwing the blame Figma, one of those was to check naming before something else. As design systems are two separate entities linked together the common denominator

What we’ve learned: Never leave a radio button alone

One issue that we’ve found when doing an audit over the journeys was that in some cases we only had one radio button, this defies the whole yang yang of radio buttons in general. As you cannot unselect once the instance is selected, better to use a checkbox component in that case.

This issue segwayed into rethinking the whole mechanics of the payment tiles

Payments

The payment system consists in one main payment (mostly card) method and the secondary ones. In previous designs were scattered over different market specifics, for example in the Netherlands the primary payment method was iDeal, an e-commerce payment system started in 2005-2006 by a consortium of NL banks. Same in France and Belgium with Bankcontact, these services lost market share as new Genz have more trust in giving credit card details as they manage their accounts via banking apps.

So the push was to push to the customers to use cards as much as possible, prioritising saving and gathering credit/debit card data rather than using third-party vendors. Also making sure that new financial services that offer post-purchase payments (buy now, pay later), like Klarna, Affirm & Sizzle.

The tasks were:

Set a universal system that would prioritise card payment first but keep the legacy vendors like IDeal and Bankcontact options open.

Create a seamless management system where a user can easily save and add additional cards on Vision Direct

Integrate third-party vendors like Klarna and Credit Mutuel

First-time checkout

When a first-time user gets to the checkout, or we don’t have any stored card in the system, we show the new card tile by default open, aside from the other 3rd party payment methods.

Recurring Visit

On a recurring visit, we want the least amount of friction or decision-making possible so we worked out the easiest flow possible considering the legal and technical requirements.

When a recurring customer is at checkout the card from the previous session is stored and shown as a preview (last 4 digits & payment network logo), once they accept the T&C’s the checkout is complete.

An example of a recurring purchase, the customer adds a different card than the one is saved

Multiple payment methods

As we tackled multiple markets one of the key differentiators was payment types as every country favoured a specific payment method.

🎓

What we’ve learned: Text Replacement vs Text Styles Although text replacement is a useful feature, sometimes it messes up with the text styles, removing the style altogether detaching a style from a text element whose content was auto-replaced. (as is Nov 2023). So we used to search and replace items manually in order to preserve styles.

The quantity field

We had a task to unify the product quantity dropdowns, which were initially separate and were able to order a different quantity of lenses for each eye. With this change, we sought to review the experience and see if there is any room for improvement as a matrix of dropdown input fields didn’t seem the best practice.

We went on the common variation that includes an input field with [-] and [+] buttons on the sides. The main reasons were:

To break the pattern, multiple elements of the same kind may seem repetitive and feel like a chore (even for us designers). A break in the pattern makes the elements more distinguishable and pleasurable to complete or verify.

The potential task for upsizing to more boxes is less of a hassle, reducing the number of clicks.

The option to use the input field and keyboard, beneficial especially on products that can be ordered in large quantities.

To prototype all the edge cases we used variables in Figma as we wanted to showcase how the component would really behave within the edge cases that we had. The main advantage of using dynamic prototyping in Figma is the access to the Design System and the usage of if then that & boolean actions.

With a minimum quantity of 1 and max of 8 boxes in the basket, we wanted to show how our buttons would switch from the ‘Enabled’ state to ‘Disable’ when the quantity reached the max and min levels.

Price would be dynamically calculated each time a user tweaks the ‘packs’ or the ‘boxes’ fields.

Be able to check and uncheck the ‘left’ and ‘Right’ checkboxes, which will turn on and off the respective input fields, retaining the selected value.

💡

What we’ve learned: Broken Components

As many projects you enherit all sort of stuff and ever so often everyone has a certain style to work with components. Figma like any type of software that becomes so stuffy and a swiss army knifes has retain different ways that work to acompass everybody.

When instances of components don’t work usually there’s an error in the design system, so normally you should go on the pipeline and check all namings and the instance matrix.

Naming is a big issue, even though Figma tries to solve this from their backend, so when glitches happen, it is worth going though every element and making sure all have at least some differentiation.

Handling delivery and billing address

As we prepared for the unified system over all markets we wanted to improve the overall experience. We worked out two pain points in the checkout, the billing address and how we manage payment cards.

Persuade users to change their password

For some technical reasons, we could not migrate the Irish users to the new unified platform without a password change. This process would be a one-time event per account and the concept was to make it as seamless as possible without any blockers or

Initially, a page was set in place that was based on the ‘Wrong Password’ template, featuring an ‘Alert’ banner with just a copy change. However, in testing, this didn’t go well.

“message error of the image below with the red background does not explain very well why the customer has to change the password”

“CTA/link on the message alert to distinguish it from the standard error message”

“Reset Your Password” ” as in design and not “forgotten password as in confluence?”

the landing will arrive into this second image below but has the field of email, it says reset your password but only the email is requested,

The key was to differentiate the “Reset Password” to the “Forgot Password” flow, make signposting less alertness and stick the email

A tailored page was created, without using the ‘red alert’ components like before pushing users to reset their password. We took patterns and ideas from the situations like when your password was compromised and we worked with copyrighters to make sure we’re delivering the right tone of voice.

So a new ‘Reset your password’ page was created that will appear once per user that never changed their password. The red alert bar was removed and a bunch of lines of copy were added explaining the situation as long as showing the email that is involved.

Main CTA: Reset your password will redirect users to the ‘Forgot your password’ flow, while keeping an option to go back to login in case they have multiple accounts or any edge case that may be around.

Restructuring Colour Styles in the Design System

One of the tasks was to adhere to a unified design system called ‘Crossbrands’, which has a unified naming convention according to the front-end token system.

Even if those shades look, in reality, this 4 yr old system was the result of two brand systems merged. The main issue was that lots of

Many colours were identical or too similar and over time different people assigned colours the wrong

The ‘Shade Gradient’ which was the cause of many of these issues had naming that was misleading

Lack of control over the text & background colours

We had more than 7 different styles for plain white (#00000)

Find, replace and merge colours

A bit of a tedious process was to reverse search colours and the first question is why would you need this. Well here is the point, large design systems in such big crossbrand organisation often witnessed a lot of merging and rebrand attempts, they never look like a ‘design system template’ from the figma community.

Aside from looking like you would football match strategy plan, this was necessary to plan which

Even if Figma’s ecosystem offers a lot of plugins, the process is not entirely automated. For example in this case the plugin can ‘see’ where a specific colour style is used and it has the option to ‘swap’, but that doesn’t change chronologically (as in Atoms first, molecules, orgasms).

If we run here the plugin scripts it will ‘modify’ all component colours, so when a change from the ‘Atoms’ is made the instances will not change as the script modified it. This tool makes a great assistant to navigating us and teleport to the right place and do the changes strategically.

The result was removing over 20 colour styles that were hardly used, defaulting into a solid set of colours that were according to the brand guidelines. This move not only helped developers reduce errors and maintain the front-end but also helped us designers with the everyday tasks, to assign colours seamlessly to new components.

Scanning each colour and making a chart out of how many instances were used

Create a strategy for what colours are duplicates (especially whites) and which are close enough to merge to the nearest denominator. We found that many shades were used solely by hover states and that wasn’t enough reason to hold one style.

Mockup over a new colour structure

Merging styles by reassigning the colours to each component manually

Deleting color styles making sure again they were not wrongly assigned by scanning the visual design styles via remote styles (this takes so long and it’s tedious)

Remaining styles to match the new naming convention

Adding up certain new elements like opacity styles and new colours

Splitting the white and dark into two styles by manually reverse search

Fiscal Code (Italy & Spain)

These two markets have a fiscal code with is optional however important enough to take into consideration as lots of people are using it, especially when buying med-related items.

The main task was to find a way to relocate the fiscal code in the account and showcase it in the checkout flow for confirmation. The main pain point was to understand the hurdles of the tech team while providing the best user experience possible.

For our presentation purposes, we will showcase the fiscal code for Italy, with a lot of copy bits in English. After the proof of concept was validated we translated everything into IT and ES. Swapping the Fiscal Code (Codice Fiscale) with NIF Code for the Spanish market

We created a widget

Route A — The user adds a fiscal code from the Account and then gets to Checkout where the widget is prepopulated.

Route B — The user has no Fiscal Code in the account but adds one while in checkout

A third category is the users that already have entered a FC/NIF in the system and they need to be updated to the changes that occur in their account

Migration

For the users who have entered a fiscal code in the system already, a way to signpost the changes via info bubbles.

Upsell a product from the basket

We worked out what products would have an upsell and this was mainly for business purposes, from the data of products frequently bought together. Not all products have an upsell tied with it and some require to go to a PDP page to choose the right lens prescription. This was solved in a couple of solutions we backlogged (see further below).

If we have a product in the basket and we want to upsell a contact lens, instead of going to the PDP, we have a quick view modal where they can choose their CL values and add to basket effortlessly.

If we have a lens in the basket we can copy the values of the current product in the basket.

Review and Improve payment checkout

Research some of the main shopping websites that use custom CMS’s from the UK, IT

One button to rule them all

Multiple Tabs

What happens when an user has multiple tabs open?

One often edge case for e-commerce is when an user has multiple

Dealing with expired cards (Checkout + Account)

1. Set Expiration Checks:

Implement a system to regularly check the expiration dates of stored cards. This can be done as a scheduled task running at regular intervals (e.g., daily or weekly).

2. Notify Users:

Send notifications to users about their card's expiration status well in advance. This gives them time to update their information.

3. Grace Period:

After the card has expired, implement a grace period during which the card is marked as expired but not yet deleted. A common period might be 3-6 months. During this period:

Notification Reminders: Send periodic reminders to users to update their payment information.

4. Automatic Removal Process:

Once the grace period ends, implement the following steps to automatically remove expired cards:

a. Identify Expired Cards:

Use a query or script to identify all cards that have expired and have not been updated within the grace period.

b. Backup Data:

Before removal, back up the data in case of errors or disputes. Ensure this backup complies with data protection regulations.

c. Remove Expired Cards:

Implement a script or automated process to remove the identified expired cards from the database.

d. Notification of Removal:

Send a final notification to users informing them that their expired card has been removed from their account.

Payment Form Redesign

One of my goals since I’ve joined the project was to investigate solutions over the payment forms which I found quite clunky and tedious to use. So we’ve conducted a research of

While it’s always best to enter the correct name, most transactions in the UK will still go through even if the name is incorrect, as long as the primary payment details (card number, expiration date, and CVV) are correct.

Handling J&J products that are not available overseas

Vision Direct main strategy is to have designated websites for each main market, but there’s always the possibility of shipping to places that have not a dedicated website like the UAE. The UK website allows users to ship to the emirates, however there;s a catch, some products are not available like in this case J&J products like Acuvue range.

Indeed we could just dim the Buy button if the user has a Dubai address in its account, but the main concerns were around regular UK customers which may work or live or go to the UAE ever so often. So here we have first time users (a) that use vision direct UK, or the ones They might have already a UK address saved, but in checkout they might decide to add another overseas address (b).

a) User doesn’t have an account, starts shopping on the UK website which shows all products by default, when entering the UAE address it shows that some items might not be available, show available alternatives.

b) User has previously checkout and has only one UAE address saved in the account, the PDP of the products not available will have the “Add to Cart” button disabled + an alert banner to explain the situation.

c) Mix of edge cases

Prescription ‘Wizard’

On mobile due to the lack of space we had issues with the dropdowns, users reported that the text was quite small and the list quite narrow. Prescriptions on eyewear are a set of positive and negative values from 0 to 15, depending on the availability of the product. Generally are displayed in two columns ‘Plus’ and ‘Minus’ where users can quickly recognise and select their prescription.

The ideal solution would have been the native app selector, however that’s only available for apps, and the web selector looks like a tall list that splashes all over the screen.

On the short run, we redesogned the tables to

Soon we discovered that we ussually have a set of 2-6 dropdowns which a user needs to open-close and reopen again

The Login Issue

More than often something like a login screen would go unnoticed as we may just drop two input fields and one (or two) buttons from our design system and that’s it! Well that’s not how it goes in practice.

As I was been tasked to improve the ‘Reset Password’ starting jouney, more exaclty using the same email field for both ‘Login’ and ‘Reset Password’, I’ve noticed that we have a sort of Input Field Validation mechanism, which is not time based as I would expected. It works by clicking anywhere else, including a button, which causes a situation when a user needs to click two times on a button in order to proceed futher. One to validate the field that itself will enable the button, then when a button is enabled, click again to proceed or in this case to log in.

The performence of the backend to receave a certain amount of queries, so a query was set to be triggered by an outside click. So we agreed to set a rule:

If we ought to use in-field validation == we use it time based (after 1s) and we don’t use any buttons and we show a snackbar to confirm the auto save

If we do need to use buttons, we keep them always active and the fields will have validation on button trigger only, which will result showing Error states.

Archive don’t show

BONUS: Changing the Twitter Logo to X

One of the most weary yet exciting tasks was to finally change the Twitter logo into X.com, changing all the multiple elements where Vision Direct showcases its social media presence, like footers, navs and email components. To get everything right we composed an elaborate strategy for this task as follows:

💥Add the new Twitter/X logo in SVG form to the same Vector Network shape as the old icos uses. [ ⚠️ Adding a total new shape will not update the colour, as the icon was used multiple times with custom fills ⚠️ ]

💥Renaming the file from icon_social_twitter to icon_social_twitter_x, keeping the previous name to be easy to find by everyone ☺️

💥Checking a series of scenarios where it was used to see if all gone correctly. Of course it did!