Human Centred Design
What is Human Centred Design?
Human Centred Design (HCD) is an approach to problem solving, which places an emphasis on the user. It stresses the importance of understating a problem from the perspective of the user and lays out a framework for making design decisions with this focus in mind.
The Rapid Prototyping Team follows an agile methodology. Typically, this means we produce a Minimal Viable Product (MVP) and then improve it by iterating on stakeholder feedback. Given that our turnaround times are quite short – usually between two and four weeks – it is important for us to focus development on the aspects of a project that provide the most benefit to our stakeholders.
HCD is a very useful framework for enabling this focus since it prioritises the human aspect. This makes it easier to identify preconceived notions about how a product should function and instead build features that help the end user.
IDEO is a design firm which specialises in HCD. They break their design process into the following stages:
- Rapid Prototyping
- User feedback
It is interesting to note that points three through six describe the normal process of iterative design, while points one and two are heavily dependent on HCD. However, principles from HCD can be applied to all sections in the process. For example, soliciting good feedback is an art in of itself and should revolve around the user.
Global Navigation Satellite System (GNSS) is a collection of satellites that allow you to determine where on the planet you are. The most well know system in this collection is GPS, but there are many other which are run by different organisations.
All these satellites work by using the same general principle. They emit radio waves which an observer can detect and use to determine their location. Ordnance Survey uses this technology when surveying the country. By the time GNSS signals reach Earth, they are incredibly weak. It is very easy to block the signal, which can lead to surveyors’ location drifting and in the worst case dropping out completely. Consequently, we were tasked with finding a way to detect when the signal dropped out.
This section gives a high-level overview of the project with key stages in each of the HCD phases.
At the very start of the sprint, our customer showed us their current process for identifying outages in the GNSS signal. We observed that the only way to find outages was to trawl through hundreds of folders, run a python script, and view each spectrogram one by one. Additionally, we noticed that the python scripts, which converted raw data into spectrograms, were very good at producing one-off spectrograms and allowing a good amount of customisation.
We also observed that the raw data was not one continuous signal, but rather split up into chunks of thousands of files which could vary in length from a few milliseconds to minutes. This made it very hard to monitor an outage that crossed over multiple files.
In the ideation stage we came up with a huge selection of ideas that might provide some value to our stakeholder. Ideas ranged from setting up a cloud process to analyse raw data, to making the spectrogram plots look more aesthetically pleasing. The point of this stage was to collate a list of everything that we could do. Then, we were able to start discussing ideas and distilling what aspects would help the most.
In this case, we had gone into the project with the notion that the end goal was to have an algorithm to detect GNSS outages. However, it became clear that the key limitations with the current process would not be solved by this algorithm. You would still need to manually run it on thousands of files, trawl through complicated folder structure every day, and you couldn’t link up events over multiple files.
Given these were the key problems faced by the users of GNSS data we decided to produce the following:
- A python module that automatically sanitised and merged multiple raw data files into a single spectrogram. This would enable GNSS operators to view raw data by specifying a time range, instead of manually searching for files with the correct timestamps.
- An algorithm to detect signal outages.
- A way to display all the outages in one place. This would completely remove the need for GNSS operators to manually look through files.
At this point we started developing the ideas created in the ideation phase.
By rapidly prototyping, we were able to get a working solution in front of GNSS operators which meant we could get precise feedback. In fact, we were able to hand over our code enabling us to observe how the customer used it. This allowed us to identify problems which we had not considered in the ideation phase.
For example, the raw data came in two different formats which our code handled separately. But we found that GNSS operators expected the code to be able to handle both in the same way, since they wanted the same output. This was an oversight which we made during development and would not have been caught if we had waited until we had a polished product to handover.
In this phase we addressed the feedback and improved our MVP by refining our algorithm and streamlining the python code.
This stage was not particularly relevant for this project. Normally it refers to productionisation or building a product by incorporating everything that was learnt in the previous stages.
The aim of Datahub Explorer is to lower the barriers of entry to using OS APIs, creating a better user experience for someone who is not familiar with OS data, to see what is on offer.
The Rapid Prototyping Team are constantly looking for opportunities to deliver value. For example, the idea for Datahub Explorer came after identifying that a lot of third-party APIs are difficult to use, so the team decided to implement a solution for the OS Data Hub.
They followed the same process as the GNSS project, which means there were a lot of similarity in the iteration and development of the product. Since the idea was conceived within the Rapid Prototyping Team, there was no customer to observe, but we had our own experience of signing up for APIs and could use that to guide our development.
To ensure ideas were distilled, a framework called the abstraction ladder guided the observation and ideation phases. An abstraction ladder works in three steps:
- Write down a problem, frustration, or something that could be improved.
- For each point repeatedly ask Why? Why?... Why? This process helps you isolate the root cause of a problem.
- Finally work down the other side of the ladder by asking: how do I fix these problems?
By producing an abstraction ladder like the one below, it’s clear that the key problem faced when investigating a new API for data access, is the perceived trade-off between set up and alternative options. If a user is unsure that an API will give them the data they need, or if set-up is too complicated, then they are likely to shop around for different options. So, the question becomes: what can we do in order mitigate these issues?
This process resulted in the DataHub Explorer and most of its key features. By focusing on the aspects of a problem that a user faces when looking for a data source and were able to deploy a “product” in less than 4 weeks!
The principles of Human Centred Design enable us to focus on the important aspects of a problem and develop products with useful features. We would encourage you to try some of the ideas here in your next project and see if it’s a good fit for your team.
If you have any questions, get in touch with the Rapid Prototyping Team.