How we use iteration at Wattpad to consistently improve our design
Rebuilding Home on Wattpad and shipping user value incrementally
Hey UX designers, tell me if you’ve read this blog post before: some ambitious designer or design team looks at an experience in their product, gets the buy-in to improve it, throws all of their IDEO-sanctioned processes in the oven, and out pops a portfolio-ready redesign adored by users the world over.
I work at Wattpad, so I know fanfiction, and that has got to be the most unbelievable UX fanfiction I’ve ever read. Yet it’s plastered all over Medium, it’s crept into people’s portfolios, and it sits like a sparkle in the eye of every aspiring UX designer like it was Harry Styles asking them to the prom.
The truth is, redesigning an experience isn’t really a thing that happens in one seamless journey. Those blogs largely leave out meaningful iteration. Yes, they’ll talk about how user interviews altered an assumption or how an engineer needed a screen simplified, but that pre-production iteration doesn’t reflect real users using your app in the real world and generating feedback, support tickets, and angry tweets. That’s where the best laid plans meet users that don’t use things the way you expected or the places that your survey results don’t line-up with new user behaviours.
New Year, New Home
When this year kicked-off, we’d just finished shipping the skeleton of our new Home experience and had begun getting feedback. On Wattpad, Home is the first screen that welcomes users into our app, and is made up of dozens of algorithmically curated lists designed to help users discover new stories that they’ll love. “We’d received a lot of user feedback around what was working and what wasn’t,” offers Dottie Omino, the Senior Product Manager on the Content Discovery team that ‘owns’ Home. “So there was an opportunity for us to learn and iterate on the work that had already been delivered.”
The way we work at Wattpad, we use a version of Dual-Track Agile, a blended Discovery-Delivery model that emphasizes delivering value to users frequently and iterating on work rapidly. When we shipped our new Home experience, we weren’t aiming for perfection on day one. “V1 was a baseline that set the foundation for us to be able to more rapidly iterate and personalize based on our observations and learnings from users,” explains Andrew Chak, Wattpad’s Head of Design. “From that point of view, V1 was a foundational success. The real success of [new home] is based on our ability to iterate beyond V1 as that is what will empower a better and more effective user experience. I’m most happy with the fact that we can iterate the experience because it’s the iteration that makes us better.”
It’s a compelling notion to use your first shipping iteration not as a compromised version of the ideal vision, but rather as a baseline experience to generate feedback from while also providing a new technical underpinning that allows for more rapid iteration in the future. That’s not to say that there weren’t meaningful design contributions to that first version — we shipped a modernized version of Home that better aligned with our 2019 rebrand and streamlined the interface by removing much of the story metadata to instead emphasize cover art in response to research findings telling us that was a primary driver of story interest from users. However, there were cuts made to get V1 out the door.
“[We had to cut] Content Settings and blocked tags, quotes from our community, even small UI pieces like what the greeting was at the top,” lists Zoe DiNovi, the Senior Product Manager in charge of the project at the time. “Oh, and the CMS for featuring stories in Paid section and the featured carousel, and the way the featured carousel was structured had certain design restrictions.”
We ultimately felt that V1, even minus these features, brought enough user value to warrant shipping because getting meaningful feedback and rapidly iterating was going to be the real achievement, not trying to ship a perfect feature on our first try.
That’s the first myth from our UX Fanfiction blogs: that it is meritful trying to deliver a ‘finished’ product on your first try. When you’re institutionally oriented around doing one pass on a feature and then moving on, you become slow to iterate on real user problems with what you’ve just shipped, and that means that users are left to contend with friction-full software until it is deemed worthwhile to revisit the feature. Users want software that works for them, and they are a lot more forgiving of software that they trust will fix small things quickly than they are of software that only updates in big, heavy, redesigns.
So, shortly after shipping, we set about trying to figure out what we could fix. “As for determining net-new work, the qualitative (app reviews, support tickets, user interviews) and quantitative (usage metrics, survey responses) data we collected on [new Home] was actually quite useful in narrowing down our focus,” said Omino. “With net-new work, there was collaboration with UX design and UX research to parse through the data to uncover and articulate the various problem areas from a user perspective, then narrow down some of the pain points that would be most impactful to solve.”
Two areas immediately jumped out as requiring attention: getting back into the book that you were reading and adding more metadata back into Home.
Wait, what was I reading again…?
As to the former, when we redesigned Home, merchandising new titles was a business priority, and so our Continue Reading row was removed. We considered moving it down, but it became lost and hard to find mixed-in with all of the other rows of covers. Because we wanted to deliver user value quickly, to address this pain point I opted to use a small toast (a compact UI banner that pops up from the bottom of the screen, like toast coming out of a toaster) on Home to help users immediately jump back into the story that they were most recently reading, without having to jump over to their Library to dig out the title again. I went through a number of variations for this little element — probably around 25 — that played with what content it should include, how it should be arranged, and what the layout should look like so that it drew the user’s attention but didn’t overwhelm the user when they first opened the app.
I ultimately decided that the user only needed very little information about the book they are currently reading to explain what this UI’s purpose was:
- The title of the story, because it is our most consistently-used piece of metadata when referencing a story
- The cover, since not all users can remember the titles of our stories and we know that the cover is a big piece of what compels people to read certain stories
- A prompt, in this case Continue Reading, to quickly contextualize for the user what this UI is for
- A call-to-action, in this case Read, to let the user know where they will be redirected to if they tap on this element.
There were other, smaller, decisions that were fed into this feature, as well. First, I went with a floating bar rather than a fixed bar because I wanted the user to feel like the entire element was tappable, and the drop shadow provided that affordance. Second, we had talked about using more personality in our prompt and CTA, something like “Jump back in!”, but ultimately decided that such whimsy might confuse what is, ultimately, a rather quick and tactical decision that the user has to make. The feature shipped in February and we collected feedback for future iterations (chiefly, adjusting how long someone has to be reading for this element to change, as someone quickly previewing a story that they might read later shouldn’t knock the book they are currently working through out of this spot).
Bring back my story details!
Next we moved on to the much bigger issue of metadata on Home. We had done research that identified cover art as the primary driver of user interest in a story. When we set about redesigning Home, we thought we could lower a user’s cognitive load by focusing almost exclusively on cover art and removing much of the story metadata (like reads, favorites, a little synopsis, and tags) that used to come attached to each cover. We felt confident in this move because our research mixed well with industry trends on media sites like Netflix and Amazon Kindle.
However, this is where that second myth of UX Fanfiction blogs comes into play: despite having user and competitor research to back-up our decision, users struggled with what we shipped once they had to use it day-to-day. Despite our attempt to lower cognitive load, we had instead increased it, as users were left with too little information to make informed choices on stories based on covers (and a single tag) alone.
What we misinterpreted in our research was that while cover art is a primary driver of interest in a story, isolated from all other context it fails to provide a user with enough information to want to click through and find out more about a story. Cover art certainly grabs attention, especially a good cover, but users were using that cover art to pull their eye towards a low-friction engagement that included the metadata to help them decide whether to make the high-friction move of opening a new page to reveal more story details.
Users wanted to get a sense of their return on investment for a story.
This gave us an opportunity to reframe the question about what information users needed on Home. Whereas before we wanted to know what primarily drove their interest, we now wanted to explore what information they required to drive action. We sent out a survey with just about every piece of metadata we could think of about a story and asked users to rank importance, and two characteristics stood out in their responses: How long is it, and is it complete?
Users wanted to get a sense of their return on investment for a story. They wanted to know that the story had enough length to warrant their time and attention, and they wanted to know if it will have a proper ending (a chief complaint from Wattpad users has long been getting totally engrossed in a story, only to discover that the writer abandoned it years before without finishing it. Since Wattpad is made up of user-generated stories, a story being incomplete is a real possibility for users).
We also learned that this was not a place to use tags. The blessing of tagging on Wattpad is that writers can paint a fairly accurate picture of all of the areas of interest their story touches upon, often including more than fifteen tags to call-out various niches, but the downside is there is no way to isolate which two or three best represent the story. We tried randomly assigning tags when we shipped new Home, but unsurprisingly this proved more confusing than helpful, as users were left to tackle with what it meant for a story to be categorized as ‘lies’ or ‘park’. While we continue to explore the possibility of algorithmically determining what tags best represent a story, for now we chose to delay the user seeing tags in the ‘choosing a story’ experience until they can see all of the tags on the Story Details page.
Now, this is where reality makes waste of great ideas. We had wanted to test a variety of metadata combinations to give us a sense if any particular combination drove higher conversion (at this point we were still entertaining having a small handful of random tags as a part of the experiment). However, technology ran afoul of our ability to run the test, and so instead of a data-informed choice de-risking the final solution, I just had to make a call on what data would be included. Keeping in mind that we needed just enough information to help the user make a quick assessment of if this story was worth further investigation, I ultimately used our research learnings and my own opinion to settle on:
- Title
- An indication if the story was paid
- The number of parts
- An indication if the story was complete or ongoing
- Four lines of the synopsis
I opted to include a piece of the synopsis for two reasons: one, in lieu of tags we needed something to give the user a flavor of the tone of the story, and two, if a user was engaged by that short tease they might be compelled to read further by progressing into the full Story Details.
Deciding on what metadata to show, however, was not the hard part of this iteration. The hard part was deciding how to show it. It would have been easy to roll-back to a view of home where every story presented all of its metadata all of the time, but the fact was it was overkill considering that the user is only going to need the additional information for a small subset of stories that interest them. This was a good time to remember our Hick’s Law and strike that balance between being useful and overwhelming.
To that end I tried leaning in to progressive disclosure, which involved a little bit of friction to expand a story to see more details about it, but without navigating away totally in a heavy and committed interaction. I would have the user trigger the expanded metadata by tapping on the cover that interested them, so they could see some more info before committing to leaving Home.
However, upon presenting that option to the Content Discovery team, several engineers quickly hit upon the fact that, for those that want to go directly to Story Details (which had historically always involved a single tap on a cover) we were adding a tap that may not be welcome. While I instinctually wanted to explain away this concern with the value a user was getting for this friction, I knew they were right and that my interaction paradigm would not work for the way our users were used to using Wattpad.
From there I considered a way to expand a row into a ‘detailed view’ or adding a similar option in settings, but both lacked discoverability and forced the user to jump out of one mindset (looking for a new story) and into another mindset (how do quickly see more about this story) and back. So while I didn’t have a solution, I had reached a certain conclusion: if we weren’t going to have metadata persistently available for all stories, but we wanted the additional metadata to be discoverable, I could always create a focus state and show metadata for one story per-row at a time.
Of course, focus states don’t really exist as a mobile paradigm, so I borrowed a paradigm from TV interfaces, where the ‘active’ cover swells to show focus, only in our implementation the first position on every row would carry ‘focus’ and covers would scroll through it to activate their metadata. It was a very tricky interaction to explain or even show in static mockups, but once we could actively interact with it on device, it worked like a graceful iteration on our design motivations for Home. User testing showed that users had no problem understanding the interaction model, and there were positive sentiments towards the return of metadata, but the proof will be in how users actually use this feature day-to-day.
We are about to ship our new metadata row on Home, and no doubt our analytics and user feedback will help inform the next iteration of this feature, because at the end of the day that’s how these blogs really should conclude. There is no satisfying button to put at the end of a design blog like this because all we do is learn, design, learn, iterate, and learn some more. There is no satisfying conclusion that ties it all up because the work never really concludes. That being the case, the only appropriate send-off I can think of is this: I don’t know how this will all work out once users have their hands on it in the real world, but I know that they’ll tell us and we’ll tweak it further and hope that we get a little bit better with each iteration we ship.
