Beta – Sprint 4 Show and Share

Posted byfrasertrickPosted inBeta, Week notes

We have had another great couple of weeks of progress, bringing us ever closer to a working product designed around our customers needs.

During this sprint we have been able to setup some of the foundations of the technical setup that will help to make our product as reusable as possible. Some of our key achievements this sprint have been

  • Captured key findings from 1st round user research

We have also managed to do the seemingly impossible and meet up, not virtually but actual person! It was great to meet the team and talk through the direction of the project face-to-face as well as building upon our great working relationships.

It really is great to get together – nothing quite beats being together for sharing ideas.

Lastly I’d just like to thank DLUCH for sharing our story on their blog, if you haven’t had chance please check this out too.

Iterated beta

Based on the user research that was completed in sprint 3, we have iterated the prototype design to make the process as easy as possible for the customer. Some of the key updates were:

  • We updated the copy on the emergency page to make it clearer what we define as an emergency
  • Changed the continue buttons to show what the next stage is
  • On the problem identification page we expanded the description to help customers identify their issue
  • The photo upload guidance was removed as users found this confusing
  • We shorted the overall journey by condensing contact detail and access requirement questions
  • The ability to request more dates for appointments were added

I’d recommend reading our sprint 3 update to see how the research influenced these changes.

SoR Engine

To ensure our product can be used by different authorities; we have built in the capability to upload schedule of rate codes for each repair classification. With over 2000 codes available, in addition to local customisation, it was essential this functionality we available.

Infrastructure as code

Defining our infrastructure as code allows us to easily manage our cloud resources and replicate the production environment quickly in any other azure environment. Taking this approach will also allow easier conversion to other cloud providers. A further benefit of having infrastructure as code is that this prevents having unnecessary dangling resources, so that we provision only the resources we will use, which in turn will ensure we are only paying for resources we need.

The show and share session

Why not take a look at our latest Show and Share, so you can see and listen to the progress made in more detail: