Linked to our recent work on what happens when a user opens a completed project, we've also been looking at what should happen if a user opens a project they are not assigned to.

A tailored project list but open access to all projects

In the product, users can access any project.

Users can only see projects they are assigned to in their project list, but if they have a link to another project they can access it.

A list of projects assigned to a particular user. The list contains information about each project including the school name and conversion type.

Helping users to work together while protecting the accuracy of a project

Having access to all projects means users could share links to project with their colleagues.

This could be helpful to users if they wanted to ask advice for advice from colleagues about an issue in a project. Sharing the link may help them share thoughts, knowledge and experience.

However, it could also result in accidental or unnoticed incorrect changes to projects if any user could update any project.

We've made some simple changes to what the user sees when they access a project that is not assigned to them. These changes are designed to help maintain the accuracy of projects and prevent accidental changes.

Notifying a user that they're in a project they're not assigned to

A notification banner will appear at the top of the task list page in projects that user is not assigned to. This banner tells them that they are not assigned to this project and that they cannot make changes to it.

Users can add notes and contacts to a project that is not one they are assigned to, but they cannot complete actions or tasks.

When a user accesses a project they are not assigned to, a banner at the top of the page tell them they will not be able to change it, but they can make notes or add contacts

Preventing a user making changes to tasks

If a user opens a task in a project they're not assigned to, they will be unable to save any changes.

We've removed the primary action button so while they may be able to tick off a task, they cannot save that change. Only the person assigned to the project can save changes to that project.

A task in a project that is not assigned to you has no primary action button. Changes cannot be saved.

Reassigning a project

While these barriers help to protect against potential mistakes, it does mean that there is slightly less freedom for users compared to what they are familiar with in the previous applications they used.

Any user could access and change any project in the old systems.

This meant that if somebody was ill or on holiday, somebody else could pick up their work easily.

This level of flexibility in the application is something users told us was important, and so we've designed with the ability to reassign projects to different users.

If a user needs to pick up a project from somebody else, the project can be assigned to the new person and they can work on it.

A list of people working on the project. This can be updated by clicking a link that says "Change". Users can then search for another user by email address or name. Once selected, that person is emailed to tell them they've been assigned the project.

When reassigning a project users see a heading saying, "Change assigned person for [school name]" and a text box they can use to enter a name or email address. There is button saying "Continue" which they click to update who is assigned to project.

What we'll do next

We'll monitor this functionality for user feedback. As we learn more about how useful it is we'll look to iterate and improve on it.

We've heard about some cases where more than 1 person is assigned to a project. We'll try to learn more about that through our research and see how it may change the way these permissions and interfaces work.

Share this page

Tags

Content design Service design