Behind the scenes

Sowing the seeds for the continuous redesign

We know that people come to Philly.com for the journalism, which represents the combined effort of the largest newsgathering organization in Pennsylvania. But we also know that if the experience doesn’t meet expectations, it doesn’t matter how good the journalism is: People will go elsewhere.

This was top of mind as we set out on a redesign effort for Philly.com.

The goals

We are looking to achieve a number of things in this redesign. A sampling:

  • Work well on all devices: We want to build a product that functions consistently on screens large and small and doesn’t shortchange mobile users.
  • Grow engagement: Our site is full of useful and interesting news and information, some of which doesn’t get the chance it deserves to reach a digital audience. We believe we can fix this.
  • Improve ad experience: We know we have some work to do to optimize ad impact and user experience on Philly.com, and we think we can do that in a way that adds value for advertisers and users alike.
  • Make money: At the same time, we urgently need to grow digital revenue in order to help sustain our company and the award-winning journalism it produces. This is our balancing act.

But we don’t want to be back here in two years thinking about our next big redesign and preparing to start the process all over again. So we’re setting up this project a little differently.

A phased approach

Think about the last time your favorite news site redesigned: Did it catch you by surprise? Did it feel different or take you longer to find things? Did it take a splash page to explain all the new features? Now consider products like Facebook or Gmail: Can you even remember the last time they were redesigned?

What I’m talking about is the difference between redesigns in the traditional sense — months- (or years-) long efforts with a big reveal (and a big leap of faith) at the end — and continuous, small changes that through testing and observation over time yield better results with less disruption to the user.

We’re looking to take some inspiration from what leading digital players have done by rolling out our redesign in stages and then continuing to evolve it after it’s launched.

But we have to start somewhere, so we’re going to tackle the article page first. Why? Because this is where visitors to our site spend the largest amount of time. It’s the destination, and we want it to shine.

From here the process looks something like this:

  • Article page beta: In the next couple of weeks we’ll be launching a public beta of the new article page. If you want to try it, you’ll need to opt in via a link we’ll post on this blog.
  • Mobile site relaunch: By the end of the year, you’ll see the new design replace the current mobile.philly.com site.
  • Full relaunch: In early 2016, we aim to roll out the redesign on Philly.com.
  • Continuous improvement: Relaunch is only the beginning of an ongoing cycle of listening and fine-tuning.

Always be redesigning

Throughout the process we’ll be seeking feedback and incorporating this feedback into the site. We know we’ll make mistakes, and we hope that introducing changes gradually and listening to users along the way will reduce the number and impact of these mistakes.

I tell colleagues that if we get this right, it could be the last redesign we do. That’s probably overly optimistic, but it’s definitely an aspiration.

Through this effort and our collaboration with two world-class locally-based design partners — Happy Cog and Superfriendly — we are building the necessary skills and product culture to begin a continuous design process that we hope will take us far.

We know that users’ expectations are not standing still, so neither can we.

One thought on “Sowing the seeds for the continuous redesign

  1. This comes across, to me, as a misunderstanding of the benefits of semantic versioning. Continuous rollout increases product quality, absolutely. But that’s because it’s a byproduct of the underlying structure behind the engineering and design teams. They’re working in sprints, coordinating across departments, leveraging exploration… the sort of stuff that necessitates bi-weekly or weekly releases. Because you have different branches, different features, different stages of implementation, and you’re rolling out the A version to 10% of your users, then the B version to 10%, then the C version… is that really what you want to do for a *news* site? A high level of fragmentation? For a *local* news site that’ll plateau at, what, maybe 2 million users? That’s a challenge. You don’t want a big moment happening and half of your users looking for news and instead finding themselves in a navigation split-test.

    I hope that doesn’t come across too negatively. Happy Cog and Superfriendly are wonderful. This project seems cool. I’m just hoping it’s well researched. I’ve learned from experience that implementing continuous rollout with contractors can be a nightmare, so I’m hoping to help you guys avoid the headaches I had!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s