What we learnt from prototyping

Hi, I’m David Swainston from the Business Solutions team and I wanted to give a following up on the work we did over the last month to create a prototype for a digital end to end service for Housing.

Here’s what we learnt over the 2 fortnightly ‘sprints’ in which we built Housing Helper – a chatbot for tenants and leaseholders.

  • Be guided by the needs of the end user first: as part of the Agile methodology, this was an opportunity to let our end user needs from the discovery phase inform the basis of our requirements. Traditionally, we would gather a whole raft of requirements from the service area to build a large product that isn’t necessarily tailored towards the needs of the user. It was really interesting to see the relative level of simplicity of end user requirements for a service (i.e. only what users really need), compared to the larger scope and scale of requirements we usually gather and work to. Obviously this can be dependent on the type of service/project being worked on – but we felt this is particularly relevant when it comes to designing public facing digital services
  • Look at existing products and services for design inspiration: as part of the design we looked at various existing consumer based digital services and products currently out there and widely used. These included Banking apps, Messenger interfaces, web chat interfaces and SMS to name a few. We considered the strengths of what these services offered in terms of functionality and user experience and fed this into the design of our prototype
  • Test with end users and let assumptions be challenged: ensure that the service you are prototyping is put in the hands of the users who will be using it. Get their perspective on things such as functionality, design, user experience and also additional user needs that may be identified and incorporated as requirements for future release sprints. Although our brief was to design a service for Housing, we learned from speaking to tenants that the service could be expanded to offer services across the organisation. We gained useful feedback on the certain design aspects, for example allowing spelling mistakes and slang to be recognised within the chatbot prototype and that the interface was easy to use
  • Having the right blend of technical expertise: this was really important when it came to us exploring different platforms that could support the development of the prototype. We benefited from having developers within our team who could identify and configure the cloud platform, the various API’s between different components and coding the chat bot framework. We also had a technical architect who brought the whole platform together and summarised this in a solution design canvas that enabled other members of the team and observers to understand the different components that supported the platform
  • Having a leader in the team/Scrum master: whilst Agile is a methodology to enable quick iteration and change, we soon found out that it is still very much a disciplined approach when it came to working through the design and release phase. It was useful to have a good leader to ensure that everybody within the team is aware of the role they have, and that release sprints are delivered in time to allow for the next iteration to begin. This is something that we can still tighten up on when applying Agile and its various forms for real projects, but as a first attempt away from the traditional Waterfall approach we didn’t do too badly!

Here’s a link to the Google Ventures channel on Youtube. We adopted the sprint methods described by GV in their videos, and the team found it really useful as a framework for our exercise to come up with the final prototype.

If there’s any questions you’d like to ask about the approach or the prototype itself, please drop me an email.