User Journeys on the Digital Marketplace

Visual Overview User Journeys

The visual overview lives in the:

Digital Marketplace - Design - User Journeys folder

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.

Use the 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:

Digital Marketplace - User Flow Journeys

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.

To use:

  1. Identify whether it is a supplier focused or buyer focused journey

  2. Identify whether it it a further competition (DOS) or direct award (G-Cloud) specific journey

  3. 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.

Digital Marketplace - About the Digital Marketplace - User journey maps

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.

Open the Buyer map or Supplier map in draw.io for the best experience of these.

Preview environment

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 /users?role=[role].

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

Warning

Avoid arbritrarily changing the framework state on Staging, as we want to keep that environment as close to Production as possible.