Every so often, I am tasked with a project that forces me to step outside of my comfort zone and tackle something I wouldn’t normally consider, for lack of a less corporate term, “in my wheelhouse.” Sometimes for us devs, putting on our how-do-real-users-think hats can be a little scary because it’s opening up to the possibility that we might have been wrong the first time. A little over a year ago I had to do just that, as smartURL faced an issue that required some creative thinking — part of our core UX was downright confusing.
To give a bit of context, smartURL is a geo-aware link building platform. It allows for you to take a link and redirect someone based on a number of criterion, but most often based on their geographical location. The typical use case was for iTunes releases: getting people to the correct store for their country so they could make a purchase in as few clicks as possible. This concept was later expanded upon to include the option to build a landing page that promoted an album, as well as blocks that link to various retailers, also in a geo-aware fashion. We’ve branded these kinds of pages as “Pivots”.
So, what was the problem?
Individual retailer blocks are able to be configured to know what destination to bring users based on their country. If the creator put in an iTunes URL into the field named “Default URL,” the system will do its best to generate the iTunes URLs for the remaining countries based on whether it is able to find that album in each store, or at least provide an artist’s profile as a fallback if nothing was found (we call this process “expansion”). Here’s a visual:
The expansion process, while a big time saver, did cause a question to come up quite often. “What if someone from another country not in this list clicks the iTunes button?” This was an extremely valid concern, and one that was hard to dispel in only a few lines of descriptive text next to the main content.
The answer was that these URL variations, called “country URLs”, where actually overrides for whatever was placed in the “default URL” field. If a user’s location matched a place on the list, they will be brought to that URL instead. Otherwise, they go to the default location.
However.
One sneaky detail about a retailer that is not immediately obvious in the above screenshot is that they actually have their own internal list of countries that determine where it gets served. If a user’s location does not match on a retailer’s internal list, the retailer block simply does not show on the Pivot page.
For example: Pandora, pre-getting-acquired, was only available in the United States and Puerto Rico. Line Music is only available in Japan and Thailand. Amazon Music’s free version is available in the US, Canada, and Mexico, but not Ireland and Greece.
As you can see, there were not only concerns about getting people into the right places, but also making sure there is even a place for them to go at all. Our UI tried to half explain this in a way that really only made sense to the people that built it, while hoping that users would eventually “just get it” after trial and error.
Well, turns out they didn’t “just get it”. In fact, a lot of employees didn’t “get it” either and would frequently ask me to explain to them what was going on, so they in turn could explain it to their clients. There was a severe disconnect between “what countries this retailer will show up in” and “what URL will a person in this country go to”.
Eventually, this question, or one close to it, would start coming to me more and more frequently. One team in particular, who’s clientele is predominately European and Central American companies (named “Team International Love”, or “TIL” for short) were e-mailing me on what seemed like a weekly basis. Before long, I wrote up a template for them to copy and paste to their clients so they wouldn’t need to ask me how to explain the difference between a country URL and a retailer’s country as often. It was at this point where we realized that something that required this much effort to explain had clearly been a user experience failure.
At this point, something needed to be done. If people who worked here were this confused about what was going on, how would a client wanting to use our tool feel?
The first step my manager and I did to tackle this problem was to ask for the expertise of our new design director. He had just been brought into the company and had minimal experience with smartURL, but lots of experience with building good UX. So, we set up a meeting with him in a conference room, gave him a crash course on smartURL, and then asked “why do you think this isn’t working?” The shellshocked look on his face from information overload was very telling.
At that moment, it became clear to me that I just spent close to 25 minutes walking someone through our product and he was still not quite sure what exactly it did. Sure, I knew smartURL is complex, but I didn’t think that complex. It was easy for me to know it’s nuances, its subtleties, and the shortcuts of features because I built a lot of it. But for someone going into it for the first time, especially without one of the developers holding their hand through the process, there is no way they could have completely understood every aspect of what was happening.
Thankfully, the director was happy to help.
The first piece of advice we had gotten was to think about presenting information this less technically, and more conversationally. “Default URL” means a lot to my manager and I, as does “Country Destinations”. But to most anyone else, they’re sterile technical jargon.
“Why don’t you think about how to convey this information like a question?”
What is it that this field is doing? How can we pose a question that gives the user confidence in what they’re entering, and leave the heavy lifting behind the scenes? I’ve seen others get, or even received myself, the feedback that sometimes our labeling is too robotic, or too…literal. I needed to think about this as a user journey, rather than fields in an object that the server was expecting to parse.
The second piece of advice was to not hide too much information when it is truly important that users have access to it. Sometimes simpler UIs are the correct solution, but in our case we made it too simple and that was leaving room for ambiguity.
“If the country where a retailer appears is confusing for a lot of people, why don’t you show more information about what’s going on?”
A question my manager and I sheepishly admitted to not having a good answer to. It was something that got left on the back burner as a “we should probably fix that eventually” line-item, but never got around to it. Now was the perfect time to finally do so. We brainstormed how this could be addressed and the most obvious solution was to show the list of countries a retailer worked in. After more iterations, we realized that it was possible to allow people to control the list of countries themselves. Ultimately, we settle on the following:
Users now get a three-option solution (and I, surprisingly, was allowed to come up with the copy for some of them???).
Option one: “smartURL verified”. This basically means you leave the country list as-is and let us take care of the markets a retailer is available in. We also explicitly state where those locations are, so you will know if a different option would work better.
Option two: “custom selection”. The user gets to choose what retailers show up where; this could be as granular as they’d like.
Option three: “Everywhere – the world is your oyster”. No geographical limitations are put on a retailer, so it’ll show up everywhere.
The labeling for each of the input fields also changed. Now it was a more inviting question that helps guide a user through this process: “where are people going?” Additionally, the “country destinations” links are now hidden behind a toggle that asks “are there places that need a different URL?”
Another feature that came out of user testing was the option to modify the page’s preview window to mock a different location. This allowed for users to play around with different countries and confirm that all of the retailers are showing up as expected.
While this whole process took a lot of work, included several meetings with design, media coordinators, and even the CEO, it was all worthwhile in the end. Proudly, this UX redesign was a tremendous success. Gone were the weekly emails asking me to explain what was really going on, gone were the help desk submissions confirming that a certain retailer would really show up for customers in a neighboring country, and gone was a lot of confusion that overly literal labeling had caused. Several other coworkers also expressed their thanks with the rework because it was also a problem their clients would often get confused about.
Sometimes, you don’t get UX right the first time. Or even the tenth time. What matters is that you listen to what the problem is, and try to meet people where they’re at to solve it. And when you finally do, everyone’s life will be made easier.
=> { }
Fat Arrow Dev 