Brief

Buckinghamshire Fire and Rescue Service needed an updated website to provide clear information to the citizens they serve. Their existing website, other than being generally outdated, didn’t have a clear structure, so most of the value from their content was lost, even more, it didn’t meet the latest AAA standard for WCAG 2.1 accessibility. They then required to streamline content and simplifying content publishing. The main section visited was the incident section, and they wanted to shift their focus from incident to safety, to inform the public and potentially save lives.

On top of the main website, regularly updated just in content, they had an HR website fully managed internally. To have a cohesive message they wanted to merge both of them on the new site.

Plan

My plan was to have a full understanding through a discovery phase ( define key goals, objectives, target through test and research) to define a structure and create an initial wireframe. This plan was presented during the first discovery meeting to the three main stakeholders. Then after discovery proceed to mock-up, prototyping and testing, and then front and back-end alongside content creation.

Discovery

To create a solution I always start from the why so from understanding the key areas as much as I can. I do this at the beginning of every project during the discovery phase.

Discovery / plan

To be able to define a structure (wireframe) I needed to understand:

• Main requirements from the client
• Define goals
• Define targets
• Understand user needs
• Map full content
• Define content hierarchy

Discovery / goals, requirements and target

To define requirements, goals and targets I had structure face to face meetings and workshops with the main stakeholders, building up information from general to particular.

Because the Fire Service is mostly focused on people at risk, to reduce that risk, the target for the website, even if directed to the citizens living in the area covered by them, was narrowed down to people at risk or vulnerable (such as old, living alone or disable). 

Alongside this, to protect these vulnerable people, the second target for the website was new recruits.

To understand user-target needs and also define it better, I used client’s knowledge and data collected by them, such as requests for support, information about incidents and analytics from the current site, and also a live survey on the main website (that gathered more than 850 responses) and a demographic and competitor research.

Data collected from the client allowed me to understand the areas of interest and concern of the citizens, this was also supported by the analysis of google analytics.

These data together with meetings allowed me to define key goals/requirements:

• Encourage learning about prevention ( so shift focus from incidents)
• Find new recruits
• Improve user experience
• Reduce call and messages for general enquiries
• Make the website accessible for everyone

/ user survey /

The survey, that was published for over 4 months on the main website, the HR website and on the client intranet, received more than 850 responses and allowed me to understand what users liked and didn’t like about the current site, what they needed as extra, what were the reasons for them to go to the website and how long they were spending there. This survey also allowed the project to be inclusive of the whole team and the public.

/ demographic research /

The demographic research using government surveys and data from 2011 to 2018  allowed me to understand many key information about our target, such as:

• Majority of the population speaks English (over 85%)
• Majority of populations works
• Majority of the population is aged between 20 and 60 years old
• Majority of the population is from Great Britain
• Almost 60% of the population is Christian and almost 30% has no religion
• In Buckinghamshire, there is 13.4% of the population limited by long-term illness (67,928 people) and 9.8% are providing unpaid care
• In Buckinghamshire, 12% of households (23,652) are Lone pensioners
• In Milton Keynes there are almost 40% (99,528 people) of people single / separated / divorced / widowed and 3% (7,464 people) of people in bad health conditions

All these key information helped me define better the people in our “vulnerable people” target, and so to add simple paths and structure to the content and functions to the website to simplify their journey. Because the target is ‘vulnerable people’ sometimes I used demographic research considering the minorities rather than the opposite, for example considering the 3% of people in bad health who are clearly at risk.

Discovery / main personas

Considering the knowledge gathered I started creating 3 main personas to guide my and the client decisions when working together.

For them I considered the following fields:

• Age range to consider needs and accessibility requirements
• Gender to consider possible risks he/she might have
• Spoken language to remember that most of them speak English but not all of them do
• Area where he/she lives to remember that we are considering just citizen in that area
• Marital status to consider if the person might be alone and have someone who can support him/her
• Kids to consider if the person might be alone and have someone who can support him/her
• Religion to understand what risks related to religious celebrations or practises he/she might have
• Health condition as a key element of definition for a type of vulnerable person
• Pain points / risks associated with his/her characteristics
• Needs connected to pain points
• JTBD to understand the root reasons for needed the Fire Service support or info and so visiting this site

Discovery / content structure

Content is the core and strength of this site, and the main reason for user visits, so to understand content requirements and to create a structure, I mapped the full content on the existing website, working with the stakeholders to understand grey areas. With that, the goals and the target information I was able to define an initial content hierarchy structure, presented on a simple doc, that was then reviewed with the client and against the survey results (and later user-tested on the prototype).

Content hierarchy:

1. Emergency contact information
2. Emergency alert information
3. Advice about safety
4. Share culture to find new recruits
5. Incidents information
6. Services information
7. Authority information
8. General information

To support the process of content simplification, I worked with the client to create sub-structures and maps. This allowed both our team and their team to structure and create content more easily.

Discovery / user flow

To help the client evaluate the proposed structure I created a visual representation of the expected/desired user flow. To redirect from incidents to safety section, and from the homepage and social media to safety section (the core of the site) as well as flow to direct users to join us section and then job application.

Discovery / wireframe

To complete the discovery process I converted all the knowledge and information gathered into a website structure using a mobile-first wireframe. The wireframe was presented to the client together with an explanation of how to use a wireframe and what to look for.

The wireframe allowed me to work with more clarity with the stakeholders, using a visual representation of my vision for the product, it allowed me to clarify some grey areas and to test the concept and initial assumption using internal user testing.

/ wireframe description /

Using the goals and the target knowledge I structured the website and the main page accordingly. The top header navigation presents in hierarchical order from left to right only the main pages of the site (with no dropdowns) and the other pages are moved to the footer navigation. 

The homepage presents a similar structure, with elements to direct the user journey to the areas of interest. 

The secondary pages have common elements to simplify user navigation and make the pages more accessible, these are from top to bottom, historical breadcrumbs, page title, page introduction (that give to the user an indication about what he will find on the page).

Content and posts are the core of this site, so they follow a common structure, with some extra elements when required, all coherent to the general system. These are, like other pages, breadcrumbs, page title (post title in this case), sub-title (to give more context to the title), post introduction, body, and at the bottom of every post we collect all the related resources in separate groups (related download, external resources, related post), this simplify the fruition of the page, helps the user get value from the content (being in a simple and consistent order) and to continue his journey to new pages, and also helps the content team to manage and add new content.

To oversee all this structure I designed a cross tagging system that allows the content team to add a post in the correct repository area ( one of the 5 main defined when structuring the content ) but to use that everywhere in the site. So if for instance, a post from one section can be useful to a user that is reading another section, or another post, this can be tagged with more than one tag or linked to that other post; in this way that post will be created once and it will be present everywhere is needed, avoiding duplication and keeping the structure clear and easy to manage.

Prototype

Once the wireframe, and so the website structure, was fully tested I was able to create a mobile-first UI. This was made considering the latest accessibility standards ( WCAG 2.1 ) to provide all users with the best experience possible regardless of limitations or disabilities. I based this on the main Buckinghamshire Fire and Rescue Service colours, I modify them checking contrast to create a hierarchical system supported by shapes, colours and text. This system of buttons, previews and navigation elements allows the user to understand their importance and function, so access the content easily and get value.

This, together with the structure, was used to create an interactive prototype, using Invision and Principle when needed. This prototype was used to do user and accessibility testing, and make adjustments where needed, and to then present it to the client to get approval to proceed to the building phase. The user testing was done by creating a simple task for the user tester connected to the preferred user flow, to check the actual one and evaluate any difficulty or issue during the experience. The accessibility testing was done using online platforms and web tools as well as in-browsers tools (from Google and Mozilla).

Development

Once the prototype was tested and approved I worked closely with the front-end developers. I first used the prototypes and the sketch file to provide them with a full picture of the structure and the requirements. During the build, I help them find solutions and make adjustments when needed. 

Once the front-end was fully tested on desktop, tablet and mobile, on the supported browser and devices, we handed it to the client to run an internal user testing before starting developing the back-end, to make sure that we were still on the right path. Once we got sign-off for the front-end, I again worked closely with the development team to make sure that all the functionalities were built according to specs and to help find solutions to any possible issue that might have occurred.

In the meantime the development was proceeding I also worked closely with the stakeholders and their team to create the required content. Because the new website had an improved structure and was now also fully compliant to WCAG 2.1 we had to work on updating the content from the original website and placing that in the appropriate area (considering that part of this job was already done during content mapping in the discovery phase). To help the team working on these tasks I first created a presentation to bring everyone up to speed on the new website and its structure, then I provided an overview of the work needed. To do the work I created a worksheet for each section of the site (managed by a different team on the client’s side) and post templates. I created all these documents using google docs to support the team in their work remotely and also to be able to track progress to meet the live date. Once the content was completed, together with the internal content team (that I trained in advance for this site) we reviewed the material provided and made the needed adjustments. When all was checked the content was uploaded on the testing environment where I was then able to check its correct layout.

Once the full website build was done we ran again full testing on every device and browser supported. To provide training to the remaining part of the client team and to any future team member I created a full guide comprehensive of the process that created the site (goals and target), the structure explanation and the CMS explanation.