VFLO - Streamlining the RFP process
Design process
Lean UX methodology
Jobs-to-be-done framework
Timeline
Late 2022 - Early 2023
Role
Product designer
Project overview
Historically, the valuation process has been laborious and time-consuming. Lengthy negotiations on terms and pricing lead to multiple exchanges between companies and valuation institutions. Once an agreement is reached, valuers input substantial amounts of data and present it to the client, often resulting in data overload.
VFLO was conceived to streamline the entire portfolio valuation process, providing a centralized hub of coordinated information accessible to all parties involved. The primary goal was to simplify the way teams appoint, approve, review, manage, and compare their valuations - effectively doing away with the need for exhaustive manual processes.
As the sole Product Designer at Brick Road at this time, my role was to design the end-to-end solution from 0 > 1. This case study will focus on the 'Request for Proposal' (RFP) workflow of the app, as it was the most foundational and complex section of the app. Specifically, I will illustrate the design challenges I encountered, the methods that were employed, and the solutions developed.
The challenge
The RFP process is complex and multifaceted, requiring users to configure multiple assets, each with numerous future planned valuations, within a single RFP. We also had to account for different user roles - from investors who could be initiating multiple RFPs to assistants who would be handling the bulk configuration. Our challenge was to design and build a simple process that eliminates headaches and can all be done in one central place.
The approach
To understand my approach, you must first understand the context of the business. Brick Road was a bootstrapped startup with the need to quickly push products out to determine product-market fit. The company and culture was very aligned with lean methodology. Thus, as the designer, I had to work within the constraints of having no user-base to research from as well as rapidly produce the designs for development so we could ship and test afterwards.
As a result, I decided to employ a Jobs-to-be-done (JTBD) framework for designing. The JTBD framework was instrumental in the design process. This method focused on understanding the 'jobs' that potential users aimed to accomplish with VFLO. I treated one of our co-founders as an expert user as he was highly knowledgeable and had experience in this industry. Thus, with when determining a job a user would aim to do, I would ask probing questions to uncover what these jobs consisted of. Here is a small example:
A user wants to issue out a request for proposal for a valuation on multiple assets that they own
Job 1
A user needs to choose and configure which assets to include in the RFP
Job 2
A user wants to include future valuations for certain assets in the RFP
Job 3
A valuer needs to know which dates the user requires each valuation to be done by and their various other stages
Job 3
Whiteboarding sessions were held with our technical co-founder to brainstorm and sketch ideas for the RFP process, considering data structures, information architecture, and developmental constraints. These sessions allowed us to organise and visualise the task of bulk adding assets and scheduling multiple valuations.
Bringing in an expert
As I continued to iterate and follow a very agile process to design, we decided to bring in an industry expert to gain further understanding and test our early designs. This expert was a giant in the valuation industry and provided some critical feedback. From him, we learned the following:
Companies may delegate the RFP creation process to an assistant to bulk create and edit.
Insight
Companies may prefer to directly appoint a valuer rather than send an RFP
Insight
More often than not a company assigns a valuer company with the intention of them assigning their own valuers for the job
Insight
These insights, alongside additional smaller insights, drastically changed the way I had to think about the structure of the RFP process and the inclusions necessary for the user to complete their task in an efficient and simple manner.
Quick iterations are the aim the game
Regular feedback cycles, testing, and expert insights led to many changes and refinements in the design. Initially, I started by structuring the RFP process as creating groups called 'cycles' that housed multiple RFPs, each holding multiple assets and valuations. However, this structure proved overly complex. I ended up simplifying the process to its essential tasks (JTBD), allowing users to send a single RFP with multiple assets and valuations, and choosing to directly appoint or send as an RFP at the valuer selection stage.
Challenges I faced
Balancing the different visions of the founders was one of the major challenges I faced. Our technical founder wanted to focus on a lean methodology, shipping a barebones structure quickly and iterating based on user feedback. In contrast, our other founder had more expansive ideas for the design and feature set. I had to somehow manage the tension between these two approaches as it was increasingly proving to be quite overwhelming for me as well as slowing down the design process. To manage these contrasting approaches, I put on a product manager hat, setting up a Jira roadmap and backlog system. This became our source of truth, streamlining feedback, and significantly speeding up our design iterations.
Looking to the future
The final design for VFLO caters to the complex needs of valuation firms, providing a streamlined solution for managing RFPs. Through continuous iteration, open collaboration, and a focus on the 'Jobs to be Done', we developed an intuitive and efficient interface for the RFP process. We successfully distilled a complex system down to its essential tasks without losing functionality, meeting the needs of various user roles in the commercial property valuation industry.
Unfortunately, Brick Road ceased operations before we could properly launch this web app. I personally felt as though a lot of my work had gone to waste. But the true value of designing and building this app was everything I learned along the way. In particular I learned:
The Jobs-to-be-done framework for designing when we don't have the resources for larger scale user research.
How to develop a full scale web app in bubble.io
How to design for complex applications - reading Nielson Norman Group's articles on this topic was a regular part of my commute home. Specifically, I learned the concept of progressive disclosure for hiding secondary actions until the user requests for it. This cleaned up the primary interfaces significantly.
How to manage expectations of various stakeholders as well as manage differing voices of influence
How to use a design system
Had Brick Road stayed in operation, my next step as the product designer would have been to run some usability testing sessions with a small group of users. I would have also led some interviews with users to find out how they are finding the product and to probe deeper into any issues or ways we could improve the experience.