How do we conduct the discovery phase when working with a newsroom?

Written by Elwira Majewska and Grzegorz Wiktorski, UX Researchers at Autentika.

Let’s admit it: media are complex organisms, and so are the solutions we develop for them. That's why we rely on proven processes and methods when collaborating with a newsroom. We'll show you how we go about the discovery phase – so you can tackle your next digital project with peace of mind.

Listen to the audio version of this article or read the transcript that follows below the player

"We'll see, we'll figure it out later" are probably the worst words you can hear from a team developing a back-office system for your newsroom. You do not want white space in your plan; you want a well-defined scope of work and transparent pricing. That's why at Autentika, we have developed a process that ensures both parties' needs are met.

In this article, we will share some of our most valuable insights about the discovery phase – the initial stage of our collaboration. It is a crucial moment for both sides – and that’s because before we start working on a new CMS or editorial software, we need to drill down to the bone of your system. We need to learn as much as possible about the existing tools and problems users experience when interacting with them – all to deliver a functional solution that your team will love and that will help you achieve your business goals.

Importantly, our role extends beyond identifying CMS weaknesses and remediating them. The discovery phase and the time we spend with your team allows us to see "the "big picture": processes around tools, workflows, habits and behaviours of users in their natural environment. All that happens in the workplace "around" your tools and software can be critical to developing optimal solutions.

For us, there's no room for "we'll-seeism". We tell you what to expect and give you a clear idea of what's coming next. Of course, in the interest of this text, we generalise and simplify certain things, as collaboration details depend on many aspects – but here is our basic framework.

Main objective:

To learn the basics about your media company: numbers, structure, workflows, division of responsibilities, and to define the fundamentals of our collaboration: communication channels, people involved, and tech stack.

Some of the questions we ask:

• What is the organisational structure and the editorial structure?
• How are the roles in the editorial team distributed?
• How many people work in each newsroom, IT and UX /UI departments?
• What are the basic workflows in newsrooms?
• Do you work remotely or in a hybrid mode?
• What kind of content do you produce?
• What is the daily content production volume?
• What external and internal tools does the editorial team use?
• What is the team's general opinion about the tools?
• How do you measure the work of the editorial team?
• What innovations or major features have you introduced recently?
• Who will be involved in the project at each stage?
• Who will be the early adopters of the developed project?

Participants:

• C-level
• IT department
• Product owner
• Analytics department
• Newsrooms representatives
• Marketing department
• Graphics team
• Design team
• Graphics team

Why we do it:

As you migh conclude from the questions, at this meeting, we lay the foundation for the entire collaboration. It is critical for us to learn the basic facts about your organisation and understand the newsroom structure, as well as your general tech needs and expectations. We will be collaborating for quite some time, so we need to know who is who, how people work, how tasks are divided, and who the key stakeholders of each project phase are.

We also decide on the technical setup, communication channels, and software we’ll use, and ask for necessary documentation and access to tools and systems. All this helps us plan our work and present a realistic schedule to the client.

Main objective:

To learn the project’s primary goal and grasp the "big picture": the business vision of the project and the motivation for change.

Questions we ask:

• What is the strategic business objective of the project?
• What is the motivation for change?
• What has already been done to change the existing situation?
• What challenges and obstacles has the client encountered along the way?

Participants:

Key business stakeholders involved in the project.

Why we do it:

This meeting allows us to understand the project's essence and business perspective. We are UX designers – but to design a good product, we need to understand the business motivation behind it. We know that sometimes there can be discrepancies between business requirements and user needs – so it's vital to hear arguments from both sides. This allows us to produce a clear scope of work at the end of the discovery phase.

The discovery meeting also confirms previous arrangements and agreements on details regarding the work calendar and task list.

Main objective:

To learn how the current editorial software and CMS work to determine the "as-is" status.

Why we do it:

Documentation analysis helps us shorten the overall research phase. Reviewing existing manuals and instructions can save time because later we do not have to ask our interviewees about them again. The more documentation the client has, the less time we need to spend looking for details.

However, missing documentation is not an obstacle for us – if necessary, we obtain all information directly from the users and interviewees.

Main objective:

To learn in practice how the back-office system/editorial software/CMS works.

Why we do it:

Having someone - usually the product owner - walk us through the system, allows us to see how it "officially" works. This saves us time because we start the survey phase already with a basic knowledge of the tools and the software. Often the surveys reveal much more about the system - shortcuts, exceptions, and workarounds that users use when working with the tool.

Main objective:

Get an overview of the state of software and processes and learn as much as possible about existing user problems.

Participants:

System users: journalists and editors. The size of the group depends on the particular newsroom; it can be between 50 and 150 people.

Why we do it:

Surveys are essential for us to grasp, analyse and summarise the main problems of the existing system so that we can better prepare for the next phase of one-on-one interviews. The detailed and exhaustive questions give us a deep understanding of how the current tools work and how users engage with them during their onboarding process. The scope of the surveys allows us to list the most common and burning issues and better use the time needed for IDIs.

Main objective:

To learn more about the users' working environment, to put oneself in the role of the system user.

Participants:

• Journalists, editors, desk editors, chief editors, producers (selected by the client)
• People who use the existing system daily
• Employees with both long and short tenure and various levels of work experience

Why we do it:

IDIs help us go deeper into the topics we already know from the previous research phases and add an emotional layer. When we talk to people face to face, users are often more open and willing to share their observations and pain points. The fact that we are outsiders helps a lot, as we can notice things invisible from the inside.

Main objective:

To learn other departments’ needs and requirements concerning the future system.

Participants:

• SEO department
• IT department
• Analytics department
• Marketing department
• E-commerce department
• Advertising department
• Video production team
• Photo team
• Design team

Why we do it:

Talking to people who will have contact with the future product helps us learn their needs and perspective. Then we can take them into account when designing new solutions.

Main objective:

To gain a more nuanced and comprehensive understanding of users' behaviour, needs and problems to complement other research methods.

Participants:

Selected journalists, editors, desk editors, chief editors, producers.

Why we do it:

Ethnographic research is the research part done always physically in a newsroom (on-site). We observe users in their natural work environment (newsroom), which helps us uncover needs and pain points that we may not have caught with other research methods. By more extended and immersive observation and data collection, we get the complete picture of the situation in a newsroom.

Read more about ethnographic research here.

Main objective:

To initiate a moderated discussion among members of a selected group of people and gather detailed information on a specific topic.

Participants:

Selected representatives from newsrooms/newsdesks and various departments, usually a group of 3-7 people.

Why we do it:

Focus group sessions help us better understand problems we have previously diagnosed during the research and delve deeper into specific topics. Those sessions take the form of structured, facilitated conversations. We proceed according to a scenario, which helps participants focus on a selected topic, activates them, and encourages them to formulate their thoughts clearly.

Main objective:

To report on our work, summarise current activities and results, and prepare the next steps.

Participants:

Stakeholders involved in the project, our contact persons in particular departments.

Why we do it:

Weekly meetings give the client a good orientation on what is going on in the project, what has already been done. They also help us organise our work, plan next steps and choose new participants of planned conversations. Weeklies also give us a chance to flag any obstacles or roadblocks that appear, request additional meetings, or access to software and documentation.

Each of the above steps is followed by the analysis and summary of the results. We collect all the information, user responses from surveys and IDIs, problem descriptions, and challenges people have with systems and tools.

We include our findings and conclusions in the project documentation so that the client receives a comprehensive synthesis of the entire exploration process.

How long does a discovery phase last? The answer is: it depends, but to give you a rough estimate, based on our experience, it's 10-12 weeks.

The most important result of this time spent with your newsroom is a comprehensive document that includes:

• the synthesis of the problems and challenges of the existing system,
• tools and processes the summary of our findings and conclusions
• the basic process modelling
• the scope and basis of future solutions

As mentioned earlier, the main goal of the discovery phase is to understand the problems your organisation is facing and propose solutions on how to solve them. You'll get a clear idea of what needs to be done next and what the design phase will look like – so both parties know exactly what they need to do and what they need to work on.

Sometimes the flawed onboarding process for new journalists leads to them not knowing CMS properly. Sometimes it's equipment or communication issues.

We want to emphasise that we always strive to develop a solution that addresses a specific problem. Editorial teams are very different – so there is never a "one size fits all" solution. That's why we need all this time and effort – to avoid the "trial and error" method and focus on what is really necessary.

Being "outsiders" helps us a lot in this process – we're objective and unbiased in our observations, and we aren't here to tell you that you have a faulty system. We're here to develop the best possible solution for you: one that is functional for your employees and helps you achieve your business goals.

Talk to us if you'd like to learn more -- >