Online Booking 1 — In the beginning
It’s Chriiiiiissstmasssss!!
It’s Tuesday 24th December. The Christmas night out is long past, and the team exchanged Secret Santa gifts last Friday¹. The working year is over.
This is probably a time to reflect, but my only reflection is — how did another year that’s supposed to last 365 whole days fly by in five minutes? So, instead of reflecting, I want to look forward to the next five minutes.
My early new year resolution is to write once a month about the progress of our next big project, the replacement of our online booking portal for service and MOT. Roll on 2020…
The festive lull offers a software delivery team the opportunity to do two things, take stock and plan for the future. Replacing the companies existing online booking portal is no small task, so it felt like it would be a mistake to not use the slack time available to do some planning.
Rather than go in to detail about everything we’ve done on this front, which would get boring pretty quickly, I’d like to concentrate on one thing that we found particularly useful, The Grid.
So, what is the Grid?
Simply put, it’s a tool that allows us to translate user stories and design work into technical requirements.
How does this work?
Along the top we have the provisional designs for our new booking portal, down the side we have a variety of potential use cases². This give us a framework for discussing the functionality we expect the system to have, and how different types of customer are expected to interact with that functionality.
Having this discussion allows to identify the supporting services required to make the various combinations of design and use case into real features for our customers.
That sounds very impressive in a generic agile business speak sort of way, but can you give me a specific example?
I certainly can.
Customers need to give us the registration and mileage of their car when they make a booking, so we can identify their car offer them the correct products. In the current design we capture this information in steps one and two.
We need this information for every single customer, but who they are, and how they arrived at the booking portal determines how much we already know about them. This is where the use cases come in.
The top three use cases on this grid are:
- Mr Vanilla
- Mr Pre-Booking
- Ms App
If we look at the difference between Mr Vanilla and Ms App for these first two steps of the process, it should demonstrate the value of the grid.
Use Case 1 — Mr Vanilla:
Like his name suggests, Mr Vanilla is plain, we have no information about him. He will need to provide us with the registration of his car, and the number of miles it has covered.
However, we still need a supporting service for step one that can look up the make and model of his car based on the registration. Luckily this already exists, it’s called HPI, hence the green tick:
Use Case 3 — Ms App
Ms App has downloaded the Arnold Clark App, hence her very imaginative name. She is quite different to Mr Vanilla.
If someone is booking a service through the app then we already know what car they have, and how many miles it has done since its last service. We still need this information to make a booking, but in the circumstances its unnecessary (and a bit off putting) to ask the customer to provide information they know we already have.
Given this, the use case for an App user is quite different. We want to pre-populate the details of their car and mileage, so we need something that pulls this information from the App. It also means that we don’t have to use the registration look up tool for App users, as we already know what type of car they have.
This might seem obvious, and not very hard to do, but it’s functionality that doesn’t exist that will be needed to provide this user with the experience we want. Using the grid has helped us identify this.
Isn’t this all a bit obvious?
Possibly, but this isn’t about reinventing the wheel, or making big leaps forward. It’s about getting everyone on the same page before we embark on a major bit of work. Everyone involved in the project now knows that:
- For unidentified customers we need a registration look up service, so we can identify the make and model of their car. They also know that this service already exists.
- For customers coming from the AC app, we don’t want them to have to enter this information manually, so it needs to be pulled down from the App. They now know that this will have to be built.
And that’s only one small, relatively simple, part of the system.
Hopefully that makes sense to anyone who reads it, if not feel free to get in touch
Thanks and Merry Xmas
¹ I got a rather fetching Pac Man Ghost lamp
² The designs and use cases are based on equally provisional user stories, and produced in collaboration with our designer and marketing team. You could use user stories instead of designs at this point, but a picture really does paint a thousand words in this context
