Address validation pattern

Project summary

Please note: this is only a summary of the project. More detailed information and visuals are left out due to copyright restrictions. Feel free to reach out if you wanna know more!

At Viking, for a long time, addresses entered by customers were not validated by the front-end, resulting in many mistakes and staggering expenses from returns because of faulty deliveries. Also, because of this, the database was cluttered with faulty addresses. The plan was to start validating all addresses, like many competitors were already doing, so that these errors and extra costs could be avoided. For this, Experian, an API with an address database of almost every country, was chosen. A year before me, another designer already put some work into this. I was able to pick it up and finish the Address Validation pattern.

I first put some extensive research into understanding address structures of different countries. Viking is operating in 8 countries and each country uses a different address structure, like a different postal code, the order of facets (first house number, then street name, or vice versa), but also what people are culturally accustomed to. I also did some extensive testing with Experian’s API to better understand how it validates addresses.

Based on this research, I was able to design a pattern that accommodates the address structure of each country and enables users to find their address as quickly as possible. A “one size fits all” solution was not possible due to the differences in address structures and the way Experian handles validation per country. I defined 4 form layout variants with which every country could be covered. Because of this modular setup, the overall pattern behavior could stay the same.

After finishing the pattern design, I started adding documentation of the pattern to zeroheight as part of our design system. The documentation includes detailed information about the usage of the pattern and an overview of the different variants per country. It also includes related sources and a research section to explain why certain choices have been made. My pattern designs and documentation were handed over to the developers for implementation in our shop. I worked together in close collaboration in a multidisciplinary scrum team for support of the implementation.

The assignment formulated:

"Design an address validation pattern that accommodates for the address structure of each country so that our customers can enter a valid address and faulty deliveries and extra expenses can be avoided."

Working with the scrum team presented quite a few challenges. The team leadership decided to divide the pattern implementation into several iterations, which resulted in a half-finished pattern being put live each time. This resulted in negative feedback from clients and colleagues and also towards us as a UX team. Eventually, with many iterations, we managed to complete the definitive version. Although supporting the development of my pattern was quite the challenge, I’m still very proud of the result. The pattern has a positive impact on stored addresses on the database, the amount of faulty deliveries and most importantly, the user experience.

Hit me up if you want more details and visuals of this case!