Rethinking Organizational Hierarchy Systems on Paces Portfolio Page
Role: Designer, collaborating with 1 engineer
Context: Paces is a software that helps green energy developers identify the best plots of land for building and managing projects
Task: I created a V2 of the Portfolio Page by adding a folder feature and revamping the UI as a solution to the question:
How can we transform Paces into an end-to-end workspace?
Here’s what I came up with:
“It’s so much easier for our team to work on the portfolio page now. . .we’re really excited to see how this impacts our site origination process.”
— Albert, Chaberton Energy
So how’d we get there? First, some context...
Parcel vs Project vs Portfolio
The base unit used in the Paces universe is a parcel, a discrete plot of land owned by someone.
Projects are groups of parcels, and this concept arose because a large solar developer might need a large piece of land that is bigger than 1 parcel. They might need a bunch of connected parcels. During the Search flow, users can turn on a filter for “Project Search” which will result in Projects containing adjacent parcels.
Portfolios are folders that contains a list of parcels and projects.
The Problem: Lack of Organizational Tools
Although this was the intended way of using projects and portfolios, the flexibility of projects started to cause some fraying in these systems. Because users can create new projects and ad-hoc add parcels or even modify a search-generated projects, users began to use projects as folders. Although projects were created as a “super-parcel’ concept, users began using projects as portfolios.
We heard from customers like Albert who presented a perspective into why people would use Projects as folders.
“Each salesperson on our team has their own prospecting folder. So to make things easy to find across the whole company, we decided that it’s easiest to have one portfolio for each person, so we can’t break it down further below that — besides using Projects.”
This led to many pain points, because the table UI of Portfolios wasn’t designed to accomodate projects with hundreds of parcels strewn across the US. For example, the graphic below shows an example of a project being used as a portfolio with 1300+ parcels, and overflowing the location column.
Not only was the Portfolio page missing a layer of organizational hierarchy, the UI made it so that these “alternative” ways of using the product would create extreme hinderances in usability.
Foldering Explorations:
Hearing customers’ perspectives reinforced the need for another layer of folders on the portfolio page. I explored both creating a folder level under portfolios and one above portfolios.
After comparing these options and discussing with the team, we decided that a folder level under portfolios required more intrusive UI changes to the portfolio page. This was a pretty high priority/urgency re-design task, so it was important to find a solution that did not unnecesarily impact other pages.
From here, we scoped out the specific flows and actions that would be necessary to have on this new Folder Dashboard. This included the ability to search, move portfolios, and create a new folder.
Portfolio Page Improvements -
Once the folder dashboard was designed, I turned to the Portfolio Page itself. The earlier mentioned overflow behavior still made the Portfolio Page incredibly unfriendly for users.
The table UI of the portfolio page was designed for single parcels and not yet optimized for projects. For example, because a project might have multiple owners, in the Owner column info, the overflow renders the whole table nearly un-usable. See the video below for more examples.
The overflow behavior presented a couple of usability challenges:
1. It’s difficult to know what parcel or project you’re looking at
2. It’s incredibly difficult to parse through the large blocks of information.
In response to issue 1, I decided to fix the Parcel/Project panel in the following designs, so that there would always be a reference point for the parcel/project. In addition, explored a few ways of managing the behavior overflow.
Ultimately, we decided on the quick view because for some of these projects. There’s so much information that you need more space to clearly display all the inforamtion.
Project Content
I also decided to rethink the way this content is displayed for Projects. Previously for columns like “Insights” each Parcel’s Insights were displayed individually, despite the goal of Projects to be presenting a Super-Parcel. Additionally, Insights are generated based on different search criteria relating to grid preferences — so depending on the search, there could be multiple different sets of Insights all being clumped into one “Insights” column.
With this in mind, I decided to separate Insights into specific Insights columns, in this case, a HIFLD Substation Insight and a HIFLD transmission Insight column. Additionally, I decided to display Insight Overviews for the project on the table view, highlighting the Criteria and Linear Distance, the two most important pieces of information needed at a glance. And then in the detail view, I decided to include both the project overview and the parcel breakdown.