Invitation to tender for Renfrewshire.gov.uk Alpha phase

Table of contents

• What our Digital Experience (DXP) vision is
• What we learned in our Discovery phase
• We want a new approach to our digital experience
• What we want to achieve in Alpha
• What the procurement timeline is

What our Digital Experience (DXP) vision is

In short, our vision is to develop a successful digital experience that is seamless, integrated, consistent and personalised.

This successful digital experience will solve real problems and create value and positive experiences for our citizens, local communities, and colleagues. It will deliver valuable information and services, improve the way we work, and enhance the efficiency of our services.

You can read more about the vision and programme on The Thread.

What we learned in our Discovery phase

Our research in Discovery validated the diagnosis we made from our Pre-Discovery phase: our current digital experience is not working. It is fractured and inadequately supported by the existing content, design, technology, brands, and ways of working.

We categorised the issues and challenges we gathered into four themes. Based on these, we identified practical solutions to simplify our digital experience and support it with a new way of working and a new infrastructure for our content, design, and technology.

One of these solutions is to develop the new Renfrewshire.gov.uk based on a structured content model on Drupal – with Acquia – and GatherContent, with the launch of beta planned for the second part of 2023. You can read this article to see a bit more of the insights we gathered in Discovery and the key changes we are going to implement in the future.

We want a new approach to our digital experience

One of the key changes is around our approach for developing new digital services. Everyone in the Digital Experience team has worked on many digital products such as websites. We all learned the hard way that building digital interfaces that have a design-first, desktop-first, and action-first approach is not future proof. Most of our websites have been designed with this approach in mind and we know where this led us.

We want to change this by adopting a mobile-first, content-first, and object-first approach for any digital applications we want to build or optimise, starting with the new version of Renfrewshire.gov.uk. We haven’t really seen this approach talked about in the Scottish or UK local government. This is an opportunity to be innovative in our sector.

Why we want to go mobile-first

More than 70% of users visit Renfrewshire.gov.uk on a mobile device so we need to build for them first. Being mobile-first means that we are going to sequentially rank objects based on their value according to our users. This will help us prioritise content and functionality that are valuable and eliminate what isn’t. This will lead to simpler designs that are easier to code and that provide faster load times, which is critical for SEO and people who don’t have Wi-Fi access.

Why we want to go content-first

The most important component of any digital product is content. We’ve seen too many of our digital interfaces being designed and coded first. This is always very costly because we end up retrofitting content into our pre-envisioned interface and eventually, we realise that the interface we designed first needs re-designed and re-coded to fit the content.

Understanding, modelling, and prioritising our content before designing and developing the interface is mandatory. This will remove most design constraints and help us deliver the right content, in the right format, in the right place, at the right time. It also means that our content will focus on semantics (service description, service eligibility, location, opening hours, cost, testimonial) rather than layouts (preamble, media gallery, carousel, tab, accordion, text block, video block, hero header image). We’ll use structured data sources such as schema.org and the Dublin Core Metadata Schema to inform these semantics. This will push for content adaptability and reusability across digital products (websites, Google knowledge panels and search snippets, mobile apps, Siri, etc.). Also, this will make sure that our design system and CMS are not just a pile of reusable layouts, they will define how these semantics – or objects – should present themselves consistently across the board.

Why we want to lead with an object-first methodology

Experts also call it Object-Oriented UX or Structured Content. All humans think in object, using nouns before verbs.

If you were to walk in a grocery shop, you would first think of nouns such as hand-sanitizer, trolley, fruits, vegetables, bags, coupons, etc. Only after you think about those things will you decide what you’d like to do with them, you would then think of verbs or actions. How to wash your hands with hand-sanitizer, how to get an empty trolley, how to use coupons, and how to pay for the fruits and vegetables in your trolley and put them in a bag, etc.

The same applies online. As a resident in Renfrewshire, you might visit Google and Renfrewshire.gov.uk looking for objects like council tax, parks, schools, jobs, holidays, bins, elections, councillors, or volunteering. You will then determine what to do with these objects such as how to pay council tax, how to apply for a school place, how to report a missed bin collection, or how to find your councillor. With this approach, we prioritise the objects before the actions.

We’ve seen many council websites prioritising tasks, where verbs are put before nouns and sometimes without nouns at all. For example, in their menu and homepage you will see things like ‘Click to report’, ‘Pay it online’, ‘Request it’, or ‘Book’. Councils often prioritise tasks because it aligns with their objective to make their services more efficient. We sometimes assume – wrongly – that a highly visible ‘Pay’ call-to-action on the menu of our website will increase online payments and reduce the ones over the phone. This task-first approach is not aligned with people’s mental model. People will think and search for ‘council tax’, ‘parking fine’, or ‘birth certificate’. They won’t think and search for ‘pay’. We have data to evidence this. Stats for Renfrewshire.gov.uk on the Google Search Console and the internal search show us that no verbs are searched for in the top 250 queries. All queries are nouns.

Being object-first will help us simplify the complexity of our information and services and create an easier user experience that is matching people’s mental model. In turn, this will make the objective for service efficiency easier to reach. This will also create a common language for everyone working on our digital experience, including subject matter experts, content designers, interaction designers, and developers.

What we want to achieve in Alpha

To define what we want to achieve in Alpha, we particularly looked at what other organisations usually do in this phase and what approach and processes they are using. We also looked at some methodologies around creating content and interfaces that are mobile-first, content-first, and object-first. We have been inspired by the Connected Content approach from Carrie Hane and Mike Atherton, the ORCA and triple diamond process from Sophia Prater, the Structured Content Design Workflow from Andy Fitzgerald, and the full stack design system by Emmet Connolly.

Some of these methodologies have been successfully used in many digital projects, including the US election night interface for CNN.com or the re-platforming of the City of Sydney website. Sydney’s domain and content modelling and the Structured Content Stack approach have really inspired us, and we would like to use a similar approach in our Alpha phase. Of course, we are open to different methodologies and processes if you think they would be better suited to meet our goals. The work outlined below is what we want to achieve in Alpha:

• build a domain model of a Scottish Local Authority
• build a content model for Renfrewshire Council
• develop the foundations of an object-oriented design system for Renfrewshire Council’s digital interfaces
• sketch and test mobile-first prototypes for Renfrewshire.gov.uk
• test how the Drupal and GatherContent platforms can support our approach and content model
• define Beta phase.

To inform, build, test, and refine the models, design system, IA, and prototypes, we will expect you to reuse our findings from the two services deep-dives we did in Discovery and carry out some service design activities for two or three areas (e.g. school admissions, fostering, employability support, recruitment process, employee induction).

Build a domain model

In our Discovery phase, we learned that we don’t have a common understanding of what Renfrewshire Council represents and does. Across our digital experience, we often talk about the same things in very different ways. There is no shared language. For instance, ‘tackling hate crime’ can be referred as a service, guidance, advice, initiative, or policy. This lack of conformity confuses users and will make the development of a content model impossible.

This made us think that we need to understand what a Scottish Local Authority is according to Renfrewshire Council and its users’ mental models, independently of how our digital touchpoints currently think it is. That’s why we want to start Alpha by building a domain model.

A domain model is not a map of Renfrewshire.gov.uk. It maps the objects within a subject area and captures the language people use to describe these objects and the relationships between objects. The objects in our domain model will most likely include people, places, and things like services, assets, consultations, parks, schools, citizens, businesses, employees, councillors, committees, projects, initiatives, etc. We expect desk research (e.g. noun foraging from the latest Council Plan) and interviews and workshops with subject-matter experts and service users to build this model.

We are aware that this model could cover a significant number of different things and each of these things could easily be a whole model on its own. The point of this model is to provide context for the content model and everything else that follows based on a subject rather than an organisation’s structure or an existing channel. We want it to be holistic rather than too granular. We want to keep it simple and manageable to cultivate a shared understanding with relevant stakeholders on the most important and common objects within the model. We expect our domain model to be similar to the one built for the City of Sydney’s website re-platforming.

Build a content model system

From the domain model, we want to identify what part of the model we want to expose and build upon in a content model. A content model can also be referred as a structured content model or an object-oriented map. We will refer to the term content model for clarity.

A content model isn’t a sitemap. In fact, we don’t want to start with any sitemaps to define our content. We don’t want to think about the Renfrewshire.gov.uk interface at this stage either. Content isn’t linear and it isn’t tied to any particular representation or delivery method. We don’t get to decide which platform or device our users use to access our content; they do. That’s why we want to model content independent of how a website, app or other touchpoint interprets it.

To build this content model, we would like to follow the ORCA and triple diamond process or similar and action the following:

• Define content types and group them when necessary. For example, content types could be consultation, project, space, profile, place, event, service, vision, etc.
• Map the content types’ relationships. For example, a consultation informs a project within a vision that aims to improve a place and this consultation can happen in a space.
• Define the calls-to-action they offer users. For example, a consultation calls a user to be informed and provide feedback on a project.
• Understand the attributes that make up each content type. These attributes should ideally be based on Schema.org and the Dublin Core Metadata Schema. For example, a consultation has a description, period, status, type, contact name, contact role, contact email address, contact phone number, etc. These attributes would be reusable across multiple content types.
• Define some instances for each content type. For example, the ‘Have your say on Barshaw park’s community garden’ consultation invites the local communities from Paisley North to inform the Local Regeneration project 2022-25 (consultation + user + place + project).
• Prioritise and sequence content types as well as their relationships, CTAs and attributes based on organisational objectives and users’ needs.
• Sketch and wireframe content types and test with users.

As part of this content model, we will also need to start looking at the label and classification – taxonomy – of topics within content types. For example, in the ‘Services’ content type we could have services categorised under ‘waste and recycling’, ‘transport and parking’, and ‘building and construction’. In the ‘plans’ content type we could have plans categorised under ‘environmental action’, ‘people and communities’, and ‘business and economy’.

Develop the foundations of an object-oriented design system

Once we have our content model, we want to design the representation, starting with a design system. A design system will help us save time, reduce cognitive load on our users, and build brand trust through consistency. We want to use a design system for Renfrewshire.gov.uk and other channels.

We want to lay the foundation for a design system that is specifically tailored to our domain and content models and focuses on objects and attributes rather than layouts and components. Emmet Connolly calls this the full stack design system where you style the objects and their pieces.

Sketch and test mobile-first prototypes for Renfrewshire.gov.uk

After we have determined our content types and their pieces and developed a design system that is tailored to them, we want to build prototypes for the interface of Renfrewshire.gov.uk. These prototypes must be mobile-first and they will represent content types and the overall navigation model of the website. Again, we’re not interested in designing the representation of a linear sitemap. Users and robots navigate to information in multiple ways, our information architecture and navigation need to factor this.

With prototypes, we want to test the representation of content types and their relationships. We also want to validate primary and secondary menus and other means of navigation (e.g. local menus, contextual links, and related content) on any page so our users can navigate through content in multiple ways and wherever they start their journey from.

Test how Drupal and GatherContent platforms can support our approach and content model

In Discovery, we identified Drupal – with Acquia – and GatherContent as our future platforms to manage our content and Renfrewshire.gov.uk. We want to validate them in Alpha by making sure these platforms are good value for money and can support a mobile first, content first, and object-first approach and successfully implement our content model.

For example, we want to:

• understand how these platforms would work together to support portable and independent objects across multiple locations and build better structured data for SEO
• ensure that the content model can work with the inherent quirks of Drupal and GatherContent
• find out if Drupal can support publicly available staff content which may require user authentication
• find out if Acquia is the right hosting platform to support Drupal.

The goal is to have an infrastructure that is future-proof. If we find that these platforms are not suitable, we would want recommendations of other platforms.

Define Beta phase

We want to complete Alpha by defining the minimum viable product for Beta and the activities required to achieve it. Validating the investment requirement for Beta implementation with the new technology will be needed too.

Conduct service deep dives to inform, build, test, and refine the Alpha phase

To inform, build, test, and refine the models, design system, and prototypes, we would also expect you to reuse our findings from the two service deep-dives we did in Discovery and carry out some service design activities for two or three areas (e.g. school admissions, employability support, recruitment, employee induction).

This will allow us to:

• identify and use real instances and user stories to inform and test our domain and content models
• improve our understanding of our users with personas and identify what the different level of confidence and expertise they have to find and use a service
• bring real context with user flows to inform and test the content model and prototypes.

What the procurement timeline is

These are the key procurement dates for Alpha:

• Published on Digital Marketplace: Thursday 25 August 2022
• Deadline for asking questions: Thursday 1 September 2022
• Closing date for applications: Thursday 8 September 2022
• Stage 1 shortlisting: Friday 9 – Wednesday 21 September 2022
• Feedback to suppliers not shortlisted: Thursday 22 September 2022
• Stage 2 invitation to submit proposal for shortlisted suppliers: Thursday 22 September 2022
• Stage 2 deadline for asking questions: Thursday 29 September 2022 at noon
• Stage 2 closing date for submitting proposal: Friday 7 October 2022 at noon
• Stage 2 evaluation: Monday 10 – Friday 21 October 2022 (plus 1 or 2 weeks if needed)
• Stage 2 update to suppliers: Week beginning 24 October 2022
• Contract award: December – January 2022
• Expected contract: up to 6 months.

Order forms and schedules

You can download draft copies of the Order Form, Joint Schedules and Call Off Schedules. These have been included for reference only in order to note the additional Terms and Conditions and the documents will be required to be completed by the successful supplier, later in the process.