Designing project pages

Discovering user needs

The data design team had a clear need to document how projects (a group of planning considerations) move through the data design process.

Users in the policy team, statutory consultees and the senior leadership team also needed to

  • understand a project’s goals and steps in getting there
  • an audit trail of a project to support the work in the future
  • be able to contribute to discussions and attend events
  • understand what had been discussed in previous events

What we already had

The user needs were discovered by accident, through creating a page to document an advisory group for the planning applications project. The planning applications project covers multiple considerations that were being discovered. As a result, the page soon became overcrowded with competing content.

A portion of the original planning application page with sprawling content

Improving the user journey through Google analytics

The original page was published in isolation. When users got to the page they spent less than 2 minutes there. We can assume that this is not enough time to take in all the content.

In the new design the project page has subpages for detailed content. The flow is also embedded in the data design website. This allows the user to discover more content that they may be interested in.

A user flow that now links the Project page to related considerations and datasets

How to design a project page

Components

A project page summary consists of multiple components

  1. Summary: A short description to cover the planning need of the project with a link to ‘future vision’ and relevant Github discussion
  2. Upcoming events: This section pulls event information and encourages users to join (this section would only show if events existed)
  3. Key (past) events: A timeline showing key changes to the project, rather than detailed week-notes.

Connected pages

The new project page has sub-pages. This is to provide more detail for certain users, without causing overwhelm on the project page.

  1. Weeknotes (working title): This gives an audit trail for work that has occurred on the project
  2. Future vision (working title): A space to talk through future vision and how the team intends to get there.

Next steps

The first step is translating the current planning applications page into something that fits our template. This includes deciding what the ‘key events’ have been so far. Once we have the right content - we will update the page.

A figma screenshot showing an analysis of current content and how it can fit the new template.

Planning applications is our first project page, but we expect there to be many more. For the next project page, i.e. Local plans, we will use the template to document consistent information so its easy to understand for our users.

Planning application submissions original page

A portion of the original planning application page with sprawling content

A portion of the page before a redesign, with more content being requested, this design wasn’t efficient

Proposed user flow

A user flow that now links the Project page to related considerations and datasets

External links worked well, but we needed to connect project pages better internally.

Translating existing content

A figma screenshot showing an analysis of current content and how it can fit the new template.

The beginning of translating the current planning applications page to fit the new template.

Leave a comment

We only ask for your email so we know you’re a real person
By submitting a comment you understand it may be published on this public website. Please read our privacy notice to see how the Design History platform handles your information.