Wattpad

When I shifted to the content discovery team and started working on Home, I wanted to look at trust, and how much users trusted our recommendations and suggestions to them. Trust was going to be key for us to grow our paid stories business, and we just didn’t have enough of it when we asked users to compare us to competing platforms.

I got to thinking about how we build trust person-to-person. Trust is built through active listening, and then demonstrating that you heard what was being told to you. I wanted to explore how Home could be a place where we showed the user that we’re listening. I can tell you “you’ll like this book,” and hope that you trust me, but if I say “remember when you asked me about sci-fi books? Well, here is one I think you’ll like,” that additional context both shows you that I was listening and it will make you take a longer look at the book I’m recommending to you. We were missing a step between “open the app” and “here’s a story” — we weren’t telling users ‘why’ we were showing them a story, and weren’t giving them any information about that story that might give them a sense of if they’d like it. That needed to change.

Myself and my new PM were totally aligned on focusing on an idea — trust — rather than on this feature or that feature. We knew that what had shipped was never meant to be the final iteration of Home, and so we set about figuring out how we could start the long process of building more trust with users when they opened the app. We knew we needed to address the context we’d removed, and we knew that was going to require us to find out from users what context they were especially lacking, and how to augment this new home design to accommodate it.

I had a theory as to what parts of the conversation were ‘missing’, and I wanted to get them on paper quickly so the team could have a shared context to start our discussions with. I always find it’s easier to start with something concrete — even if it’s bad — and then build on that so that we’re all talking the same language. I went in with two ideas: being more explicit in our row headers about why users were seeing groups of books (such as calling out their genre affinities, reading history, and search history) and then showing them more key metadata to get a sense of how that grouping was relevant to each title.

Since we were all aligned on getting more context into our row headers (and subsequent user research validated that approach), we decided to spend time figuring out how to add more story metadata back into home after it had been stripped out during the redesign.

We sent out a large survey to our users to get a sense of what drove their interest in a story, both in terms of metadata and not. Because Wattpad content isn’t generally widely publicized off-platform, in-app metadata tended to be the largest driver of interest in stories, but the type of metadata surprised us. Outside of obvious things like a short synopsis (the number-one determiner), we had long believed in social proof stats like read counts and favourites. In fact, it turned out that our users were less interested in stats and instead wanted to know two things: how many parts are there, and is the story complete.

Because Wattpad is exclusively user-generated content, users have to contend with things that platforms like Netflix or Apple Books don’t, like the completeness of a story. It turns out readers would rather know if they are going to get a long, complete experience than if other users really liked a particular title or not. This gave me a good sense of where to take the UI.

We’ve always shown at least one ‘tag’ per title on Home to help give the user context for what type of story they are seeing. Wattpad, though, doesn’t do genres like traditional publishers, owing to the fact that the types of stories found on Wattpad can often exist outside of the traditional genre model. This is both a strength and a weakness of the platform, because it allows for the diversity of content that has made Wattpad successful, but it also makes it harder to give a user a sense of what ‘kind’ of story this is.

Our tags were randomly assigned on Home (we would pick one from the dozen or so that writers typically add to their titles), which was not ideal but it was impossible to know the one right tag that would be the most descriptive. Our users, however, were pretty adamant that no tag is better than a random tag, and when we tested version of our new UI with no tags, users largely preferred them to the versions with four or five random tags (that is, when they even noticed that the tags were missing at all).

Once the metadata module had been nearly finalized, we needed to determine how the user would trigger it. My first iterations focused largely on tapping on a cover to expand the metadata section. This behaviour could be quickly learned and consistent throughout the app. However, the team immediately seized on the problem of adding a tap between home and the story details page, especially when we were trying to improve our clickthrough rate on home. If the metadata wasn't triggered, however, that would mean it would need to be persistently there, which made me nervous since it would add back a lot more visual noise to a home interface that had just been cleaned up.

So, to address my fears, we started putting the metadata UI into user tests for other features, and seeing if the user noticed it and/or was bothered by it. It was surprising how few people even noticed its was there, but when they did they were largely appreciative of the extra info. So, it was decided, persistent metadata was making a swift return to Home.

If the metadata was going to be persistent, though, then we were going to have to come up with a user-identifiable focus state so that people knew what piece of content that metadata was referring to. Unfortunately, focus states are rare on mobile, so there weren’t a lot of great common options to choose from. I opted to borrow Apple’s tvOS focus state, where the cover art swells when it is focused, and keep it so that only the left-most cover is ever enlarged (basically, titles come through a position in the UI). I hoped that the consistency, even if not immediately clear, would be an easy convention to learn and adapt to.

When shown this UI in static mockups, the design team was concerned about how clear this interaction model was going to be. It was on my radar, but once we moved to some motion design on it, the UI was much clearer. The interaction was key. This was a good reminder when getting feedback: give people the right context/framework to evaluate a design through, even fellow designers. They haven’t been sitting in your head with it as long as you have.

One of the most rewarding parts of working on this solution has been the engagement of the whole team in all manner of UX issues. Our team is made up of front- and back-end engineers, a content specialist, a data scientist, a product manager, and myself, yet everyone was as invested in the user’s experience as I was. I also found that the more I shared throughout the process, the more ownership everyone felt over what would eventually ship, and so everyone felt eager to chime in with thoughts and ideas. I have now begun actively sharing ideas with more than just the design team far earlier in the process, and continuing to do so throughout. What I got back from doing so improved the work immeasurably, and I can’t imagine building another feature without that kind of a feedback loop.