Client: Dictionary.com
Project Length: 1 year and some change
Team: Sandy Micone, Michael Villas
Key Role: User research, prototyping, design production, and engineering communication

Dictionary.com set a goal to redesign their mobile web experience. They needed three things to happen: to maintain their legendary SEO rank, to increase session page views, and to drive ad revenue. Here’s how it went down.

 

TLDR: As the only designer for nearly a year, I led the redesign process from research to implementation. At first, we struggled to validate the value of clickthrough features over ad visibility. We ultimately launched a clickthrough-heavy prototype and then scaled back to something in the middle. The process relied heavily on responding to user testing and revenue analytics. I was able to use my visual skills to make quick and effective prototypes that were on brand.

Redesign Goals

  1. SEO. Dictionary.com needed to maintain its superior SEO standing. In the years since its birth (1995) many competitors have flooded the ‘definition’ space (most notably, Google). The convenience of being the first result is a competitive advantage that cannot afford to be lost.

  2. Clickthrough. Dcom users are one-stop shoppers. They often read the first few definitions and then ‘go back’. We wanted to encourage users to explore more content and see more ads.

  3. Ad impressions. Ad tech has come a long way since 1995. Dcom wanted to catch up with technology and optimize their screen space for profitability. Quantitative revenue analytics informed the redesign process.

Research

 Behold. The great wall of research.

Behold. The great wall of research.

Surveys

In starting the process, we needed to collect a profile of our user. A person we could reference throughout the redesign. “This feature is brilliant but would ‘Kaila’ use it?” We worked with engineers to implement a ‘visually effective’ link to a survey that would go live to a quarter million definition pages. After a week of being live, the link brought in 100k responses. 

 It is ugly but you cannot argue with results.

It is ugly but you cannot argue with results.

Persona Defining

Our survey results informed us of the behavior, touch points, and mindset of users. We were able to generalize four personas from the data. The most relevant persona was the college millennial persona. They used Dcom regularly, they accessed our website through their phones, and that they have a small tendency to need synonyms. I designed this persona into a poster we could reference throughout the process. Check it out below.

persona-card.jpg

Qualitative Competitor Analysis

Our findings informed us that our primary mobile segment was college millennials. We did the obvious thing and found some to talk to. We took a foldout table to UC Berkeley and started talking to students. We recorded them as they used their phones to define words. Sometimes that involved Dictionary.com, sometimes it did not. We asked neutral questions so that the users could inform us of what they wanted. Extra credit: We collected contact information so that we could use students for future tests.

Synthesis

Our research told us which users to prioritize and put us in touch with them.

How Can We?

We began our process with “How Can We(s)”, a process adapted from the Google Sprint methodology. We circled up all the stakeholders into a room, and asked them to voice their problems through a madlib.

 Everyone has ideas. HCWs help prioritize them democratically.

Everyone has ideas. HCWs help prioritize them democratically.

Every post was presented and posted to the wall. Immediately afterwards, they were organized into problem areas. For example “promote blog content?” and “clickthrough to Thesaurus.com content?” were organized into a content-promotion bucket. Immediately after that, we were all given two votes for what we thought was most important to work on. The votes were represented as stickies so that people wouldn’t be persuaded by others.

It’s all about prototypes. 

Enough talk! Show us the money. Here is how we took that information and turned it into a prototype.

1. We created links to TCom content and crafted a new search-bar. This was meant to encourage users to search Dictionary.com instead of ‘pogo-sticking’ to google.

2. We placed the most semantically robust content first to preserve SEO.

3. We created an ad placement that would meet the minimum view-ability necessary to count. This unit could also be customized in the future as we tested ad configuration which was helpful! Read the next paragraph to learn why. 

Quick and dirty ‘scrolling paper’ prototype.

Testing

Next, the executive team wanted to test mobile video ads. They knew the revenue returns would be high but they needed to guarantee it wouldn’t effect usage patterns/ frustrate users. I designed a ‘fake-enough’ experience using principle, which actually featured a video ad. This prototype recreated the experience enough to ascertain the user impact. We were able to make an informed product decision using the results.

The prototypes also allowed us to establish baseline design effectiveness. Were the links legible? Was the search bar effective? Would users change their search behavior because of the design? We observed users over Usertesting.com and in-person. Their responses shaped the iterations of our layout.

 I’ve got 99 problems. They’re all feature requests

I’ve got 99 problems. They’re all feature requests

Visual Design

Millennials. You might be familiar with the type. These young users have short attention spans and high standards for websites. We updated our look and feel to respond to this growing demographic.

MobilePhones@1x.jpg
ContentCards@1x.jpg

Delivery

Delivery. is. crazy. Especially when you are the only designer. To make the process manageable, I implemented Zeplin to make the engineering handoff more efficient. This was the first time a redlining mgnt tool was used at dictionary.com. I helped make that happen. I even gave a presentation on how all stakeholders could effectively use it.

 Redline tool: check. Puffy-vest: check.

Redline tool: check. Puffy-vest: check.

Problems caught before launch

It is every designer’s dream to redesign a dictionary. When I created the visual look and feel of the redesign, I included custom web fonts. This was going to be my childhood dream come true. I would get to adorn definitions with a legible, elegant typeface that communicated Dcom’s venture into the future of human language. Long story short that could not happen. Not yet at least. To explain why we couldn’t: I’m going to ask you to think for a second. Consider dictionary.com’s demographic… millenials on phones with data plans… consider Dcom’s monetization strategy…. displaying ads to users… and finally consider Dcom’s design legacy… dependent on convenience and speed….

It actually set us up for the future. Now that we knew our limitations, we could design other properties (homepage, definition pages, Thesaurus.com) with the same principles.

Loading fonts not only increased the load time of the page but also the load time of ads. That is a no-no. Now consider that this problem is exacerbated by poor data connections, you have a YUGE problem. We decided to cut custom web fonts. This actually became symbolic for the future design of Dcom. We are a company that is driven towards convenience and simplicity and luckily, verdana communicates this very clearly. This is how we took the problem, and made something good come from it. It actually set us up for the future. Now that we knew our limitations, we could design other Dcom properties (homepage, definition pages, Thesaurus.com) with the same principles.

 Loading custom fonts adds up to a second of latency. No bueno.

Loading custom fonts adds up to a second of latency. No bueno.

Release

We used a segmentation tool to launch our v1 to 10% of mobile users. Immediately there was a problem. Ad revenue. Because of the variable nature of definitions, ads were being pushed below the fold. Pair that with the ‘pogo-stick’ nature of our primary demo, and you have a real issue. Users would enter the website, get the first couple definitions, and leave without ever seeing an ad. Terrible. We did the first obvious thing we could do to change that. We sandwiched the ad between definitions. This was a research driven solution. We knew from qualitative tests that users tended to read up to 3+ definitions before ‘bouncing’. Meaning that users were likely to scroll past the ad to see more definitions. 

 Which interface makes more money?

Which interface makes more money?

That was easy. We immediately moved forward with a v2. The problem persisted. We went back to the drawing board and did an anatomical comparison with our original website. The dimension of the header was clearly infringing on ad real estate. We disbanded the header concept and changed the layout to focus on a card centric design. We tightened the search bar to provide even more real estate. We were behind on schedule, and we needed this release to be a home run. It worked.

We released this final version. You can see the release on your mobile phone at www.dictionary.com/define/awesome