G2 Track aims to be the single source of truth for managing software spend, contracts, account usage and compliance, and marketplace for software.
This project was an exploration on how G2 Track could help users connect directly with software vendors.
Over the course of a few weeks, I spearheaded the design of Request for Information (RFI) as the lead designer for the G2 Track team. Through a combination of research analysis, concept exploration, and product strategy, my goal was to take a broad, conceptual idea and deliver something valuable to our users and to the broader G2 organization.
Learning fast to move faster
I was brought into the project after the initial research phase and briefed on the current direction of the project: Request for Proposal (RFP), a formal method for software buyers to request proposals from software vendors.
Given the short timeframe, I needed to quickly analyze the research collected and synthesize my own insights to help move the project forward.
Through concept testing, I found users did not resonate with the idea of creating an RFP. Most users were curious but were unsure how to implement it into their current software procurement process. Others had no clue what an RFP was.
Results from testing proved too risky in releasing a feature that would fall flat of user expectations.
However, this didn’t mean that the project needed to be completely scrapped, rather we needed to change our hypothesis. I found that every organization, no matter its size, engaged in the procurement process whether or not it had a formal procurement department.
Users wanted a better way to connect with vendors, but not necessarily through a formal process which would require a lot of cross-team collaboration in the beginning.
Although internal stakeholders were already strongly committed to the idea of RFP, I advocated building a less complex feature called Request for Information (RFI). This solution required less resources but still addressed our users’ goal.
Through my research, I found there were three types of commonly used documents in the software procurement process: Request for Information (RFI), Request for Proposal (RFP), and Request for Quote (RFQ).
I communicated to stakeholders the pros and cons of both methods. Our users needed to be eased into a formal procurement process and our team was already working under extreme pressure. It also made business sense to first invest and learn from an MVP to help minimize cost. It became clear that building out an entire RFP system would create unnecessary frustration to our users, team, and organization.
Through striking a balance between user and business goals, my insights helped us move forward with a new direction: RFI.
Less work for more value
With less than a week left, I moved on to producing visual designs.
The visual designs included all flows, screens, and interactions and a working prototype. Each flow was fully designed to help engineers learn and build faster.
By quickly pivoting to a simpler solution we were able to design faster, build faster, and ensure our user's goals were met.