Testing revealed that a single dashboard could not effectively address the distinct needs of both asset managers and brokers. By attempting to cater to both user groups, we made it more challenging for them to get value from the dashboard. We also found that the questions asset managers prioritize about their portfolios are not always relevant in the context of leasing meetings or consistently discussed in those meetings.

With this in mind, we refocused on the original problem—empowering brokers during leasing meetings—and began exploring alternative solutions for delivering value to asset managers, such as dedicated dashboards tailored to their specific needs.

Key takeaways from our research further informed our approach:
- Users primarily interact with data on a per-asset basis, rather than through side-by-side comparisons.
- Granular insights tend to provide more actionable value in most scenarios.
- Simplicity is crucial—streamlined dashboards are more impactful and easier to use.
‍

Our partners at Looker provided the scalable solution we needed. They introduced us to the possibility of building a custom component library within their platform and embedding dashboards in VTS using an iFrame. This approach allowed us to achieve scalability with minimal engineering effort by enabling non-engineering teams to design and build dashboards seamlessly once the component library was in place.

All that said, the project's scope and direction shifted significantly at this point. While we continued testing and refining the content of the LAR dashboard, we also conducted additional research to identify what was working and what wasn't with our current BI tool. I then collaborated closely with our business analysts to define the requirements for the new components based on these insights. After selecting Charts.JS as our charting library, we moved forward with the design process.

With the introduction of the new component library, there was significant internal conversation regarding what was to be released. The main focus and first release would still be the LAR, but beyond that we would plan to release 10 additional dashboards and several other features.

We would then package this all together as a major platform launch that would uplevel the product from VTS -> VTS4 in the eyes of our customers. It became a cross functional initiative supported by multiple teams and sponsored by our co-founder.

As we introduced the new Looker component, we continued to focus on our initial goal of 'empowering brokers during leasing meetings' by refining the dashboard alongside our users. The recurrent theme of condensing the dashboard remained. Brokers value insights that are quick to grasp and directly relevant to their goals.

While mildly interesting, marketing trends and upcoming expirations were either already addressed by existing reports or not actionable enough. Similarly, tenant sentiment may be valuable to asset managers or landlords, but would be more work for brokers and could actually deter them from sharing the report at all. With that, we found success in keeping the MVP highly focused on clear, meaningful insights that saved time and facilitated leasing efforts.

Through testing, we identified a key issue: brokers discoverability of the dashboard was low because they rarely used the Insights tab. To address this, we needed to meet brokers where they spent the majority of their time—the Deals page.

We explored several options for placing the call-to-action and ultimately positioned it near the existing export options for other leasing activity reports. This placement aligned with brokers existing workflows, minimizing cognitive load and ensured the button was easy to find. Testing validated this decision, yielding a near 100% task completion rate, which confirmed it as the optimal solution.

Once the designs and components were completed, we passed the final wireframes to our BI team to bring them to life using Looker. This is where some of the benefits and drawbacks of using Looker came to light. The benefit was that our BI team could make rapid query and dashboard changes because it was powered by Looker. The drawback was that the QA process was very extensive because it had to be done within Looker as well as within our app.