Enterprise Product Design

VMware Panorama Project History

  • Timeframe: 25% time for 4 Months (2022)
  • Primary Collaborators: Eugene Fabian (PM) • Alex Lobasciano (Engineer) • Ian Fisher (Engineer)
  • Personal role: Lead Designer & Researcher, collaborating with one Product Manager and several Engineers
Highspot Licensing


When customers expressed distrust in our enterprise resource management tool’s data, I conducted research to understand the root cause and proposed work to address the issue. In collaboration with the development team, we iterated on a project history feature that increased confidence in our product while reducing support requests.


Project Context

Panorama manages details of projects and the people assigned to them. Managers at VMware use the tool to staff projects and plan schedules for software development teams. Business Operations & Finance teams consume this data to generate insights to evaluate the company’s resource investments.

In customer support channels, I observed confusion and uncertainty around the quality of our data and the perception that our product was buggy. Lack of trust in our data was undermining leadership’s faith in Panorama and jeopardized future investment in our team. These support requests made up approximately 20% of our monthly tickets.


Research Process

The customer support issues seemed clear to me, but the team needed more evidence that this was a priority issue. I began with a single research question: What’s contributing to these personas’ lack of confidence in the data we generate?

Thematic analysis of customer support tickets and a series of interviews with business operations and finance partners were conducted.

Research synthesis
Research synthesis was a team activity, with Project Managers and Engineers contributing their own insights.
Research Collaboration with Product Manager & Developers

Transformation Products is an unusually collaborative team - instead of focusing on fixed roles, we support each other toward shared goals, regardless of role. After I conducted synthesis and insight generation in Miro, I hid my conclusions and asked both the product manager and developers to evaluate the data and draw their own conclusions. The additional perspectives generated unique insights while helping to level up the team’s comfort with ambiguity.

Research Findings

Interviews with business operations & finance personas painted an unflattering picture.

Users were struggling to answer three main questions about the data represented in Panorama:

  • “What changes are happening in my area of responsibility?”
  • “Where did this project go?”
  • “Who took that person off my project?”

Each unanswered question undermined faith in our product’s value and threatened customer retention.

With this in mind, I began asking how we might help people understand the changes being made to projects and assignments in Panorama?

These findings were successfully used to help the team understand the problem and prioritize an intervention.

Design Intervention

Product Strategy

Two interventions could address this customer pain: creating finer control of user permissions, and adding a project history feature

Enhanced Permissions: Panorama had an intentionally open permissions model - users could be either viewers or editors. Finer control of what a user could edit would prevent unauthorized people from making inappropriate or unintentional changes, lowering the number of questions about the data. This resolves some issues, yet does not help customers understand the remaining cases.

Project History: Adding a log of changes made to a project would help everyone understand the changes being made to projects. This would not prevent errors, but instead enable better conversations about the changes. The team felt that this solution would make a larger impact on trust in our data by optimizing for clarity over convenience.

Pattern Research

In enterprise software, many patterns are well established and it is not necessary to create every solution from first principles. I began the solution generation phase by researching history patterns in other applications.

Resources like EnterpriseReady.io were used to define a long term feature set while helping to focus our focus scope to today’s customer needs. While an advanced logging feature might include immutability and sub-millisecond timing, our first iterations could deliver value with only a simple set of actions.

In terms of user experience, products like Google and Zendesk often treat history features as an administrative tool to be used rarely. Both the integration with the core workflows and the level of craft were lacking.

Competitor examples
Event Logging in Google Admin Panel. Entries are difficult to scan and the level of craft is abysmal. Logs are separate from the context in which they are most useful.
Competitor examples
ZenDesk Logging. This pattern emphasizes the technical aspects of each event, making them unnecessarily difficult to read and discuss with other humans.

Development Collaboration

Throughout this project, I made sure that everyone understood what we were trying to accomplish and why it mattered. With a shared understanding of problems and possible solutions, we were able to identify cheap and expensive paths and make tradeoffs early in the design process. For example, an undo feature was found to be 5-25x the amount of work of a simple log, so we eliminated that path before spending any time imagining a solution.

With summer vacations approaching, I established shared design principles so that the team could make decisions autonomously and without waiting for all critical team members to return.

  1. Show human actions, not system events. Project history is a tool to help people have better conversations about changes made, not a forensic or technical tool. We shouldn’t include automated actions taken by our system.
  2. Absence of evidence is evidence of absence. If a person expects that a type of event (such as project dates changed) and the event is not included in our log, they will assume that no such change has been made.
  3. To this end, add history events in clear chunks that are easy to remember. We can’t log every event in our first iteration, but we can help people understand what classes of event are and are not logged.

UI Mockups

Our team released iterations every week, so it was important to outline both long term ideals and multiple smaller iterations along the way. Establishing a long term architecture helped developers build create near-term value while avoiding solutions that won’t scale to future iterations.

Design Pairing

Our team practiced pairing - working sessions where two designers could make decisions together with the benefit of differing perspectives. Thinking out loud and explaining decisions increased the quality of our work while encouraging accountability and decisiveness.

Making Complexity Feel Simple

Every project in Panorama has a set of attributes, such as name, dates, and contract status, that are displayed on the about tab. This work added a history tab to display human actions taken on the attributes shown in the about tab.

Each entry begins with the attribute being changed, followed by its previous and resulting status. This presents events in a human readable form that better enables conversations. The name of the person taking the action is linked to their email address, making it easier to reach out about a change that doesn’t seem right. Actions committed at the same time are grouped for better understanding.

RAbout Tab
The About Tab contains all of the project fields that can be changed and logged.
Version 2
Version 2, our terminal version. This includes the to and from status for each item and linked names.
Scope & Compromise

As we iterated toward a full feature set, much was left out of our initial releases so that we could provide value sooner and learn from feedback. Developers noted that displaying the to and from values would take extra work and push back our first release. We compromised by not displaying this data initially. Critically, this data was saved so that it could be displayed later. This avoided a future state with some entries displaying to and from data, and others without it.

Version 1
Version 1, our first release. This temporarily cut the to and from status so that we could deploy the feature and start delivering value faster.
Architecture and Future UI

I designed an extended project history view that could display entries within a business unit, conveying all changes within an operations manager’s domain. These new components and iconography built upon the team’s existing design system and established patterns for navigating hierarchy across Panorama.

Version 3
Version 3 provides an overview of all changes being made within a scope of concern, such as withing a business unit. This enables Business Operations and Finance partners to track relevant changes without visiting each individual project.


Reception & Impact

The team successfully completed versions 1 and 2 of project history, leaving staffing history and the overview page for future iterations.

Upon release, customers quickly came to trust the data in Panorama. We disproved the perception that Panorama was buggy, finding instead that changes were often being made by some teams without informing affected people. This helped affected teams have better conversations about the decisions being represented in Panorama. Customer support requests about data dropped from approximately 20% of tickets to 4%.

Some remaining changes were found to be made by accident. Often, managers who should only make staffing changes were editing projects that they should not have. In the following months, I worked with a developer to implement finer permission controls, reducing the number of erroneous changes.

Lastly, there was high demand from customers for additional features on our roadmap. The overview page was highly desirable for customers and also fit into our business strategy of providing a canvas for better conversations.