FiscalNote Stakeholder Search

The Product

FiscalNote supports organizations to monitor, manage, and act on the issues that are important to them by combining policy and stakeholder data with AI technology and expert analysis.

The Challenge

Stakeholder data lived separately on the platform (legislators were in one place, custom/user generated contacts in another, and state and federal executives didn’t exist). In order to even allow users to start doing stakeholder management, we needed to be able to have a one-stop-shop of where all stakeholder information lived. Since all data came from different third party sources, the structure was different for each stakeholder type.

My Role

As lead designer on this team, I facilitated all user interviews, synthesized the findings, worked with our UX research team to do prototype testing and usability studies, designed the interface, and worked with the product manager and engineers on pushing for certain features to be prioritized in order to meet our users Jobs to be Done.

Discovery & Jobs to be Done

We interviewed over 15 clients to better understand how they do their jobs and what role does stakeholder management have in their day-to-day life. We were able to highlight pain points not only in their everyday life but within the platform as well.

Jobs to be Done

  • Identify for important stakeholders (governors, legislators, etc) in order to see if they are beneficial to my issues (for issue tracking).

  • Log meetings, calls, or any interactions with key stakeholders and make sure my team has insight into these interactions

Major Pain Points from User Interviews:

Card Sort

We gathered all the existing background and research we could find and created a cardsort of over 150 user stories to be prioritized by key stakeholders. This would help us get feedback and buy in from folks directly on the team and people who would eventually be more engaged later on in the project, such as engineers, business stakeholders, etc.

Journey Map

We then mapped out our user journey for Actions, grounded in the Issues Management framework instilled in our product and Jobs to be Done for our users, reflecting the phases 'Research > Plan > Execute > Measure'.

“Current State” Audit

We conducted a current state audit of the platform to ensure our team was coming from the same understanding and worked to identify painpoints and heuristic considerations to inform the future state.

Guiding Principles

The output from Discovery was a list of prioritized goals and high level feature areas to be prioritized by impact based on usability metrics, stakeholder input, and customer revenue. Our hypothesis is that we believe we can increase the value and adoption of our users by:

Conceptual Design

Once we established the guiding principles based in research, each of the three designers explored conceptual designs to holistically solve the user goals outlined.

Flexible Actions

"Flexible Actions" presents all users with a configurable (by super-user) list of Action types, each with their own configurable fields, per organization. Flexible Actions empowers users to do what they need with their own data. Without the control to set specific action types and fields, users rely on outside tools to do most of the work needed to be done to produce the reports.

Our clients produce reports with Actions for their leadership teams. These reports need to have an infinite number of ways their data needs to be sliced & diced to be useful. The information varies for each user for the many reports they need to create, for the audience they are presenting to and the type of report they are creating, e.g. monthly vs quarterly reports, and what they are reporting on (information is different for each report). Users will have the field types they need at their hands rather than creating abstractions.

In the end, the whole Flexible Actions flow was descoped but we were able to implement the ability to have “custom actions” for users, which was a huge win.

User Research

The designs we aimed to test look to address the most severe pain points with the Actions functionality. The goal of this usability test is to validate the direction of the conceptual designs of the Actions Refactor project and to uncover major usability issues. The findings from this study inform iterations on the design before it is built as the final product.

Overall, we wanted to find out:

  • Is our product usable, especially in places where we don't have models for other features, like interactions?

  • Are these solutions the right fit for the problems they are aiming to solve?

  • Are there other opportunities for improvements we have not uncovered?

“The Drawer” Final Design

This prototype demonstrates how the various field types will manifest within the Create Action Flow. I was responsible for the detailed designs of the 'Create Action Flow Drawer' (shown below).

Actions “Entity Page”

This is the design of an Action profile page or “entity page” as we called it for users to view the action in detail.

Create Action Final Designs

These are the final designs and specs for the field types that can be configured to appear for a user creating an Action.

Next Steps

Ultimately, the team and project pivoted several times due to changes related to the foundation of the technical implementation.

The team launched the MVP of Actions in June 2021 and will look forward to adding the functionality in-line with the Next Generation Product strategy, and will include robust CRM features around alerting, task management, and data science enhancements. Now that the MVP of Actions is in the hands of our users, we will get feedback and continue to iterate through the next phases in our build out.