How the re-design of the layout workflow of La Presse+, quickly brought value and productivity within the newsroom.
Deliverables • User research • User flows • Wireframes • Prototypes • UI mockups • Specifications for Developers • User Testing
La Presse+, comprised of 60+ screens, is published daily on iOS and Android tablet applications.
The legacy workflow to create each one of those screen is extensively used everyday, and has been around for the last 7 years and counting. In an everlasting desire to do more with less, my back-end team was tasked to re-design a layout workflow to be able to publish the same structured content on all platforms (web, mobile app., tablet app.) with minimal intervention from editors.
What is this layout workflow ?
This manual workflow allows editors, directors, reviewers, graphic designers, etc. to produce a screen, hosting an article, for the tablet application.
It is nested within a bigger workflow of producing the whole edition of La Presse+ on a daily basis. Layout workflow is comprised of the following steps :
- Import the structured content within the canvas and/or the chosen template
- Edit the article within the screen for layout and storytelling purposes
- Do the layout for ergonomics and aesthetics purposes (rich content, animations, charts and tables, etc.)
The existing process was time-consuming both for editors and graphic designers fo the newsroom, draining precious time instead of capitalizing efforts on other places. A big part of the work done during this layout phase is repetitive, has low value and make the late evening production very complex.
1. Understand the problem
We started to gather context around the problem to solve with this new workflow. It had been 2 years since we made several proof of concept of an automated edition. Back then, we pitched and proved to higher executives what it could look like and how this had potential for scale.
Through a couple of kickoff meetings and onboarding sessions on the project various people and executives, we clearly identified the following facets :
- How an automated article's look is going to determine how complex the back-end solution will be (what are the requirements)
- Change management is going to be hard, and will take time.
- Onboard users early, collaboration is key to inviting people to use your product, because they are part of the solution.
- La Presse+ is mostly, if not all about the layout and the storytelling. Aesthetics of a screen are very important to the newsroom.
Considering those findings, we decided to start by re-designing the way an article looks to be able to define reasonable requirements. Also, we decided to focus on the most simple type of screen as a starting point (see capture below).
2. Explore and ideate
I was used to work with people from the newsroom, so I was tasked to organize workshops with several people from editors, graphic designers, the artistic director of La Presse+, and people from product, in order to gather user needs in terms of layout and aesthetics.
The main objective from a product point of view was to translate user needs into a very simple template for a simple screen, then start to build upon this base.
I hosted a full day of workshop each week for 4 consecutive weeks in order to understand the following aspects :
- How an article looks like in La Presse+?
- How many and what types of commonly used screens do you have ?
- Why do they look like that ?
- Why are you using this [color, font, font weight, background, animation, tag, etc.] in this specific situation ?
- What are you trying to achieve with this ? i.e. Editorial value, aesthetics, etc.
During those workshops, we used cookie cutter activities with people, as not everybody was confortable doing workshops, even more more remotely. Using Miro, we brainstormed using "How might we" notes to quickly find bulk ideas to refine in later sessions. We casted votes on ideas, refining them session after sessions, we also looked at existing samples of La Presse+ articles as support to spark new conversations.
By the end of the two first workshops, we listed most of user needs required to properly convey their stories and satisfy the aesthetics of the experience reading an article.
It's essential to bring people to think outside their box, to be able to find a common ground. So we benchmarked with participants in order to explore solutions, challenge the existing way of doing things, and move the conversation forward.
3. Sharing is caring
After this first phase of defining what problem and what needs we were addressing, we all felt as it was the right time to move to the next step of our collaborative journey. At the end of the second workshop session, we settled on several hypothesis on how to answer those user needs, for instance :
User need : Setting a pace within your storytelling
- Use text styles (font weight, font family, colors, case, etc.)
- Insert rich content (photos, images, videos, galleries, social, audio, hyperlinks, etc.)
- Module styling (indent, separators, marging/padding, etc.)
We took those hypothesis, and did a co-creation workshop where each participants was asked to design the most simple screen that could validate or deny those hypothesis of solutions. After a few iteration, constantly diverging and converging together until we found the best iteration, we started to have a MVP version of an automated article.
We continued to refine the way an article should look like, testing the new template in all kinds of situation, with various colors, backgrounds, font-size, etc.
Takeaway We started to get a sense of how those visual attributes would translate into requirements for the back-end, and most importantly, how people started to change they mind by being open to think outside of what they do currently.
4. One standardized template
Those workshop sessions allowed us to produce detailed specifications for a simple article, destined to be the minimum viable screen that we could use to launch. With this template of a "simple screen", we simplified ten fold the development process, clearing out most of the exceptions we had with their legacy layout process.
In the following weeks, newsroom people started using this template manually within their legacy system, it order to gauge impact on the user experience and to start introducing the new layout and aesthetics to our readers, and this, to uncover potential showstoppers.
What about the Backend?
1. Humble beginnings
With this new template in hand, we started to list requirements with my Product Owner, and started designing the backend part of this project. Due to time and cost constraints, we weren't able to do as much research as in the first phase of the project. However, we started designing interfaces and processes that constantly shared with our end users, mainly editors of the newsroom.
We iterated first on a workflow from beginning to end, laying the foundation.
We then worked closely with users to balance development cost, ease of use and above all respecting the current workflow in which we are integrating parts of our new workflow. Therefore, we had to design part of the interface in the legacy system, used to build the edition.
2. Automated screen editor
We quickly reached the biggest and most interesting part of this workflow, the automated screen editor. Developers decided to create a standalone version of this configuration screen, simply to future-proof it from the rest of the legacy systems. Therefore, if at one point those systems are decommissioned, it will be easier to plug the standalone service to a new system.
It influenced greatly the design, since I was integrating my design into a system that exist, I had the freedom to start from a blank page. I wireframed some early version of this service. Validating it with users, developers and my product owner.
We initially thought that editors would care to have a preview of the configuration options they chose, however, we quickly realized by talking to the users that despite being a very good idea, conceptually it was a bit misleading to take 3/4th of the real estate just for a preview of a template. We didn't want them to think it is a preview of the content, furthermore, since they had already other means of previewing the article in its final form, it made little sense pdocut and development wise to continue down this route.
We finally settled for miniatures to convey the visual representation of the option, taking the best of both world, with simple choices and its preview, allowing editors to quickly scan options and pick the right one.
Then before you know it, a couple of users suggested that we add a widget to display which article was dispatched into the screen. We loved the idea and added it to our design, along with a shortcut to quickly jump into the article in the new CMS (Story Builder), and a delete function to delete the dispatch link between the content and the screen.
Beyond the minimum viable product
Between our design work and the start of the development we had a few weeks if not months to get ahead and start to plan the next steps.
We conducted new workshop sessions with users and product management to define and iterate on the 2nd and 3rd phase of the project. Amongst many things, we identified the following features to add to our MVP for each "side".
For the Back-end
- Disable all advertising within a screen
- Specify a visual theme to a screen (i.e. for the upcoming olympics, elections, etc.)
- Add several other exceptions, like no video as cover image, or hide the photo credit and description.
We adapted our design along the way to the flow of added features, always in collaboration with users.
For the front-end
We converged with users on a set of new modules to add to our simple screen template, to enrich storytelling and the visual experience.
We needed to make sure to keep a visual consistency between legacy screens made with the old manual workflow and new automated screens made with the new template.
Therefore, new modules were designed both with the old workflow in mind, but also with other platforms (mobile app., desktop/mobile website), this to ensure a consistent experience across all our platform.
Thinking cross-platform greatly helped us with change management within the newsroom. People were only used to looking at La Presse=, the tablet application, but now with a more holistic view of the overall experience, it really helped simplify the visual presentation of those new modules, avoiding costly exceptions during the development, and ensuring a relevant ecosystem.
As of August 2021, we are adding new types of screens requiring new and more sophisticated templates. We continue our work to simplify the visual presentation in order to keep a consistent experience and relevant ecosystem. Editors now spent less time producing screens for the tablet allowing them and graphic designers to focus on high value screens such as investigations, in-depth analysis and visual presentation.
What we learned
Constant communication is essential, as cliché as it sound, numerous people try to cut corners by not involving users, developers or the business at every step of the project. Also, having a track record of what was discussed, when and why tremendously help in moving towards the best solution. Otherwise, there is a lot of time wasted catching curve balls.
Change management can't be addressed with a new product/solution only. You can ship the best product in the world, if people have no interest, constraints or benefits to change their habits, they simply won't. That is why bringing people with you in your project is of the utmost importance.