User Journeys on the Digital Marketplace¶
Visual Overview User Journeys¶
The visual overview lives in the:
This was collated in late 2017 by the design function at the time.
It provides full screenshots of popular user journeys but lacks contextual information. It is useful for referencing the design patterns on the Digital Marketplace.
digitalmarketplace-flow[1|2].pdf files to see the full flows.
Walk-through User Journeys¶
To walk through the different journeys users make on the Digital Marketplace you want:
This was collated throughout 2018-19 by the analyst function at the time.
It provides slideshow style, step by step, visual guides of the user journeys. It includes the URLs for each step referenced.
Identify whether it is a supplier focused or buyer focused journey
Identify whether it it a further competition (DOS) or direct award (G-Cloud) specific journey
Dig into the nested directory structure to identify the relevant journeys
User Task Maps¶
The user task maps indicate how the user journeys on the Digital Marketplace facilitate the overall procurement journey.
These were collated in the first half of 2019 by the product and user research function at the time.
Although they lack screenshots they indicate where the journeys on the Digital Marketplace fit in to the wider procurement effort. Some parts of the procurement journey are not included in the Digital Marketplaces user journeys. For example; the collaborative shortlisting of relevant search results.
Buyer map or
Supplier map in draw.io for the best experience of these.
To log in as a supplier, buyer or admin on the Preview environment, ask a developer for a test account. If you are
a developer, grab a test account from the Preview API (or API client) using
Not all user journeys will be visible on Preview, depending on the state of the frameworks at the time.
If you need to see what the platform looks like when a framework is open for applications, a developer can set this state in the API (see framework lifecycle for developers). It’s recommended to re-open a previous iteration, for example, if G-Cloud 11 and Digital Outcomes and Specialists 4 are ‘live’, re-open G-Cloud 10 or Digital Outcomes and Specialists 3.
Re-opening an old framework ensures that the current ‘live’ iterations are still present and the smoke/smoulder tests will pass. This also means we don’t have to clone all the content for a new framework. However there are some drawbacks:
declaration and service questions will not be up to date (as it’s an old iteration)
any new features (such as Modern Slavery statement uploads for G11 and DOS4) will be missing
re-using declaration answers or copying services is likely to fail somewhere
some functionality outside the framework application journey will be missing or broken, such as viewing opportunities or saved searches from the old framework
Avoid arbritrarily changing the framework state on Staging, as we want to keep that environment as close to Production as possible.