Background

Wellcome improves health for everyone by funding research, leading policy and advocacy campaigns, and building global partnerships. Wellcome is due to be launching Wellcome's Funding Platform on March 2023, replacing the outgoing Grant Tracker - the current platform where researchers can apply for funding through Wellcome.

The challenge: Create a framework for notifications and
system feedback 

Applying for funding can take hundreds of hours across several months. Applications can also have several participants on an application, with all of them potentially editing the application simultaneously. Once completed, an application needs to be submitted to an administering organisation for review and either submitted to Wellcome or returned to the applicants with feedback, where applicants can make changes and resubmit. Once an application has been submitted to Wellcome, it must go through several stages of review before it can be successful.

All these moving parts and status changes meant that the new Funding Platform needed a robust framework to communicate all the events occurring in the funding process.

My role

I led the visual design and assisted in the research. I was part of a cross-functional product team, working alongside another product designer, product manager, user researcher, engineers, content designer, copywriter, and agile coach.

Our objective

We decided to focus on three areas:

• Users to know what is happening in the system and if they need to take action.

• Develop a framework which determines how and when a user is notified about events that have taken place in the funding process.

• Everyone in the team is clear on what the different system communications are.

The process

To understand the problem, the other product designer created a design brief to identify all deliverables, success measures, dependencies and scope.

The design brief

Discovery

After creating a brief, the first thing that I did was carry out some desk research on notification patterns used across different products and identify the pros and cons of all notification types and any accessibility concerns.

Here are the different component types that could be used within the product:

• Toast notifications

• Banners

• Modals

• Inline notifications

• Notification centre / Tray (Out of scope for MVP)

The next step was to conduct a kick-off workshop with the rest of the product team to determine the ideal future we would want once the project was finished. This workshop was run by the other product designer on the team with me assisting in the planning.

The next step was to develop the framework. This was a joint effort between myself and the other product designer. For this, we decided the best way to handle this would be to categorise between active and passive notifications and non-urgent and urgent notifications.

Active vs passive - does the user need to take action?

Urgent vs non-urgent - will effective use of the service/platform be affected?

Notification framework

Notifications audit

The framework gave us a solid platform to work from and something that could handle all communications required currently and in the future. The next step for me would be to create a notifications component set to be used for all the different communications we would require. However, before doing so, I needed to audit the product in its current state, identify all areas where notifications are already being used, and highlight all inconsistencies so that they can be addressed with the new components.

New compoenent set

The new component set had some requirements; it needed to include all the component types we required:

• Toasts

• Banners

• Modals

• Inline notifications

Each component needed a style for each severity type required (information, success, warning and error). Each component also needed to accommodate an action, and lastly, each notification was required to be user dismissable (where applicable).

Exploration

With component sets explored, I created prototypes and saw how all of these components worked on the product. This allowed me to see how the notifications were working in a 'real-life' setting and see if notifications were visible enough and if the interactions made sense.

Notification journey example

The notification sets underwent multiple reviews and iterations until we finally landed on a winning idea.

Final component set

As with all the work and components I have created for the Funding Platform, my job would only be complete once proper guidance was written for the notifications. This is necessary for the engineers to understand precisely how each component needs to be built and any animations they need. It is also needed for other designers intending to use the notifications to understand the components' purpose and severity types.

Notifications guidance