Posts

  1. Selecting organisation level permissions by type

    Grouping permissions by type instead of organisation to better handle validation errors

  2. Displaying safeguarding information

    The way we show sensitive material to users differs, depending on whether or not they have permission to view

  3. Sorting by reject by default (RBD) date

    Let users sort by RBD date

  4. More context for providers

    Help providers make sense of application form responses by showing them guidance to candidates

  5. Notifications

    Notify users when certain things happen and let users configure what notifications they receive

  6. Reasons for rejection iteration 3

    Combined some questions onto one page, added an additional question and improved content

  7. Setting user permissions: context and user research

    Users and organisations need to configure permissions to make decisions, see safeguarding information and set controls for other users. Here’s how we arrived at our designs

  8. Reasons for rejection iteration 2

    Helping providers give useful feedback to candidates who’ve been rejected

  9. Setting up permissions (iteration 4)

    Showing a confirmation page after agreeing to the data sharing agreement, not asking users to setup permissions when they both run and ratify their courses, explaining the consequences of inviting someone from outside the organisation and various other content improvements.

  10. Setting up permissions (iteration 3)

    Handling when the user belongs to multiple organisations and including clearer guidance for how permissions work.

  11. Setting up permissions (iteration 2)

    Helping users understand what it means to set up organisational permissions and what default access means. Plus a few other improvements.

  12. Setting up permissions

    Let providers set up permissions between themselves and their partner organisations

  13. Making a decision iteration 2

    Let users make offers to different training providers, courses, locations

  14. Breaking apart the application page (sub navigation)

    Help providers navigate the parts of an application more easily with sub navigation

  15. Improved header

    Changes to the header and navigation layout

  16. Reasons for rejection

    Helping providers give useful feedback to candidates who have been rejected

  17. Application layout changes

    Various layout changes to make room for new features and improve existing ones

  18. Giving teacher training providers longer to make decisions on applications because of coronavirus (COVID-19)

    Communicating temporary changes to the decline by default and reject by default decision dates.

  19. Process and rules for changing a course

    Process that providers follow when changing a candidate’s course.

  20. Card layout for application list

    Use a card layout to fit more information inside each row without sacrificing readability and scannability.

  21. Tracking conditions individually

    Let providers track and update the status of offer conditions individually.

  22. Timeline

    Added a timeline component as a form of audit trail.

  23. Improving check and confirm content

    Improving the content for checking and confirming a provider workflow action.

  24. Offer panel

    New offer panel design to better accomodate various states and content.

  25. Offer a different course

    First iteration of making an offer to a different course.

  26. Withdrawing an offer

    Flow for withdrawing an offer.

  27. Adding users

    First iteration of letting users invite other users to their organisation(s) to help manage applications.

  28. Marketing page for providers

    A page selling the benefits of joining the Apply pilot.

  29. Filtering applications

    Let users find items a long list of applications by status and provider.

  30. As launched on 26 November 2019

    List applications, make offer or reject.

  31. An interface for minimal service provision

    Looking towards rolling out the pilot.

  32. Make an offer

    First pass at making a conditional or unconditional offer.

  33. Application states

    Create new states with filters.

  34. New panels and application tables

    Bring 2018 version inline with design system.

  35. Fewer statuses

    Trying a smaller set of statuses.

  36. First designs for a minimum viable service

    A minimum viable service that could allow the providers to access and manage their ITT applications.