Posts

  1. Number of projects

    We want new users to quickly know how many conversions projects there are.

  2. Filtering projects

    We created a feature that allows users to filter conversions projects.

  3. Assigning a project

    We created a feature that allows team leads to assign conversions projects to delivery officers.

  4. Legal requirements

    Certain requirements need to be met for academy conversions.

  5. Record a decision

    A delivery officer (DO) presents a proposed conversion at advisory board. The Regional Director makes a decision and the DO records the decision.

  6. Improving the project template 2

    Once we knew the new template was technically possible to produce, our content designer showed it to the policy team to make sure it was ok. They were happy with the layout and also gave us some insight into some of the information in the template.

  7. Improving the project template 1

    Delivery officers use a Word document called a project template to bring together lots of information about a school and a trust. They then present this template at an Advisory Board meeting.

  8. MVP refinement

    We’ve reached a decision as a team to focus our efforts on getting the pre-HTB part of our product intoprivate beta. To do this, we wished to have a clear understanding of what features we deemed to be MVP and which we felt were MVP +1

  9. Finalising pre-HTB designs

    Our prototype after rounds 2, 3 and 4 of research

  10. Pre-HTB Setting a status version 1

    We developed Version 1 of setting a project status from information we got from our subject matter experts.

  11. Pre-HTB designs - user research (Round 4)

    Findings from task-based testing on the HTML prototype

  12. Pre-HTB designs - user research (Round 3)

    Findings from task-based testing on the HTML prorotype

  13. Post-HTB prototype - User research (Round 1)

    Research from existing trackers delivery officers use and input from our subject matter experts.

  14. Post-HTB prototype version 1

    Our first static designs for post-HTB based on research from existing trackers delivery officers use and input from our subject matter experts.

  15. Pre-HTB - Automated accessibility testing (Round 1)

    To ensure we deliver the most accessible service we we plan to test early and often using a range of methods. This first round of testing is to get a feel of how accessible our prototype is and to identify any major issues.

  16. Pre-HTB designs - user research (Round 2)

    Findings from concept testing on the HTML prorotype

  17. Pre-HTB prototype version 2

    Our prorotype has changed significantly due to peer reviews, user testing, increased knowledge and a move to a more focused MVP.

  18. Pre-HTB prototype - user research (Round 1)

    Concept testing our first static prorotype files.

  19. Pre-HTB prototype version 1

    Our first design based on user needs, our findings from private beta and implementation of GDS patterns.

  20. Understanding, exploration and experimenting – how the design got started

    Before this design phase started the service was in private beta with an Apply to Become (A2B) system in TRAMS created using Microsoft Dynamics.