Procurement Platform UX Design
A platform for a government agency to search for specialized small business vendors
Challenge
Our client wanted to build a platform where their client’s workers would easily find businesses eligible for Small Business Innovation Research and Small Business Technology Transfer (SBIR/STTR) funding for research and development projects.
Currently, the agency’s employees must sift through various websites that catalogue approved businesses and make contact through email.
Additionally, there is no way to catalogue these businesses within existing sites, which makes sharing potential partner businesses with other interested departments painful.
For these small businesses, they have low visibility to government employees. The quickest way to get approved for research is to submit proposals to existing issues government departments create inquiries for.
In order to start, we needed to answer some key questions:
- What opportunities were missing from similar platforms that this platform could capitalize on?
- Who were our user personas, and what were their biggest pain points?
- How might we incorporate and organize various search parameters?
How might we create a platform that makes searching for small businesses easier to find, catalogue, and vet?
Scope
The scope of this project included designing a platform with 3 proto-personas, information architecture set up, and a hi-fi wireframe and clickable prototype.
Constraints
We had a 3 month timeline to implement a full UX research process. Due to privacy concerns, we were unable to reach out to end users for usability testing or interviews and relied on desk research and stakeholder interviews for proto-persona development.
Implementation
During this process, we built the hierarchical structure and UI of a faceted search function.
Our Goal
The goals for this project were to create a solid foundation by determining the information architecture.
This required us to:
- understand the personas and their goals on this platform
- create the information architecture to establish the logical hierarchy
- design visuals that were not only intuitive but professional and sleek
Our Solution
Through speaking with stakeholders, we discovered that a centralized platform did not exist. Therefore, it needed to be created from scratch.
We recommended a design utilizing a faceted search function, repeatable components to allow for growth, and a focus on clean and uncluttered presentation of information.
Results
We presented and delivered our design in Fall 2021. Our designs were handed off with annotations for development.
Our Process
Understand
While we were not able to directly talk with agency workers or the buyers, our client held institutional knowledge to help us understand the users and their motivations.
Proto-Personas
To get a sense of the ideal users for this platform, we interviewed stakeholders. They named three types of personas, and from there we delved in with our own research.
The three personas are as follows:
- The government employee
- The small business vendor
- The Intermediary/Mentor
Speaking with stakeholders gave us an understanding of the current state of connecting government agencies to appropriate vendors.
- For government employees, the process is tedious and long, usually consisting of sifting through multiple government websites with no unanimous UI. Saving potential leads, sharing leads with other employees, and contacting a vendor for vetting is done over email, and organization depends on the user.
- Vendors have low visibility on existing government sites, with some sites requiring them to submit RFPs corresponding to advertised projects. They must create a case for each requisition they believe they can apply themselves to.
- The intermediary acts as the go-between for both government employees and vendors. They face similar issues as the government employee in collecting and organizing vendor data.
Competitors
No direct competitors exist for this platform. Similar platforms used offerings such as separate logins for different user types, detailed search filters, and searchable supplier profiles. No one platform utilized all three in the capacity that the stakeholders intended.
Additionally, in those platforms, the search for opportunities is done by the vendors, rather than the buyers.
Explore
User Journey
We created journey maps for the 2 main proto-personas; the government employee and the vendor. Because the 3rd persona had very similar pain points to the government employee, their journey was consolidated into the latter. At each state we outlined opportunities for the platform to improve upon the current flow.
Buyer User Journey
Vendor User Journey
Information Architecture
We decided to implement a faceted search function due to the large amount of criteria needed to find the right vendor. The bulk of the architecture was centered around the buyer’s need to fulfill specific technological, supplier profile, and government certification criteria.
The main breakdowns of search criteria were grouped into three major groups, branching out into specifics within each group, and then into more minute specifics.
Looking at relevant department websites, we determined the main technological focuses, contract award history, and small business company information were the top level focuses.
Architecture Map
User Flow
We determined through stakeholder interviews and user research that a buyer’s flow ended with successfully finding a supplier and reaching out, which would have them leave the platform. A supplier’s flow ended with successfully obtaining an RFP inquiry through their profile from the platform. The intermediary’s success was in their ability to catalogue supplier profiles and alert interested parties of a potential partner.
User Flow
Design
Sketches
We sketched out a basic blueprint for the hierarchy of the information. This process allowed us to work through ideas quickly and settle on successful design patterns.
UI Components
We created components that could be easily duplicated for large scale searches and growth. Most importantly, we wanted these components to be legible while scrolling though potentially large lists of cards.
Mid-Fidelity Wireframes
We focused on two separate flows in our wireframes: Buyer and vendor. The employee and vendor each got separate access upon login to protect the identities of both parties while going through their flows.
The buyer needed frames around commenting on supplier profiles, bookmarking them, and tracking their comments for future use as well as the faceted search function.
Vendors did not have access to the search function or notes and bookmarks. Instead, their flow upon login opened to a metrics page to see their visibility in quantifiable terms. They could edit a public profile meant to be shown to government side users.
Style Tile
For the styling, we utilized the client’s brand colors and font styles to create a clean, modern platform while keeping it unique to the client. Frame layouts favored a professional, easy-to-read look to match the professionalism and opportunity of STEM specialists.
Validate
We conducted internal, remote usability tests with 5 users.
Goals
The most important information we wanted to know from these tests was:
- Does the information architecture create an intuitive experience?
- What accessibility concerns are showing up?
- How viable is the design with the technology to be used to build the platform?
- How can we add delight to the high-fidelity iteration?
Changes
The feedback from testing pointed out several areas of the prototype that needed changes:
- Naming conventions were changed to more recognizable labels
- Global navigation menu items were restructured
- Pages such as “Notes” and “Bookmarks” were consolidated into a single “Notes and Bookmarks” page for more intuitive access.
After making the appropriate iterations and with the client-approved style tile, we made final iterations to the prototype UI to create the high-fidelity wireframes and prototype.
High-Fidelity Wireframes
Conclusion
Insights
We found that the buyer persona was going to be the most important user, with the most functions needed in order to effectively find the seller persona. The intermediary persona functioned closely to the buyer persona, and their primary actions and flow varied very little.
Constraints
Due to privacy concerns, we were unable to interview and test potential users, and the personas were based only on our research. We relied heavily on the stakeholder’s understanding of the user. Ideally, we would have interviewed users for a clearer picture of their needs, and we would have tested the different stages of the prototype with them. In the future, we would like to understand how the end user reacts to the design and get insights into strengthening the platform.
Because the platform’s main function was its ability to search for a prospective seller, the faceted search was the main focus. It was important to create a logical hierarchy of information for the search function, and an accessible UI to utilize the search. Thus, the information architecture had to be a solid foundation before the rest of the platform could be designed.
Next Steps
For future iterations, we recommended having an in-platform messaging system. This would help keep any information pertaining to supplier recommendations or scouting to the platform, and alleviate the frustration of bouncing back and forth between the platform and users’ email inbox.