Miscellaneous information about a project

Since our very early research and designs, we've known that while users work through the task list, they also have information they need to check and refer to throughout the project.

While this information is not a task, it can help a user to identify a project or find useful information relating to it.

It typically includes information about the:

  • school
  • academy
  • trusts
  • diocese
  • local authority
  • advisory board conditions

That information can include links to other services like Get information about schools, or links to documentation about the project in SharePoint.

Generic page name and incoherent collection of information

Since we started, our focus has really been on the task list. That is the thing that delivers most value to our users, so it's right that was where we worked most as we developed the product.

Now that we have conversions and transfer projects live in the product, we're able to look at other areas to improve, and the "Project information" page has long been on our backlog.

From a content point of view, very little time or effort had gone into thinking about what should or should not be on this page.

That meant it was a large collection of stuff. Stuff that we knew, or had a good reason to assume, was useful to users. However, we had not had chance to understand how it could or should be structured.

That means we had a generic, not-very-descriptive title for the page and a list of information that was probably useful but we weren't sure to what extent.

Scrolling and screen space

Another reason we wanted to take a look at this page again was the duplication of information on the page.

With a set of summary information that was persistent across all pages inside a project, and notification banners on some projects, it meant the information a user may be looking for was hidden well below the page fold.

project-information-page-fold.png

Pruning the content

First, we got together as designers and researchers to review what content was on the "Project information" page and in the summary information.

We then used our own knowledge and insight from previous research to reduce and prioritise the content.

Using Lucid and Figma to remove what we thought was not needed or was duplicated and sort the information into what felt like sensible themes to us.

New page names

Project information

"Project information" can be hard to understand because all the content in the product is information about each project. If it is not information about the project, why is it there?

The navigation currently contains links to pages with names that are more clear and specific, such as:

  • task list
  • notes
  • external contacts
  • internal contacts

By process of elimination, a user could have a good guess at what "Project information" might contain. It would be fair to assume that perhaps there are no contact details in the "Project information" page.

Except it did contain contact information. So it really was not clear and not well grouped.

We tried to make the name of the page more descriptive. We changed it from "Project information" to "About the project".

Internal and external contacts

We also tested a new name for the "Internal contacts" and "External contacts" pages. These terms felt similarly loose and vague. What is internal, what is external?

The "Internal contacts" page also enables users to assign projects to people, so we wondered if a more explicit "Contacts" and "Assignment" navigation option would make more sense to users.

Thinking about future changes to "About the project"

"About the project" is still pretty vague, but it feels like a step in the right direction.

As we learn more about how users interact with and use this content, we may be able to to become more specific with what is on there and give it more specific name in the navigation.

Ideally, we would like to break the content in "About the project" up into individual pages so that navigation is clear.

The problem with that is that we could then end up with a long and potentially confusing sub-navigation component with lots of links. That could actually make it harder for users to navigate and find the link they need.

We could also end up splitting information that a user needs to look at together split over multiple pages.

So we really need to learn more about how users interact with this page and what they need from the information in it.

Summary of the changes

Overall, the changes we tested included:

  • renaming pages
  • removing duplicate content
  • merging local authority and region information into 1 row
  • structuring content into related groups with clear headings
  • presenting only the truly essential or most useful content in the summary list
  • adding anchor links to help users jump to the section they need
  • renaming internal and external contacts pages to "Contacts" and "Assignment"
  • local authority and diocese details moved to contact pages

Testing the new design options

Those sketches were based on our assumptions, but those assumptions were informed by prior research and knowledge.

We were pretty confident they'd be close to what was needed, but it was important we got user feedback on them before commiting to a decision.

We took the ideas to our regular co-design and feedback session with users.

Our design ideas covered changes to the project information page and different approaches to presenting the information in the project summary list.

From that we learnt:

That feedback helped us to make our design decisions and iterate the content and layout before the page was developed and released.

Before

project-information-page.png

After

about-the-project.png

Next

We'll continue to learn from user feedback and make changes to the "About the project" page to improve it again.

Share this page

Tags

Content design User research Service design Interaction design Development