Skip to main content

04. Make the service simple to use

Build a service that’s simple, intuitive and comprehensible. And test it with users to make sure it works for them.

Make sure the service helps the user to do the thing they need to do as simply as possible - so that people succeed first time, with the minimum of help

  • We have used existing design patterns and learnings from other services to ensure that we make elements of our service simple and straightforward to use.
  • Extensive user testing has been carried out to try and identify any sticking points for the user and ensure that the service is as easy to use as possible. Further user testing was conducted with Cranfield University students before the private beta launch.
  • User research has been continued through public beta with operator users, prospective users and Cranfield University, we are constantly iterating the service to ensure it is simple and user friendly.

Test for usability frequently with actual and potential users, using appropriate research techniques

  • Discovery - open ended questions and semi structured interviews with several user groups to understand who might need a product and the prioritisation of those groups
  • Alpha testing - testing the prototype with users and iterating based on their feedback
  • Cranfield University testing event - testing the MVP prototype with potential users (students)
  • Private beta trial - actual users tested the service and provide feedback throughout. Test users were able to provide feedback through a feedback page on the website, through surveys, 1-2-1 sessions, or at drop-in workshops during the private beta.
  • Public beta - frequent and appropriate research with actual and potential users through:
    • Feedback banner on the website;
    • 1-month follow up email and check-in with actual users;
    • Research survey run by consultancy London Economics to gain better insights into the service;
    • Introductory webinars that include a presentation and demo with potential new users.

Test all the parts of the service that the user interacts with - online parts and offline parts (like letters)

  • At the moment there are no offline parts of the service that our users interact with.
  • No letters are sent.
  • There are occasional telephone calls between operators; but the vast majority of space surveillance and tracking/ orbital analysis work is currently done over email.
  • This is actually a key advantage of MSH and one which comes out strongly in the user research with both government and operator users: having an auditable log of alerts and the interactions around them is itself hugely valuable:
    • Operators can see how many alerts have affected each of their satellites.
    • Regulators can see how proactively operators are managing their satellites.
    • Everyone can have a perma-URL with the history of the alert available.
    • MSH will log and record all communications about an event, including messages sent between operators, analysts, regulators and the SST team.

Design the service to work online with a range of devices that reflects users’ behaviour

  • The service is being designed so that it works on laptops and mobile devices.
  • There is horizontal scrolling on all events pages that seems frustrating. This is a specific request from our users and is a product of the large amounts of data necessary to make wise decisions.
  • Users can choose if notifications are sent by email and/or SMS, allowing users to access alerts on laptops or mobile devices depending on their preferences.

Services should also provide users with a consistent experience from start to finish. For GOV.UK services, this means:

* Being consistent with the design of GOV.UK

* Following the GOV.UK style guide for all text, online and offline

  • We believe the design is entirely consistent with the GOV.UK style guide and have always tried to follow the prototype patterns and use the appropriate components and styles. We used the style guide to ensure we met the spelling and grammar conventions.
  • There are some requests for visualisations which are not fully covered in the design style guide. We have therefore built on patterns which are visible in, for example, the Performance Platform.
  • Operators have by and large all requested scientific notation for the numbers published, while government users have expressed a strong preference for standard decimal places (ie 0.00003% rather than 3*e^-4). We have therefore provided different number formats for different users.
  • On a few occasions, some non-GOV.UK styled text has made it onto the prototype. We think we have now addressed and corrected all of these.
This page was last reviewed on 7 December 2022. It needs to be reviewed again on 7 June 2023 .
This page was set to be reviewed before 7 June 2023. This might mean the content is out of date.