- The problem
- Reporting wasn't giving Sales Response Managers the data they needed to prove Loopio's value to their leadership.
- My role
- Product designer and researcher. I ran the exploratory research, a value/impact workshop and a focus group with Customer Success Managers.
- The team
- A scrum team of engineers, an engineering manager, a project manager and the design lead, supported by a senior UX researcher and a data scientist
- The outcome
- Shipped quick-wins across the Projects, Library and Users reports: more robust filtering, a better horizontal scroll experience and more metrics.
Loopio is a product that aims to increase efficiencies and empower sales response teams when responding to RFPs (Request for Proposal), DDQs (Due Diligence Questionnaire), SQ (Security Questionnaires), RFIs (Request for Information), and more.
When tasked with increasing adoption of Loopio across an organization, it becomes critical for Sales Response Managers to make a case to leadership of the value that Loopio provides, this is where Reporting steps in.
Before any new research was done I looked at past research which informed some of the questions I would ask in the first round of exploratory research:
- What part did Reporting take in their roles?
- What kinds of outcomes were they looking to achieve?
- What metrics and insights would help them achieve these outcomes?
- How would they envision a future version of Reporting?
Because of some of the complexities of the project, its release was broken up into three phases:
- Phase 1: Quick-wins for each of the Reporting pages
- Phase 2: more dynamic data, new metrics, and data visualizations all powered by a new back-end data micro-service
- Phase 3: more investigation is needed, but larger goals include full dashboard customization, CRM integrations, and expanded access and permissions to Loopio Reporting
To determine the quick-wins I ran a value/impact matrix activity with core team members. The list of features was quite extensive, so I started with a round of dot voting to narrow it down to the ones we thought would have the most impact.
I ran a focus group with a few Customer Success Managers representing some of our largest enterprise customers. The goal was to validate specific design elements and fine tune the designs.
Problems I ran into:
My solutions:
ProblemReporting isn't used because many customers used Loopio as a point solution
SolutionExpanding reporting functionality, mainly more robust filtering, to make reporting more useful
ProblemReporting isn't used because of lack of actionable and relevant data
SolutionGreatly expanding the number of metrics available in Reporting
ProblemData cleanliness is an issue
SolutionMaking sure to help remind clients to clean test projects from their Loopio instance
ProblemComplexity of this project, which involved 3 different teams
SolutionRegular updates within and across teams, technical program manager helps coordinate across teams
ProblemUI interaction limitations exposed need for a more robust set of interactions
SolutionOffering new interactions and tweaked components for design team to discuss
ProblemAccessibility (a11y) challenges with data visualizations
SolutionLearning and gaining experience as a team on best practices for accessibility
ProblemPotential conflicts with custom reports supplied by professional services
SolutionDiscussions with professional services and even sales on how data availability will add long term value for Loopio customers