Bonfire - Public Q&A
Bonfire is a B2B SaaS tool for eProcurement used by Public agencies across North America. Over 600 governments, schools and other public agencies use Bonfire to build, advertise, evaluate sourcing bids and create contracts.
My Role
I was the sole UX designer on this project. Designing end to end, I collaborated closely with the PM on discovery & strategy and additionally the dev lead for the rest of the process -
User discovery and research: user interviews as well as some light marketing research
Product strategy and conceptualization: identifying and prioritizing features based on user research, business goals and technical feasibility
Experience & visual design: designing, testing and iterating until handoff to the dev team
SCOPE & COnSTRAINTS
This project was scheduled for a fixed 6-week development cycle and a limited time before that to conduct discovery and design. This meant we had to design and build an MVP to bring value to the user without relying on near-future incremental improvements.
Because of the nature of public agencies, we couldn't incentivize guaranteed participation in user research activities but we had a volunteer set of internal testers and customers to give us feedback and test designs!
THE PROBLEM
Procurement teams struggled with inefficient vendor communication during the formal Q&A period.
Bonfire offers a direct messaging feature for bid projects but it became a bottleneck during the formal Q&A period.
This messaging system, intended for general communication between buyers and vendors, wasn't suited for the high volume of questions and answers.
They handled between 50 and 300 questions per bid resulting in a very time-consuming and manual process.
Discovery
Buyers found Q&A period on bids time-consuming and manual
We had direct feedback from 10 agencies that asked for improvements, and we interviewed 5 agencies of different sizes.
Buyers handled between 50-300 questions and a lot of repeated questions. They used spreadsheets and 3rd party tools to aggregate, analyze and track Q&As. Vendors did not know when their questions would be answered - resulting in follow-up messages.
From our user research, direct feedback, adjacent feature requests and competitive analysis, the workflow gap was clear.
Multiple questions were sent in a mixed message thread
Could we have better notifications and sorting and tracking for read/unread messages?
Repeated questions that all needed to be answered
Maybe a public FAQ would help?
Vendors did not know when their questions would be answered
Do we give buyers a mechanism to indicate the question will be answered?
CONCEPT + VALIDATION
Our direct messaging did not always work for public agencies and vendors
While all of the above functionality could help deal with the problem, the root issue was still that Q&A is inherently different from messages.
Through brainstorming with the dev lead, we learnt that our legacy messaging feature was on an older tech and UI stack and overlaying new features on it was not only hard but added to the existing bloat.
After lots of how might we sessions, our proposed concept was a new Q&A feature that allowed agencies to publicly answer questions.
Weighing our options to solve this problem
Publicly posted questions
Repeated questions avoided
Buyers can indicate status of question
Vendor anxiety reduced
Q&As separate from DMs
Tracking, sorting and easier to answer
All answers are public
All vendors see answers - fair and transparent
Agencies operate differently and have different needs
After building quick wireframes and user flows, we connected with 3 agencies to align our concept with their processes.
Some agencies wanted questions to be private before review while others wanted questions public by default: This resulted in a toggle for changing visibility in the UI
Need for simple status workflow: one-directional statuses to prevent confusion on both the buyer and vendor side.
Agencies were concerned about the possible liability that might arise with editable Q&As
Smaller details like adding a question ID to allow buyers to refer to other vendors’ questions
Journey of a question
EXPERIENCE DESIGN
Making Q&A efficient through UI - forum-style table or question threads
Table:
Faster to implement, existing components. Works for a large number of questions.
Details modal/page takes users away from the Question list
Large questions are hard to read in a table column
Question threads:
Needs new components and more effort to develop than a table.
Lesser questions but infinite scroll possible
Doesn’t take the user away from the action - with split 2-panel, has all the details on the same page
Meeting with the dev team, we could reuse and update an existing card component I had designed for another project.
The choice was clear - the question threads were easy to develop, modern and kept everything in one place!
Testing, testing, testing!
I conducted multiple internal hallway tests with CX and other Product team members to quickly decide between smaller design variations.
I ran a Maze usability test with over 90 buyers recruited via a popup in the app to test the copy and the usability of the workflow.
Status and button copy were crucial to get right for users to understand the functionality. Given the test covered selected areas, the feedback validated uncovered areas that were already in scope.
Outcomes & Takeaways
The MVP was launched with great success! Many of our bigger customers were very excited to incorporate this new feature into their workflows.
In just 60 days after launch, over 35% of public agencies opted for the public Q&A vs direct vendor messages for bids!
I set up tracking of the feature via our analytics tool, Pendo to study user behavior and track incremental improvements for the future.
While the short discovery and design cycle limited the testing, I would love to do more moderated testing next time.
Developers need a lot of hand-holding for new features vs incremental improvements. From this experience, I created a more thorough Figma template with checklists to ensure both our design team and developers consider edge cases during the design phase.