In this post, we give you a behind-the-scenes view of the application we built for our Editors to create PLOS Collections, and take a look at the user experience work that went into it.
On October 21st, PLOS launched our new and improved Collections. With this launch, we added many enhancements to the PLOS Collections experience, including a fresh new design and a widely expanded offering in terms of what kinds of content can be in a Collection.
Our team worked hard to ensure that the new Collections are everything that we and our partners had wanted – and my job as Product Manager was to make sure we were effectively solving the right problems. I am also the Product Manager of the PLOS Content Management System (nicknamed Lemur), so I have an additional priority for Collections: to ensure that using Lemur to create Collections is a great experience. And that is the focus of this blog post – highlighting the experience of creating a Collection, and how we got there.
Lemur Collections
Let’s start by looking at creating a Collection with Lemur. As soon as you give your new collection a name, you are dropped into the Draft Workspace. You can then add content and populate the Collection any way you wish – there is no prescribed order.
The image controls make it easy for anyone to make a Collection look beautiful – you simply select an image and then zoom and pan it into position.
You can add content in batches or singly. You can choose to feature articles, blog posts, or any valid URL — which really opens up your options! Whatever the content type, Lemur goes to the source and scrapes the title, authors, pub date, and images. It even uses heuristics to select a likely image for the thumbnail. If you don’t like it, you can select any other associated image, or upload your own. And you can zoom and pan just like you can for the banner image.
Your content may lend itself to a certain reading order or organizational structure. Lemur lets you create Sections and drag and drop your content into place. Renaming sections is easy — just click to edit the title.
We have other sidebar content options, that you can set up in what we’re calling widgets. You could have a widget for a blog feed or an article feed. You could use a text widget to feature the curator or tell more about the Collection, or whatever else comes to mind, and it has an optional button link.
This is How We Do It
(Cue music!) Here’s a quick look at, yep, how we do it, with an emphasis on how we run our UX (user experience) program.
We started this project by taking a big step back to think through our long term vision for Collections. We achieved this through an experience mapping exercise (loosely based on Adaptive Path’s methodology) that had us think through what people would be doing, thinking, and feeling at various touchpoints of the process of creating collections. This gave us great perspective before we dug into the details.
Next we ran our design inception, a big chunk of which we spent annotating initial design mockups to create a user experience story map. Then we translated those annotations into Trello to form our UX backlog.
Then we settled into our UX design program, which we tackled in 2-week design sprints culminating with user testing at the end of each sprint (sometimes more frequently than that). We generally start a project by quickly getting some hand drawn paper prototypes in front of people, as a low-investment way to aim ourselves in the right direction. Then we move into testing higher-fidelity prototypes that our superstar UX Designer, Davina Pallone, creates with Sketch and makes interactive with InVision. We are fortunate to have a wide variety of user testers for our internal tools, right here at PLOS.
Once we had a comfortable amount of the application prototyped, we ran our development inception. This involved giving our developers a lot of background information about the problems we’re trying to solve with Collections, reviewing the prototypes and user testing we’d done up to that point, and generally getting to a shared understanding. Then we wrote the stories for the first sprint as a group. The developers got started on that work, with plenty of collaboration with product (that’s me) and UX. For the next sprint we wrote more stories together, and the developers worked on those … and we basically kept on like that until we were ready with the lean feature set for launch.
Our Agile development process is highly collaborative: our developers, UX designer, and product are embedded together and we discuss what we’re working on whenever we need to – which is pretty much all the time. One real boon to our process was implementing a live style guide, which we did for the first time during this project. Aside from the consistency benefits you get with a style guide, one additional major benefit we got was that Davina, our UX Designer, could edit the CSS directly. This means she immediately sees the impact of her changes within the style guide and also in the application itself. This self-service styling work has saved us so much time and churn over the way we used to work, and netted us a more attractive application because we don’t have to weigh the cost of putting developers on styling work vs. feature development. No matter how detail-oriented our developers are — and we are fortunate to have such detail-oriented and design-sensitive developers on the team — having Davina edit the CSS herself is a demonstrably more efficient process.
There was plenty more magic and activity behind the curtain, and collaboration with several other teams, to get Collections out the door. But I wanted to focus on our UX process and the Lemur side of the project in this post. Kudos to the entire extended team, with a special shout out to our UX Designer, Davina Pallone, of Cloud City Development.
3 comments