Brief for redevelopment of Umbrella sexual health services website

Back to top

1. Background information

1.1.

The Umbrella service was launched in August 2015. Umbrella is a partnership between the lead organisation (University Hospitals Birmingham NHS Foundation Trust (UHB)) and key specialist organisations across the region, delivering sexual health services to Birmingham and Solihull.

1.2.

The website for the service reflects Umbrella’s sexual health promotion activities, supports the provision of the service and helps to deliver Umbrella’s key outcomes:

1.3.

The Umbrella website is currently managed by UHB, using the Bolt content management system. The preference is to move away from this to a more widely supported system with superior site management functionality.

1.4.

In addition to a change of content management system, a redeveloped website is required, including:

2. Invitation to quote

2.1.

We are inviting three agencies to quote for the design and build of the Umbrella website.

3. Target audience

3.1.

Umbrella treats, and provides advice and information, for a diverse range of people across Birmingham and Solihull.

3.2.

The website will communicate key messages to members of the public of all ages, genders, sexual orientations and ethnic backgrounds, as well as healthcare professionals who may need to refer patients into the service.

4. Outputs and deliverables

4.1.

The Umbrella website must include all the features detailed in the current website, except where specified. This section also sets out additional requirements for the website.

4.2.

While these are minimum requirements, providers are welcome to suggest additional and alternative features, and/or methods for their delivery.

4.3. Specific requirements

4.3.1. Content management system (CMS)

The Umbrella website must be made manageable for staff of UHB, or other staff across the Umbrella partnership, via a CMS.

Prospective providers will recommend a suitable CMS for the design, build and ongoing management of the website.

The CMS must provide a fully secure environment for management of all content.

As well as providing standard options for publishing and editing content, the CMS must allow only qualified members of staff access to key files, such as CSS files, JavaScript files, page templates and any other file types required for the building and publication of web pages or sites. (Safety measures – either manual or automated – to avoid damage to the site for which the provider does not wish to be held responsible may be agreed between the provider and UHB.)

The CMS should allow qualified UHB staff access to create their own files of the types mentioned above in order to create campaign landing pages or any other bespoke content as required by the needs of the business.

The CMS must enable publication to an “as-live” testing platform, allowing for preview of content, via a domain or set of URLs separate to those used for the live site, before it is approved for publication. This testing platform must, by default, be hidden from search engine technology to prevent accidental access by the general public.

The CMS must, via a simple graphical user interface, allow creation of “advanced” functionality which would, without a CMS, require back-end development skills, including but not limited to:

  • web forms
  • events calendars

The CMS should allow for extensibility, e.g. submission of form data to external databases, if required.

4.3.2. Accessibility

In accordance with The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, the website, including all functionality and design, must be built to achieve Web Content Accessibility Guidelines (WCAG) 2.1 level AA compliance.

4.3.3. Security

The site must employ industry-standard security measures, e.g. SSL/TLS certification, to ensure secure transmission and storage of data. (If possible, this should include wildcard certification to secure sites and pages served via sub-domains, i.e. the certificate acquired for umbrellahealth.co.uk should also cover [campaign name].umbrellahealth.co.uk.)

The website and CMS must enable end-to-end encryption of submissions sent via any forms on the website, where required, to prevent unsecured transmission of any data at any point following submission via such such forms. If necessary, this should include a secure login area of the CMS or other system where UHB staff may decrypt and retrieve these submissions.

It is expected that the solution provided will be fully secure. UHB reserves the right to procure penetration testing on the website, before or after launch, and would expect that any issues found which should have been resolved during the website build, and which would constitute a security risk, will be rectified by the provider at no additional cost.

Where data is transmitted via the website, or stored as part of the website including its CMS and hosting environment, it must be transmitted and stored in accordance with the EU General Data Protection Regulation (GDPR).

4.3.4. Hosting

The chosen provider must provide a fully secure hosting solution (providers must provide details of security of their selected hosting environment).

Providers are expected to commit to a minimum website availability of 99.9%. UHB may seek compensation in instances where this requirement is not met.

4.3.5. HTML version

It is anticipated that the chosen provider will use HTML5 to build the Umbrella website, using structural markup appropriate to the version.

Where necessary, technologies such as polyfills should be used to target browsers which do not support HTML5, although it’s anticipated that there will be a minimal requirement for this. (See “Browser compatibility”, below.)

4.3.6. Browser compatibility

As a minimum, the website must be usable in Internet Explorer 9 but, via progressive enhancement, can be optimised to provide a more engaging, richer experience across other browsers. (A conditional statement for IE9 users can be included, advising them to upgrade their browser.)

A conditional statement should be included for users of Internet Explorer 8 and older, informing them that their browser is not supported, and advising them to upgrade to a more modern browser.

4.3.7. Templates

The chosen provider will develop templates based on the existing website and/or additional requirements set out in these specifications, or as agreed with UHB.

Additional templates are required for use in publishing important service updates. While we don’t need a news section as such, it would be useful to have a news story template. News stories using this template would be linked to from the “newsflash” section (see “Design”).

4.3.8. Design

The website's design must be responsive to ensure effective display on as wide a range of devices as possible. We expect the provider to adopt a mobile-first approach.

Media queries and breakpoints should not be based solely on known sizes of popular devices, and the website’s design should assume that the size and aspect ratio of the end user’s browser is unknown. An assumed minimum screen width of 320px is acceptable.

The redeveloped site will utilise a modified, extended colour palette to add richness to the user interference, including links, headings and backgrounds. No other colours, except for white, should be used in the design of the site.

Core colours
Banana a Day #f7a30b
Slate #464749
Earl Grey #ededee
Secondary colours
Teal #007681
Green #78be20
Coral #e1523d
Purple #72287b

The button which expands the navigation menu at small screen sizes should be improved to be more recognisable as providing this functionality.

The “what would you like to do?” menu should be removed from the small-screen designs for the website as this is too easily confused for the main navigation menu by users of mobile devices. The shortcuts to key pages may be added to the expanded main navigation menu, perhaps with styling which differentiate them from links to the main content sections.

The redeveloped website must contain a placeholder for “newsflash” items, such as notices about the website, availability of services, shortage of supplies etc, which can be populated and made visible when we need to make announcements.

The templates for section home pages/listing pages must be redesigned to introduce more consistency, and to remove randomised factors such as background colours. On section home pages, the design of the tiles must be redesigned to remove the difference in sizes between the various tiles, which appears to introduce a hierarchy which doesn’t actually exist.

At present, section home pages automatically lift the first few words from sub-pages and use these as summaries for the links to these pages. We’d like to change this, as sometimes the copy isn’t appropriate. If a precis is included, this should be customisable.

The website home page layout should be improved to make it less overwhelming, particularly for mobile users:

  • The tiles should provide clear shortcuts to key pieces of content, without appearing to be the main form of navigation (will be helped by improvements to navigation menu)
    • The provider will work with UHB to agree on which links will be used for these “shortcuts”
  • The carousel-type feature should be removed from the hero banner. Design may remain similar, but this should be a static image and message (although one of a number of background images being loaded at random would be acceptable)
    • The hero message and background image must be made fully editable via the CMS

An Instagram “button” should be added to the social icons list, linking to https://instagram.com/umbrellahealth.

Marginal improvements should be made to the website where required to increase usability and readability, and decrease cognitive load. Such changes may include:

  • revised text alignment, e.g. to improve consistency and readability
  • improved presentation of contraceptive demonstration images to replace the current GIF-based solution – e.g. via CSS animations
  • additional or revised affordances on links

The website must adhere to the Umbrella brand guidelines, which are currently under review. The Digital Communications Manager can advise on specific points, as required.

The main brand typeface for the Umbrella service is Avenir. This typeface should be used on the website via use of web fonts. Providers should include use of one of the commercial solutions available in its quote, but UHB may be able to share its existing web fonts package to remove this cost.

4.3.9. Templates

The chosen provider will develop templates based on the existing website and/or additional requirements set out in these specifications, or as agreed with UHB.

Additional templates are required for use in publishing important service updates. While we don’t need a news section as such, it would be useful to have a news story template. We would link to a news story, when required, from the “newsflash” section (see “Design”).

4.3.10. Cookies

In accordance with the EU “cookie law” (e-Privacy Directive) and extensions introduced by GDPR, the Umbrella website must incorporate a message informing users of the site’s use of cookies, with fully compliant options for acknowledgement and dismissal of this message and for control over installation of cookies.

4.3.11. Analytics

Google Analytics tracking code must be included to allow UHB staff and the chosen provider to measure statistics for the website. UHB will provide required account details.

Providers may suggest additional analytics tools.

4.3.12. JavaScript

JavaScript and related libraries may be used to enhance the user experience. jQuery is UHB’s preferred library.

Use of any scripting language must not discriminate against any users who have scripts switched off in their browser by making any content or functionality available only via the use of scripts.

4.3.13. CSS

The website must be styled using CSS to keep styling separate from the site’s content. It is anticipated that the provider will take advantage of CSS3’s features to provide a rich user experience.

The provider will agree with UHB a process for both parties to ensure potential issues arising from working on the same files are accounted for, e.g. via GIT, taking into account the use of any related technologies, including pre-processors such as SASS.

Print stylesheets must be provided to ensure any pages printed by website users display correctly in hard copy, omitting any unnecessary content such as navigation menus.

As with scripting languages, all parts of the site must still be accessible if a user has CSS switched off.

4.3.14. Website performance

Due to potential access limitations, e.g. slow mobile data connections, site performance is a key consideration. The chosen provider will ensure content is delivered in such a way as to optimise the loading times of site content.

4.3.15. File names and URLs

Editors must be able to configure file names and URLs via the CMS.

4.3.16. Images

Images should be optimised for hi-res display, e.g. Apple’s “Retina Display”, and served accordingly where possible, but not at the expense of site performance, i.e. loading times.

Images containing text should be avoided wherever possible, with text being displayed via HTML and CSS. Where the use of text within images is necessary, appropriate alt text must be used.

While there are multiple options for making images available in an accessible manner, UHB’s preference is that purely decorative images are added using the “background-image” property in CSS. Where it is necessary to use decorative images via the “img” element, an “alt” attribute with an empty value should be used.

4.3.17. Headings

Headings of the appropriate level should be used to add hierarchy to page content, both visually and semantically. UHB expect that best practice is employed, as per guidance issued by the W3C Web Accessibility Initiative.

4.3.18. Search

The website must feature an efficient, effective search function, allowing users to search all pages and documents.

Results should be ranked and categorised according to relevance and page/content popularity.

Search results should be accompanied by effective, useful descriptions.

4.3.19. Navigation

The website’s navigation menus should be automated to include pages when published, without the need for editors to manually build menus.

The menus should accurately reflect the site’s structure and hierarchy, and it should be made as easy as possible to specify a hierarchy within the CMS if necessary, e.g. by selecting a parent page within the page’s properties.

The ability to set or manage hierarchy must be available within the CMS. There must be no requirement for UHB to contact the provider to change a page’s type or status in order for it to be given children or parent pages.

The website will employ a clear navigation system, making it easy for users to navigate between all areas of interest without the need to use the browser’s native navigation tools (i.e. “back” and “forward” buttons).

The provider will work with UHB to agree revisions to the design and basic functioning of the website’s navigation menus, e.g.:

  • whether clicking main navigation menu items expands a sub-menu, as at present, or takes the user to the relevant section
    • Note, user testing revealed that some users would have liked to have seen descriptions of what links meant within the menu, which would be more viable if, instead of expanders, links took the user straight to the section home page
  • which affordances appear on the main navigation menu links, and how these are included as parts of the links themselves
  • whether section navigation should appear on the page by default, particularly at larger screen sizes, rather than being hidden behind expanders

While no significant change in the main content sections is expected, it should be made easy for editors to add another section to the website and for the inclusion of this to be reflected in the main navigation, which should be automated as far as possible.

4.3.20. User orientation

The website’s design must include visual/usability cues to inform the user where they are within the site’s navigational structure, including clear indication within navigation menus of the page currently being viewed.

Users should also be able to identify where they are within the site via a breadcrumb trail (this may be excluded for smaller screen sizes using media queries if agreed to be appropriate between the provider and UHB). Where a breadcrumb trail is not included, the navigation menu should provide equivalent user orientation.

4.3.21. Pages with tabbed content

User testing has shown that pages broken down into tabbed content are effective, and that users recognise and interact with the tabs to read further information. However, we would like the editing of these pages to be improved so that each compiled page is edited in one place as one page. (Currently, each tab has its own page in the CMS, and editors have to tell the destination page which sub-pages to pull in to form the tabbed content.)

Design of the tabs should be improved to offer clearer affordances.

4.3.22. Error pages

Rather than just a basic 404 page, for example, error pages should signpost users to appropriate information.

4.3.23. Downloadable files

Any downloadable files, e.g. PDFs, should be accompanied by information on file type and size. The CMS should add these details to relevant links automatically, ideally within link text to make links as descriptive and accessible as possible.

4.3.24. Links

If possible, the CMS should allow central management of links to other websites, pages within the Umbrella site and downloadable files, e.g. allowing site administrators/editors to view details of all pages on which a particular link has been used.

4.3.25. Videos

UHB intends to use YouTube or similar hosting services to host its video content, and embed videos into the Umbrella website where relevant. Providers may consider advantages of other video streaming services, e.g. JW Player, and include details in their quote.

4.3.26. Key signposting pages

Provider to work with UHB to design updated versions of these pages to fit with other design improvements, or to devise alternative methods of signposting to the same content.

4.3.27. Service locator

The website must include a service locator, allowing users to find the following services closest to them:

  • Clinics
  • GP surgeries
  • Pharmacies

In addition to location of services relative to a postcode, as at present, geo-location should be added as per standard practice for “store locator”-type functionality, i.e. via a “Use my location” option.

The service locator must provide the following for each location:

  • Name of clinic/pharmacy/GP practice
  • Map
  • Directions
  • Contact details, including full address
  • List of services provided
  • Opening times (clinics and pharmacies)
  • Link to website (GPs)

Where items above are only applicable to certain service types, editors should be able to turn these on and off in the CMS as required.

Editors must be able to add and edit additional text as required, e.g. for pharmacies: “Please call to confirm availability of Umbrella pharmacist”.

Editors must be able to add bespoke information around opening times and services – e.g. bank holiday arrangements, or temporary issues affecting specific services.

UHB will provide details of locations, service types, contact details and times.

Ideally, for ease of management, the service locator should be updatable by uploading a spreadsheet or similar file containing the full and accurate record of all service locations. If this is not possible, the CMS should make it as easy as possible to edit details of service locations and ensure that all records are correct.

The CMS should allow UHB to specify exact locations of service locations via coordinates and/or a drag-and-drop map marker. Other common but less reliable identifiers, e.g. postcode, must not be relied upon to provide accuracy.

The CMS should allow editors to search and filter service locations via multiple criteria, including the following, for ease of management:

  • Location type (GP, pharmacy, clinic)
  • Clinic/pharmacy/GP practice name
  • Postcode
  • Phone number

The more granular, the better, as only being able to search by name is restrictive. For example, Boots has multiple branches, so being able to search by branch-specific details, or filter further, would be ideal.

The phone number for each service location should be a mobile-friendly telephone number link.

The service locator must be set up in such a way that editors can create links to it from other pages with specific filters pre-applied, e.g. via URLs including query strings with parameters which reflect the relevant filters.

To ensure correct display, and avoid confusion, service locator entries for individual services must not be available as pages in their own right in the same way as at present. However, it would be ideal to have each location available as its own page, but still displayed in the context of the service locator, so we can link to individual locations from other pages where required.

Options for filtering must be expanded to include the ability to search by services provided, rather than just location type:

  • Each of the services offered at the locations should be selectable so that, as well as searching geographically, users can search by type of service offered (UHB to provide initial list). This will probably be grouped into categories.
  • List should be manageable via the CMS so editors can add a new service type or category, which will then be added to the live list automatically
  • When adding a new location (or editing a location) in the CMS, we’d like to be able to choose which services are available at these from a list
  • Ideally, initial list of services offered should be generated in the CMS

The new default should be that if somebody visits the service locator without entering a postcode, they see all locations, unfiltered (rather than clinics only, as at present).

The design of filtering options and postcode search must be improved so it is clearer to the user that they are able to customise the results, and clearer which filters are currently applied.

Where pagination is required due to the number of service locations on offer, this must be made more prominent (e.g. via pagination appearing at the top of the list, as well as at the bottom).

Pagination should also be improved to make user orientation clearer, e.g. “Showing 1 – 20 of 80” / “Go to page XX” etc.

Prospective providers are welcome to suggest additional improvements to the service locator.

4.3.28. "Pathways"

The “find the right service for you” feature (known internally as “pathways”), is currently delivered as a series of static web pages, and each page in each pathway can be accessed as a standalone page via its URL. To avoid confusion, or the provision of potentially misleading advice, we would prefer a solution which only allows a step in the pathway to be viewed once the previous step has been completed. Prospective providers are invited to provide suggestions for how to achieve this.

We would like this to be templated so editors should be able to fully edit pathways, including:

  • Addition of steps
  • Deletion of steps
  • Editing of questions and options
  • Advice/outcomes

Each step of the pathway needs to make it clear to users that the options chosen are only used for signposting to appropriate advice, and aren’t stored anywhere.

4.3.29. FAQs

The website must feature frequently asked questions, which can be published by section.

There must be an option to turn FAQs on or off for any particular section, depending on whether any questions and answers are available for that section.

To provide an alternative way to access FAQs, we would also like the option to push the FAQs into one combined FAQs page, preferably broken down by section headings.

The design and functionality of the expanders within FAQs should be improved. Providers are invited to make suggestions for improvement.

4.3.30. Mythbusters

The website must feature “mythbusters”, which can be published by section.

There must be an option to turn mythbusters on or off for any particular section, depending on whether any myths and facts are available for that section.

To provide an alternative way to access mythbusters, we would also like the option to push the mythbusters into one combined mythbusters page, preferably broken down by section headings.

The design and functionality of the expanders within mythbusters should be improved. Providers are invited to make suggestions for improvement.

4.3.31. Twitter feed

A feed of tweets posted by Umbrella is currently included on the website home page. The provider will agree with UHB whether this should be carried over to the redesigned site and if so, whether it should be revised.

4.3.32. Other improvements

We have been considering the following improvements, and providers are invited to make suggestions:

  • Improved listing of partners, e.g. by type of service, rather than name of partner organisation ("About us" → "Our partners")
  • How to display services in the “our services” section to reduce the length of the list but improve or at least maintain ease of access to information about each service
  • A comparison tool for the contraception section to allow site users to find contraception types via different characteristics, e.g. rate of effectiveness, length of effectiveness, ease of application etc
  • Allow users to filter STIs by symptoms
    • This would require careful consideration as not all STIs have symptoms for all people who have them

4.3.33. Legal

In addition to the requirements around accessibility, cookie usage, and the handling and storage of data, the website must include pages for terms and conditions and a privacy policy. UHB will provide the content for these pages, with input and advice from the provider where relevant.

The privacy policy may include information necessary to comply with legal requirements relating to the use of cookies.

4.3.34. Transferability

If it subsequently becomes necessary to work with other providers or change the way content is delivered, the CMS, hosting and all content must be easy to migrate.

The chosen provider must not implement or use any language, technology or frameworks which are only accessible to, or manageable by, themselves and which would therefore preclude migration to another solution or provider.

4.3.35. Account management

Providers must indicate how they intend to manage timescales and resources for the project.

The chosen provider will specify dedicated account management resources.

The chosen provider will work with UHB on projected project milestones, which will be made clear and agreed by both parties on commencement.

4.3.36. Support

The chosen provider must be able to provide ongoing website support and maintenance. Quotes should include suggested options for this, e.g. retainers, ad hoc support, with costs for each option.

5. Quote timings

Quotes must be received by UHB on or before Friday 31 January 2020.

6. Schedule

Thursday 6 February (TBC) Interviews with prospective providers
Tuesday 11 February (TBC) Award of tender
Monday 15 June (TBC) Website launch

Deadlines for key stages of project to be agreed on commencement.

7. Scoring criteria for awarding tender

CriteriaWeight (%)
Technical excellence 16
Suitable approach for carrying out the task 15
Relevant experience/knowledge for particular task/work area 15
Clear understanding of the task 15
Proposing a strong team with the right skills and experience 15
Meeting the set timescale 10
Value for money 5
Satisfactory customer references 3
Relevant experience/knowledge of NHS 3
Financial standing of the company 3