Imagine having done your job a certain way for many years, and then all of a sudden a new way of doing things is introduced. There will certainly be those who embrace change, but there will also be those who fear it. Just look at the public outcry every time Facebook makes a little change to their UI. That isn’t just a technology world thing, that’s a life thing.
Having worked with Drupal development for many years, it would be easy for me to take for granted just how sophisticated a platform it is. With sophistication comes a level of complexity. Of course, once you learn it, everything is smooth sailing. The question is, how long should it take to learn, and can you afford that amount of time to learn it?
If the answer to that question is ASAP, then some work will need to be done. That is the beauty of Open Source - you can react quickly to requirements. This post talks about several ways that we set out to accomplish this during a recent project for Time Inc.
Time Inc is an American New York-based publishing company. It publishes over 90 magazines, most notably its namesake Time. Other magazines include Sports Illustrated, Travel + Leisure, Food & Wine, Fortune, People, InStyle, Entertainment Weekly, and many more. Many, if not all, of these Titles have web properties. Depending on the Title, their website may be built on a variety of technologies ranging from Wordpress, to Vignette, to Drupal and other legacy technologies in-between. The fact is, running all these different technologies means running specialized teams that are not particularly cross-functional. Editorial staff who know how to publish content on time.com for example, may not have a clue how to publish content on Sports Illustrated or People. This is just one of several catalysts for standardizing on a single technology platform.
Understanding existing systems. Likes and Dislikes
In the first week or so that I started learning about Time Inc.’s editorial workflows, I often found myself saying in my head “Drupal can do that better” or “That won’t be a problem with Drupal”. Things of that nature. I was so heavily biased towards Drupal that it didn’t occur to me right off the bat to consider the things that an editor actually likes about their existing workflow. There were many instances where the overall feeling that an editor had towards their platform was generally sour, except when we got to talking about the individual features within them. There were things that they just didn’t want to part with. For example, how they search for an image, what types of filters do they rely on, what is the search interface like? Learning all the things that editors liked was going to be absolutely crucial to the success of Drupal adoption. Without having learned about what an editor likes and dislikes about their workflow, there really isn’t a starting point for ‘change'. Having had such candid and in-depth sessions with editorial staff enabled me to become connected, zoned in, and to make professional decisions that found a balance between what I knew needed to change versus what I couldn’t change (without getting thrown out of the building).
Holding workshops and capturing requirements and future state needs
This is where the real fun began. With the convenience of having my target audience actually present in the building, getting them involved in the process was easy (thanks to the project managers). However, if all editorial staff are sitting in a room with me for a few hours, that breaking celebrity gossip is going to have to wait. Obviously that was not acceptable, so we had to break the workshops up in to three groups which, at the time, was the way that Titles were structured anyways. The sessions would need to be efficient, effective, and as thorough as possible in the limited amount of time I could spend with each group.
Prior to the first workshop, I had developed a conceptual wireframe document that showed what their new workflow ‘might’ look like. The wireframes mirrored the forms in a default Drupal installation, except I made some changes based on what I knew from my one-on-one meetings with editorial staff. We created print outs of these wireframes and placed each document at a boardroom seat, just like a place-mat at a fancy restaurant, for when our guests arrived. We also set writing utensils, sticky notes and markers so that the Editors knew we wanted them to collaborate. I walked through the wireframes on the screen and had them write their feedback directly on their wireframe documents for me to collect later. There was good dialogue throughout these sessions. Lots of questions, lots of ideas, lots of feedback. Repeating the same workshop with 3 separate groups of Editors allowed us to see what was common and absolutely critical to Editors across all the different titles. We found common pain points and common future-state needs. All I had to do was address them in the next iteration.
Refine and repeat. We held workshops just like that for several iterations until we were confident that we had an up to date wireframe document that laid all the groundwork necessary to extract requirements and user stories ripe for prioritization and development. Concurrently, I also had enough information to start thinking about the actual design.
This is part 1 of a 2 part blog series.
- Demo’s & training forums
- General usability and user-centric approach.
- Maintaining authoring context.
- Getting stakeholder buy in for the editorial user interface