Global energy company (NDA)

A platform to update stakeholders in a crisis situation

Exploratory research 

Project Overview

Client: This client is a global energy company operating in 70+ countries.

My role: User Researcher

Timeline: 2 weeks

Tools: WhatUsersDo (now UserZoom), Google Suite

Research methods: Discovery research, Remote unmoderated testing

Deliverables: A report outlining what priority features to build into new company tool backed up by user feedback

The problem

This client was in the process of creating a new website feature that would allow users to view critical company-related news updates as a timeline. The primary purpose of the timeline was for use during a crisis period and the objective was to display events in a clear overview so that users could have a complete understanding of the situation. 

The client’s designers had come up with an initial prototype that they wanted me to conduct testing on to see if it would meet users’ needs.

Strategy

When I first met with the client and ran over the proposal the first thing I wanted to know was whether any initial user testing had been done and how did the designers come up with the prototype and what features to include. 

The short answer: there had been no testing and the designers created the prototype based on what they thought users would want out of it. 

I worked with the client to let them know why it was important to conduct user testing prior to beginning the design process, especially when launching a brand new feature that was sprung from what the business thought ‘would be a good idea’. I proposed to conduct testing with users that were experiencing a major real-time critical event that was being covered by multiple media sources to see what kind of information and features were important to users who were experiencing a critical event, and why.

The research question I sought to address was: What are the top aspects of a crisis timeline that are most important to users?

My process:

1. Client kickoff meeting

2. Create discussion guide

3. Choose comparison websites

4. Launch test

5. Synthesis

6. Takeaways

1. Client kickoff meeting

My first step was to understand what the client truly wanted to achieve from this project. The kickoff meeting was required to better understand the client’s objectives, where I could then suggest my recommended methodology to carry out the research. 

I suggested to have users experience a critical event in real-time so that as a real event unfolded they would be able to communicate what information was important for them to know as it was happening. The one obvious drawback with this idea was that I could not predict when a major event would occur so it could be a great deal of time before we could actually collect any insights. To mitigate this issue I kept an eye out for events that were happening worldwide. As the client was a global company I had the flexibility of testing with users anywhere, be it North America, Europe or APAC. 

Based on where the event would take place and thus, where the recruiting would occur, I proposed to choose 3 media sources users would read over to compare the event coverage, which would then determine what features and information would be important to know when undergoing a crisis.

2. Create discussion guide

I created the discussion guide (or rather, the task list) prior to knowing what event users would be reviewing. I had a general sense of what I wanted to find out so my main purpose was to have the discussion guide in as complete of a state as possible so that once I knew what event was to be covered all I would have to do was make slight tweaks to the guide and get the testing started as soon as possible. 

One thing I wanted to ensure in the task script was for users to review the websites in varying order so they would not be affected by any biases from viewing a website first or last. 

3. Choose comparison websites

As luck would have it, a hurricane started brewing in the UK shortly after the project kicked off so I chose three British media sources that were offering various ways of reporting and displaying information and updates for Hurricane Ophelia: BBC, Evening Standard, The Guardian.

4. Launch test

With the event now chosen and the location determined, I made final tweaks to the discussion guide and launched the test to seven participants based in the UK on the WhatUsersDo (now UserZoom) platform. I had a screener that ensured that only those who were following the Hurricane Ophelia event would partake in the test. 

These tests were taken remotely and screen recorded, with videos available within 48 hours of launching the test.

5. Synthesis

With all the videos in I started the analysis, which involved watching the video recordings and noting down important insights which I completed in a spreadsheet. Here is a snippet below: 

Video clips of users reviewing the websites were also captured and tagged to input into the final report to support the final recommendations. 

When determining the prioritization of features I took into account the number of users who found a feature useful and how important that feature was for them. 

The final report consisted of:

• Key findings and their level of importance (low to high importance)
• Answer to the research question: What are the top aspects of a crisis timeline that are most important to users?
• Evidence to support the recommendations
• A recap of the project, including pros and cons stated by users for each of the websites reviewed
• Suggested next steps

6. Takeaways

When working with stakeholders it’s important to have the confidence to push back on proposals if you don’t think it will lead to a good outcome and to be well prepared to back up your methodology if challenged. Although clients/stakeholders may come to you with a list of requirements a researcher needs to have the capability and confidence to communicate alternative proposals in the interest of achieving the desired outcome. The bottom line is to clarify what the underlying objective of the project is and for all parties to work towards that common goal.   

It’s also important to weigh out the balance between risk and achieving a goal. I had the choice of going with a ‘safe’ methodology where I would have more control over the project but knew I wouldn’t achieve the maximum benefits of testing. Ultimately I opted to go for a riskier methodology since my method relied on events happening that were out of my control, but would give me greater insights if it worked out, and would use the safe methodology as a backup plan.

I communicated with the client the pros and cons of each idea and they ultimately trusted me to make the right call which methodology to go with.