How PwC team used wireframes & report prototypes to answer the right business questions

12min read

To make your report successful, it is crucial to first understand the needs of the end users. This lets report creators know which questions should the report answer and which problems should be addressed.

Since this is often easier said than done, this customer story focuses on the importance of report prototypes & wireframes. The iteration process and continuous feedback collection are crucial components leading to efficient reports and effective meetings.

Hear it from Michael Schneiders, Enterprise Architecture, Data Transformation & Strategy at PwC, who shared how his team used the design thinking process to understand what their users wanted, built wireframes, and went through multiple iterations to successfully prepare guidelines for report developers.

PwC Case Study - 15:56

The DaVinci project or the biggest digitization project at PwC

Michael has been with PwC for over 4 years and leads the data transformation & strategy team. They were heavily involved in the DaVinci program which was the biggest digitization program PwC ever did. It had two major goals. The first one was Europe-based and related to the harmonization of the contact-to-cash process. The second was to replace the given system of records (CRM, ERP, and HC) on a global level.

The first goal was related to the standardization of PwC Europe reporting. After some research, the team decided on Microsoft Power BI together with Zebra BI custom visuals as strategic tools. To truly accomplish their goal, they provided all employees at PwC with a license for Zebra BI, so that it can be used globally on any report.

By changing the processes and technology, the team wanted to redefine the reporting scope and harmonize reporting on the most important reporting dimensions like client, business unit, engagement, and further dimensions on the European level (Austria, Belgium, Germany, the Netherlands, Switzerland, and Turkey).

Facing the challenges and targeting users' needs

During the period of changing processes, technology, and reporting scope, the team was looking for the best approach to tackle this. One of the biggest challenges was figuring out the real users' needs.

In a large organization like PwC, different territories have different requirements. For example, larger territories like Germany and the Netherlands already had a mature reporting organization and had different mentalities in place as opposed to smaller territories like Austria or Belgium where reporting demands are different. To illustrate, in the Netherlands, the need for diversity reporting is much more pronounced than in Switzerland.

Additionally, during feedback collection on the old reporting, the end-users would say that those reports tend to contain a lot of data, but in the end, they were looking around for data that they actually needed. So another important input for Michael and his team was to ensure that with the updated reporting system, users' perspective is put in front.

Design-thinking approach to deliver reports that answer key business questions

To determine how future reports should be designed, they used the PwC Best Experience Technology approach. It is a framework based on the Design-thinking approach. This refers to an iterative process teams use to better understand end-users. This often results in challenging predefined assumptions, redefining problems, and creating innovative solutions based on numerous prototypes and wireframes.

To accomplish optimal outcomes, this framework is set into two spaces:

  • A problem space that refers to scope definition, research, and problem redefinition
  • A solution space that consists of a storyboard/storyline, wireframe, and final implementation.

Scope definition, research, and problem redefinition

At the beginning of such a project, it's very important to define the scope of it. It will allow you to really understand the analysis's focus.

Michael's team began with basic information that could fit on one page, referencing high-level inputs. This included: the dashboard's goal, the main users, the product owner, the list of subject matter experts (SMEs), the main responsible person, and those behind the development wheel.

2. Research time

During the research phase, they conducted several interviews with SMEs coming from different departments, such as IT, business, and controlling, and various territories across PwC Europe. This way they made sure that different points of view were considered and different demands were included.

After giving them initial information and presenting the goal to ensure common understanding, it was very important to let the interviewees present themselves. They shared information about their job role, responsibilities, and how they typically use the existing dashboards.

Michael's team learned that instead of directly asking 'What data do you need?' or 'What is the information you want to see?', you have to use a different approach. It's better to ask questions like:

  • How do you use the dashboard?
  • Which problems are you trying to solve?
  • Which action or decision are you taking from the dashboard?
  • What is the key information you're looking for?
  • What business questions are you looking answers for?

Such questions leave you with a much better understanding of the actual usage of the dashboard and the needs the viewers have. Only after understanding these, you can proceed with asking more specific questions such as which data is being used, what is the frequency and what kind of functionality are they expecting.

On average they did pair report interviews with 25 SMEs, and they had a huge list of business questions. This allowed them to really understand which demand came from which perspective.

3. Problem redefinition

After thorough research, the team had enough information to redefine the dashboards' purpose:

  • What are the guiding principles (will it be available online or not, etc.)?
  • Which information should be covered in each area?
  • Which insights should be included (e.g., comparison of the actual performance with the previous year, budget, or forecast. With Zebra BI you even get the automatic variance calculated out of the box)?
  • Which features should be included (filters, push messages, monthly updates, etc.)?

Having all of this listed allowed the team to understand the real users' needs. Since the feedback was collected based on extensive interviews with people from different departments, it led to a really clear problem redefinition.

They aligned it again with all SMEs and got the final buy-in from everyone: the management, IT, business users, and controllers.

The dashboard met users' needs and gained wide acceptance

Only when you really understand the problem, you can start with the solution.

4. Create a storyboard and storyline

The PwC team met in Frankfurt to come up with a storyboard and storyline. The main purpose of the workshop was to understand the reporting objectives and which business questions would derive from them based on different perspectives (sales, operational, client, etc.).

This was a good approach because it allowed all teams to work together and align in person on which functionality to use in which area. For most of the questions, it was more a confirmation of the interviews they did in the previous phase. However, it was also beneficial as they could ensure the right demands were met and the dashboard contained the elements the users asked for. In the end, the team fully understood which parts were needed during dashboard development.

5. Preparing data landscape & wireframes

This led them to the creation of the first page which covered the most crucial information for everyone. It contained all the data users wanted to see when opening the dashboard. To continue from there, viewers had 2 options. The first one was to continue the predefined path created based on the value chain of how engagement management reporting should look. However, there were also shortcuts on the first page enabling report users to go directly to the detailed pages they were most interested in.

They defined page by page and tile by tile which data should be displayed where. They offered a broader story but also filters so people could immediately understand how they could filter the data. This allowed them to also include some new functionalities like job-to-date and engagement-to-date. Besides the usual year-to-date or fiscal year-to-date, this was something completely new. For the first time, it was possible to analyze the performance of an engagement from the beginning of it until a certain period. This is especially useful for longer engagements like audits that sometimes last even longer than a year. This really helps users to understand the performance in the long run.

From my own experience – when you show this to the users it’s very hard for them to understand actually how all of this will look like in the end and it’s hard to get buy-in.

Michael Schneiders
Enterprise Architecture, Data Transformation & Strategy, PwC

Because of so much information, this was the point when wireframes became crucial. Michael’s team at PwC used Power BI with Zebra BI visuals and Adobe Experience Designer. The page from the previous image is now displayed here as an engagement one-pager with crucial information. The benefit of a wireframe like this is that before full implementation, they could discuss with stakeholders if this matched their needs. They needed multiple iterations to achieve the final structure.

During the process, they learned that the preferred way of ordering data depends on the person looking at the report. They went through several iterations of wireframes and corrections. For example, in the first update, they redesigned the data used. The second proposal focused too much on the past so they also added some forecast information to the third version. After aligning several iterations, they reached the middle ground for everyone.

6. Implementation

With the final wireframe being confirmed, the dashboard went into live implementation. Because it considered all user needs for different departments, the team has gained huge user acceptance and this has become the reporting norm across all areas of the firm and all territories.

PwC's final recommendations for the successful use of wireframes & report prototypes

Since this is a long process with many steps and many people involved, Michael prepared a short list of recommendations to follow to reach the best outcome:

  1. To make sure your end result matches the needs of the end users, follow the iterative approach and involve them in multiple discussions.
  2. After each feedback session align the data and align the wireframes created based on the users' inputs.
  3. Help end-users visualize the report by creating prototypes to show them what it will actually look like.
  4. To reduce your work, first, implement only a very small prototype. It's best to select the most used page with information important to all users and make it clickable in Power BI.
  5. Based on the feedback on this prototype, arrange further discussions and alignments, refine it, and after internal buy-in from everyone involved use it as a base for implementation.

Ready to start answering the right business questions with your reports?

Explore Zebra BI in Power BI for free and see how easy it is to turn all business-critical information into immediate insights.  You can also contact us to help you build your first test report or create a custom offer for your business.