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.
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.
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.
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.
Interviews with business operations & finance personas painted an unflattering picture.
Users were struggling to answer three main questions about the data represented in Panorama:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.