East Sussex Highways (ESH) is the organisation responsible for roads and highways in East Sussex and operates separately from, but is funded by, East Sussex County Council. East Sussex Highways have various responsibilities from the obvious, such as pot hole repairs, gritting in bad weather, traffic control signals and signage, to the less so including grass cutting, gully cleaning, street light maintenance and permits for private works. So, they are busy! They are highly public focused and have over 20 staff dealing with customer enquiries.
The project brief was to build a new public facing website as a direct replacement for their existing one which was deemed to be under performing and inflexible.
The website has two headline requirements – issue reporting and public information, both required attention.
The public facing issue reporting system was difficult to use and because of this a worryingly low percentage were being reported via the website, the majority being reported via phone or direct email. A key target for the project was to increase the percentage of issues reported via the website as this cuts down on time taken to log issues by ESH staff therefore increasing overall organisation efficiency.
The remaining website content, public information, was also in need of some re-organisation and simplification to improve the information architecture to aid and improve public access.
With a project as big as this it is imperative to make sure that all parties are engaged, involved and can all input into the project brief. We agreed a schedule of fortnightly meetings with the ESH project team and a variable team from us depending on what was up for discussion although as part of our project proposal we suggested various focus group engagements. With the help of ESH we organised and ran three groups:
1. Internal user focus group
ESH directors, management and staff were engaged to make sure that the expectation of the final product was fully understood. New ideas were gathered and key metrics to measure success were discussed and agreed.
2. Local Government and councillors
This was a group we had not known about or considered prior to project start. This group has direct contact at ‘the ground level’ with residents through public meetings, local offices and as the councillors are elected members they are very engaged with their electorate. In fact, we discovered that the local councillors that were using the previous site on behalf of residents, so it was essential that we understood their issues with the old site and their wishes for the new.
As a key aim of the site was to engage the public and encourage issue reporting and improved knowledge availability members of the public were also consulted to further understand what they wanted from the new site.
I think for me that the biggest thing I liked about working with BarkWeb was how friendly they were and their ability to put complex technical concepts into plain English (both for us and the focus groups) without making me feel stupid! Also their ability to come up with design solutions to the problems we had with the old website themselves without us having to solve the problems for them and tell them exactly what we wanted.
Choosing the platform for delivery
During the procurement process we suggested that our own in-house Content Management System (CMS) was used. Due to the lead time between first engagement and winning the project our third generation CMS (Jolojo) was reaching its first full release, so we jointly decided that the new system would be employed for the project.
The previous website had been developed on www.umbraco.com and ESH were disappointed by the support given and the inflexibility of the core CMS system. Being an early adopter of our new platform gave ESH the advantage of being influential in certain real-world functionality and as Jolojo is a fully API driven back-end and headless application we felt it would be simpler and easier to develop the application using the newer technologies it employs.
The main functionality of the site, distinct from normal content delivery, was the Report an Issue system that passed issues directly into Sales Force – www.salesforce.com.
This meant that the required functionality was already known, this mixed with the expert inhouse knowledge of Sales Force within ESH massively decreased the application design phase and we could focus on the user journey, user experience and user interaction – all key requirements of the project.
Application and design separation
At this point of the project the coding part of the project (application build) and design separated from each other. This allowed us to start the application build without relying on a finalised design.
It can be dangerous to start the back-end development too soon in a project but as we had a known data set to send via the Salesforce API this was considered to be appropriate and would help deliver the project in a timely manner.
Design wire framing
Once the focus groups had been engaged the first design phase was to create wire frames of the site functionality removing any graphical design elements (colour and images) to focus purely on layout and functionality.
The wire frames were discussed, tweaked and then signed off to go into detailed design.
Graphical design and mock-ups
Our preferred tool these days is Adobe XD https://www.adobe.com/uk/products/xd.html and this was used to produce the first graphical designs and design mock-ups. The advantage of XD is it allows interactive mock-ups. It is a little clunky and requires a little explanation to manage user expectation (such as ‘this may look like a website but it is not’), however it is mostly an excellent tool.
It is quite normal to choose either a ‘desktop first’ or ‘mobile first’ design approach. Our wireframes were produced in both formats and we continued this into design. Tablets sit between both device sizes having a screen size nearer a desktop but employing touch navigation, these devices were considered to be less of an issue as the layout would not differ dramatically from a desktop and the interactions were already catered for within the mobile considerations.
We then went through a few design and interactive mock-up modifications as is normal for projects of this type. Final sign-off from ESH triggered the next round of focus group engagements.
Re-engaging with focus groups
Once the designs were internally agreed we then re-engaged with the task groups. Each focus group was shown the design and shown the Adobe XD work-flow of the report an issue functionality and information architecture. In effect they were demonstrated the suggested site without us having to build the site itself.
It can be very easy to sell to focus groups, we were very aware of this and tried to minimise any inherent ownership or parenting of the mock-ups. It is essential that even the smallest observation, comment or suggestion is noted and explored in an open and frank environment.
Most of the improvements suggested were to the design of the site, the use of images and the placement and use of text. With any project of this size, it is easy to overlook ‘the normal user’ the focus group engagements meant that we were well focused at key stages.
Joining back-end and front end
Once we had finalised the graphical design it was time to get building. We staged the build so that particular elements of the site could be considered separately within the fortnightly meetings and ESH could provide internal knowledge and personnel when needed.
There is no hardest stage of any website build, each stage is important, needs consideration and proper project management but the bringing of all the pieces together stage, joining the back-end code and painting it with the design is where all parties start to see the fruits of their labour.
Internal delivery and training
We like to deliver the first iteration of any website on a known device size, so we chose desktop for preliminary internal testing.
All data interactions were tested and users were trained to use Jolojo CMS. Content started to be populated. Bugs were fixed and the final few nips and tucks made.
During this process we also started our internal quality control sign off which includes testing on multiple device types (Android and Apple phones, tablets and desktops) and browsers, mapping any old URLs, W3C checks, Page Speed optimisation and pre-launch SEO.
This final stage took just under a month in which time very little was obviously changed but the devil is in the detail and the detail is what makes a website either work or flop.
Working with BarkWeb couldn’t have been easier. They responded quickly to any queries that we had and worked fast to find the best solution for us. Our project wasn’t easy and we’re really impressed with the end results. No problem was too complicated. All of the team were friendly and helpful
Sign-off and launch
Once all testing had been completed the website was moved to a production server and DNS changed. The launch of the site was ‘soft’ so we didn’t get out the bunting and shout about it immediately. Taking a site from development to live can always potentially cause issues but thankfully these were minimal.
We kept a keen eye on Google Analytics on the first day and the first issue was reported within 30 minutes of the DNS being changed.
We consider launching a website the start of ‘the next phase’, once the baby is born it does need looking after, an occasional tweak and change. We continue to monitor Google analytics and the site performance in Google and Bing organic search rankings as well as Google search console to make sure any indexing issues are fixed quickly.
Additional functionality that had to be parked during phase 1 is now being planned and we continue to support ESH as the website gains acceptance and use.
Below is a video of the report a problem functionality.