Content: Michael Soane, Ivy Halstead-Dawber
Policy: Tony Leavy
Interaction Designer: Laura Power
To recap, Manage your DfE Connect data is the ‘internal’ counterpart to DfE Connect, where internal DfE employees across departments can feed information to DfE Connect for School Business Professionals to view or action. See other design histories on specific areas such as tasks and subtasks, tags and taxonomies, managing service details and the status workflow changes.
Designing for superusers
For this release, we focused on superusers and will explore other audiences such as DfE colleagues next. This means some functionality is no longer required for now (as it was previously designed for colleague users). In summary, superusers can see and do all actions, they have all permissions and are considered experts of the system. In these updated designs for delivery, it was crucial to ensure all minimal viable product (MVP) functionality is available for them. We took an iterative, co-design approach and worked closely with superusers within the DfE Connect team to drive design decisions.
Updated homepage
A simple homepage was designed allowing superusers to toggle between recently updated and recently published tasks (using the sub navigation component). Since personalisation and interaction with colleagues is not yet in scope, we kept the homepage simple with acknowledgement that iterations and additions will be made in the near future. The ability to Create a task and Add a service remains, although the language has changed from ‘add’ to ‘create’ a task. The terminology was changed to differentiate the two processes. Users ‘create’ a task, meaning they make something new whereas ‘add’ is used when a user is adding information from a source that already exists. For example, a user can ‘add’ a service to DfE Connect, they are not creating a new one.
Error messages
We’ve added validation to the service. When creating or adding items within the journey there are many mandatory fields for inputting information. We have created a simple validation that requires these fields to be filled, a user cannot progress through the journey without filling all mandatory fields. An example of a mandatory field validation. The error message will trigger if the user attempts to continue through to the next page without filling in a mandatory text field.
There are standard validations for dates. Tasks and subtasks are not allowed to have due dates that are before their start dates, start dates are not allowed to be after their due date. As more complex journeys are added to the service, more complex validations and error messages will be created to reflect them.
Removing the phase banner
Designing for superusers only means there is no need for the phase banner as users would be providing feedback to themselves. We anticipate including the phase banner when we expand to DfE Colleagues and other DfE professionals.