Case Study | DealRoom — Web App Dashboard

DealRoom is a virtual data room designed to automate the M&A process.

This case study is about the second UX client assignment from the DESIGNATION program. The challenge presented by our client DealRoom was to conduct a human-computer interaction study to determine the users’ (investment bankers) unmet needs for a data room dashboard.

Given these conditions, the team decided to use an HCD approach to define the users’ needs.

Discover

The most interesting part of working on this project was that we started with the work of a previous group. This group of designers conducted the initial domain research by interviewing more than ten experts in the financial industry. As a result of their research, they created a customers’ journey map based on the different type of stakeholders in the M&A process.

Not only do they studied the market the also created a redesign of the entire DealRoom platform. However, this is where we came in.

The DealRoom founders were not happy with the final deliverables of the former team due to the unaffordable technical debt that their proposed design will incur. Additionally, current users of the platform were demanding a dashboard interface from DealRoom. Since for the most part, they were pretty happy with the current set of features. Nevertheless, we decided to put their previous redesign in front of users and test it.

DealRoom’s Prior Design

Define

To avoid any biases and preconceived ideas. We conducted more than 15 stakeholders interviews ourselves. Mainly focusing on the actual end users of the data rooms, the associates at the investment banks.

With the research goal of wanting to define what a data room dashboard would look like. We quickly learned that what users meant by dashboard is the frustration of not having a way to quickly visualize their data room reports — without having to cut the data themselves.

Given that the most frequent reports run by associates are:

• Buyer Activity — with the purpose of gauging buyer interest
• Content — with the purpose of budgeting and billing
• Permissions — with the purpose of data security and compliance

Usability Testing

During the interview process, we took advantage of the fact that we had an already released product. So after completing the exploratory part of our discussions, we had users test the current platform. As a result of this, users expressed multiple concerns such as:

• Unclear charts without labels
• Not having filters for specifics timeframes
• The desire for the buyer, group, and user level information
• That showing an incomplete request percentage makes them look bad
• Not having a clear connection between document index and dashboard activity

Problem Statements

As a result of our interviews, we created an affinity map. Which let us draw multiple key insights about our users’ goals and frustrations such as:

• Activity reports don’t tell the full story
• Reports are used as one tool to gauge buyer interest
• There are standard key metrics that are necessary for activity tracking.
• Reports are only as good as the functionality and level of user activity inside the data room
• There is a tremendous opportunity for efficiency/productivity gain, but users resistant to change

So given these conditions, we decided to tackle this design challenge as three different problems:

• Improve efficiency with task management
• Let users dive deeper into the data room activity
• Provide an accurate picture to gauge buyer interest

Strategic Guidelines

Based on these problem statements, we defined the following strategic guidelines to help us design a useful and user-friendly dashboard for DealRoom customers:

Competitive Metaphors

In our competitive analysis, we discovered numerous data room providers such as IntraLinks, Merrill, ansarada, etc.

However, none of them offer the comprehensive solution our users were asking for — automatic and easy to understand data visualization. Additionally, our visual study of these platforms informed us that their priority is document storage and handling — not user experience.

Given the lack of innovation on the M&A market, we went for far remove ideas and services like zendesk and DataHero — in search for the perfect dashboard.

Develop

After brainstorming as a team, we decided to divide the problem statements among ourselves. I decided to focus on the data visualization of the dashboard with the additional constraint of only using the activity logs that the DealRoom currently tracks.

DealRoom’s Prototype 2.0

Prototypes on hand, we quickly started a new round of usability testing to discover how would users respond to our design decisions — we had mixed results. Users love many aspects of the dashboard like the automation of reports and lines charts. However, other users dislike the overload of information and the way additional features were offered.

Interactive Invision Prototype

Deliver

Before I introduce you to the final results of this project. I want to discuss the importance of talking to users and conducting multiple usability tests. The key advantage that we had while solving this design challenge was that as a team we all addressed different user’s pain points. Which led us to discover some critical overarching themes that we applied to the final version of the dashboard such as:

• Users want the most information possible in a single view
• Users want activity tracking at the document and user-level
• The preferred method of data visualization are the line charts
• Users have a strong desire for more filtering and automation capabilities
• Users see buyer engagement as a relative function of the number of actions across time due to documents interactions

DealRoom’s Final Dashboard

Interactive Invision Prototype

DealRoom’s Annotated Wireframe

Design Specs Document

In conclusion, DealRoom’s leadership really like the final concept we presented to them — because it was clean and straight to the point. Solving for the users’ demands of having a dashboard that could tell them the level of buyer interest at a single glance. The founders especially love the idea that our charts were only using data that they were already collecting. Which meant that the implementation of this new redesign did not have the same level of technical debt than the one previously offered — by the former design team.