This is a summary note of the Marketplace Reference Group meeting that took place on Tuesday December 13th, 2022. The objective of this meeting was to present the mockups of the Marketplace features and landing page, designed by the UX design vendor - SolDevelo. All members were asked to be as critical as possible and share feedback around how comprehensible, intuitive, user friendly and useful the mockups are.
Meeting agenda items:
Overview of the Marketplace Scope of Work & UX design vendor (SolDevelo) developing the prototypes for the Marketplace features and landing page.
Interactive sessions on the:
Product Comparison Tool
Vendor Storefront
RFP Radar Opportunities
Landing Page
Next steps & Future of the Reference Group
Interactive Session on the Prototypes
During this interactive session, the UX design team at SolDevelo presented the mockups of the Product Comparison Tool, RFP Radar, Vendor Storefront, and the Catalog/Marketplace Landing Page, they have designed thus far.
Following each presentation, the Reference Group members were given time to complete a brief Miro board task to write out their feedback on whether the purpose of the prototype is clear, easy to use/navigate, and visually appealing/memorable. The members were also encouraged to share general feedback on any improvements they would recommend. The floor was then open for all members to ask questions and share their feedback with the rest of the group.
Product Comparison Tool
This is the Product Comparison Tool prototype demoed by SolDevelo. The objective of the tool is to provide users with the ability to compare digital products across multiple parameters.
Below is an overview of the feedback received:
The comparison activity seems different than looking at products, it does not seem to make sense for the entry-point to this feature to take you directly to the comparison listing function.
Scrolling horizontally makes it more difficult to review quickly, are there other options that restrict that - is 8 products in a comparison tool really needed, might be best to reduce number of products one can compare?
The clarity of this tool heavily depends on the characteristics to compare. Because: the tool makes the overview and comparison easier. The Alternative could be 4 browser tabs with each product. It must be a lot easier than the alternative with tabs, otherwise it might not add as much benefit. So, are there many and complicated characteristics to compare which require a support tool in this process?
Users might find it more useful to be able to select/set a product as the primary or baseline and then compare that product to the others. The differences from the baseline could then be highlighted.
Include use case as a comparison category/parameter as well as the link to Govstack’s playbook implementation journey associated to the specific use case.
Add a parameter on whether a product functionality is Govstack compliant.
Incorporate information on the type of problem and challenge a specific DPG can solve/ has solved and what types of services are usually enabled with the specific DPG.
More clarification is needed on how the radar chart metrics are quantified i.e. how a software license gets converted from a zero to 10 score.
In response to this remark, this confluence page was shared with the reference group members to explain how DIAL is currently in the process of finalizing the maturity indicators shown on the radar chart and how they're being calculated, which are machine read through GitHub and other sources.
To ensure that the purpose of the tool is more clear, it would be helpful to include a methodological note for the categories presented (i.e how price was calculated).
Might be useful to have playbooks/guides that users can access with information on how maturity is calculated, methodology of the evaluation and the meaning behind each parameter/indicator i.e. what does adoption mean? how is pricing calculated? how does one evaluate how active their community is?.
Don't call SUM (stars, forks, docker-hub-pulls) "software quality". Rather, display the # of stars, forks, and dockerhub pulls.
Software is immature as an industry, so seeking to summarize them may be unhelpful, where exposing the core facts may be more useful. What is really needed is a semantic way of explaining software (apps, libraries, code, interfaces).
Recommendation was given that DIAL’s key focus should be to work on the data model from the gitlab link, and come up with a semantic way to describe the software in order to make this usable, sustainable and scalable.
RFP Radar
SolDevelo presented the following mockups for the RFP radar - page view and main tab - creating an RFP. The primary use case of this feature will be scraping and aggregating relevant RFPs from different sources/procurement portals and having them showcased on the Catalog/Marketplace.
Below is an overview of the feedback received from the members:
The feature doesn’t seem as well defined. The following is unclear: Who are the targets? What benefit do they get? How does this relate to the rest of the Catalog?
To ensure the purpose of the RFP radar is more clear, there should be an overview/summary of the purpose and target group of this feature shown upfront.
We should ensure that we are aligning to open contracting standards and enable open data to strengthen the DPG demand and supply system.
Useful to incorporate and have a look at the EU’s common procurement vocabulary (CPV) and OCDS - for semantic language standard for common procurement vocabulary.
Having APIs to connect to contract portals can facilitated keeping information updated.
This feature is still very useful, as some of these RFPs are not always easy to find by smaller organizations/service providers.
The feature is worth trying because it is the main point of interaction between private sector and governments.
This feature gives the Catalog the right to also call itself a marketplace platform. However, it is only a list referencing to RFPs hosted on external sites, it cannot be more, because doing so would require a very formal process.
Let us take up the need for the feature again: e.g. Governments trying to procure digital services provided by the private sector. Why not offer an RFI tool instead on the Marketplace? An RFI tool you can use before actually outlining and publishing a formal RFP. RFI is less formal and more easy to facilitate, DIAL can offer more features around this.
Vendor Storefront
SolDevelo presented the following Storefront mockups:
Since the Vendor Storefront is found under the ‘organization tab'. This makes the feature unclear because most users would not look under "organizations" to find information/ the listing of service providers.
The Storefront has the potential to undermine certain DPGs with a business model that is structured around listing their own vetted and preferred system integrators for their DPG. This could be detrimental for DPGs whose financial and sustainability model depends on maintaining their own list of preferred SIs.
This link to Drupal’s website was presented to showcase how a specific DPG already has a list on their site of preferred SIs.
For a "Storefront" it doesn't look very appealing. It has the same style as the RFP and products section on the Catalog. The mockup for this feature does not provide companies with the option to make their ‘Storefront site’ visually appealing. Is there any way to allow a free to design space between Expertise and Resources?
Landing Page
This is the mockup of the landing page that was presented to the group.
Below is an overview of the feedback received:
Why is a landing page needed? It would be best to take users directly to the Catalog and having the landing page information in the ‘About’ section.
The page should prioritize having a clean and clear and entry point. We should avoid having too much text on the landing page - any kind of user experience that requires somebody to read through how to use it is a bad user experience.
Why keep both terms, Catalog and Marketplace? Does it help the user? It wouldn't hurt to subsume everything under one name - possibly around the new concept ‘Marketplace’.
Kayak might be a great example to look at for inspiration for the landing page http://kayak.com.
Once this mockup has been developed, it might be interesting to use Google Analytics to understand concretely how users are actually navigating through and using the Catalog i.e. what they are clicking on most often etc.
No reference is being displayed on the the Catalog/Marketplace’s connection to the GovStack technical specifications, the Digital Public Goods Alliance, the Charter, SDG Digital Investment Framework etc. This connection should be showcased to connect the dots on how this work convenes the broader DPG ecosystem.
From the public sector perspective, it would be great for the landing page to easily show government actors, how the Catalog/Marketplace can save them time in digitizing their government services.
Next Steps & Future of the Reference Group
Next Steps
The link to the Marketplace’s product roadmap was presented to all, which displays the Q2023 activities and priorities planned for next year:
Building out the Marketplace features and facilitating user testing of the product.
Ensuring GovStack alignment.
Research on the incentivization, engagement and marketing channels to promote usage of the Marketplace.
Future of the Reference Group
An announcement was made that DIAL wishes to keep the Reference Group going and organize a minimum of 3 Reference Group in Q2023. The objective is to continue engaging the interested members to provide feedback on the Marketplace once we start building out the Marketplace features.
The next meeting is planned for the first week of February. The tentative topic will be: ‘Deep Dive on Product Evaluation Rubric and Marketplace Incentivization’.
In January 2023, a doodle poll will be shared with all members to select their availability.
