After many attempts at trying to solve this problem, they decided to look outside the organisation for a solution. We chose to take this problem on with a service design approach. By looking inside the organisation, we identified that there needed to be agreement from all stakeholders. So we organised a 2 day workshop in Sydney which all 16 stakeholders from around Australia needed to commit to.
A shared understanding
One of the more serious aspects of this problem was that because the solution had been attempted by many stakeholders, each had their own understanding of what the right solution should be. Hence, one of the intents of the workshop was to get a shared understanding of what the problem was between all stakeholders.
In these workshops, we use play and collaboration activities to identify and share various definitions of success. This enabled individual expression in a safe environment without frictions. At the end of day 1, the primary goal was to have a shared understanding and agree on a single Problem Statement.
Defining the problem
To start with, we focussed on understanding the problem in one “How Might We…” statement.
|How might we: _ _ _ _ _ _ _||What the problem is|
|For: _ _ _ _ _ _ _||Who the problem affects|
|So that: _ _ _ _ _ _ _||Why the solution is important|
Sometimes a variety of problem statements arise through this exercise. For example:
How might we collect data for our team so that we can share it quickly and easily?
How might we share data for our sales team so that they can share it with our clients quickly and in an engaging way?
How might we make our presentations engaging for our audience so that our data is meaningful and valuable?
Once we define the primary problem, we then understand more about the people who benefit from the solution. Often, the problem statements may need some re-focussing afterwards.
The problem statement now reads:
“How might we unlock access to our data for our team so that they are able to access information for bids and tenders quickly and easily. By reducing the unbillable time spent on these activities, this creates a compelling pitch that delivers competitive advantage”
On day 2 of the workshop, once the problem statement was agreed upon, and the primary users were identified (clients and staff). It was time to come up with a statement that aimed to solve the problem for those people.
We used a tool developed by Roman Pichler called the Product Vision Board. The Product Vision Board helps you describe, visualise, and validate your product vision and your product strategy.
“Our vision is to enable our clients’ ambitions by bringing data to life.
We will empower our people to engage with clients and each other in new ways, unlocking the full potential of data to drive smarter decisions, faster.”
Product in a Box
The real fun was to try to envisage some of these solutions in group exercises. The “Design-the-Box” activity is a good activity to focus on these outcomes. This creative activity allows people to give the solution or product a name, a description of how it might solve the problem and features of how it works.
By imagining the package for their idea, the teams make decisions about the name, features and who the solution is for. This makes the Product Vision exercise easier to articulate.
At the end of the exercise, the teams will present their box to the other teams in a playful conclusion. It’s not only fun for participants but the results of the exercise may live on well after as a friendly reminder of the big picture.
Building the agile team
We formed a multi-disciplinary team including client managers, geotechnical engineers, flying their 2 developers from the UK and a couple of visual designers. We all worked from a dedicated space to enhance communication and focus attention to working on the same project with minimal interruptions.
Grouping user types into Customer Personas
In order to better understand the customers, and also to keep the team focused on their needs and contexts, it is useful to group them by categories which will make them easier to remember. In this project, the grouping was done by profession, needs and behaviours. With the help of the team, we used their stories to illustrate each of the persona narratives to bring them to life. It was sketched together at first, and over time, they evolved to become fictional archetypes whose behaviours and needs were validated through qualitative interviews and usability testing.
Mapping the customer journeys with task models
Once we had a handful of personas, it was time to start understanding their needs from beginning to end when it came to dealing with what the company was offering them. This is where we use customer journey maps and task models to great effect.
We use sticky notes to list each need from the left to right so that we can see where each of their needs tend to occur along the journey. Of course, each need might consist of a number of tasks. These tasks are also added to each need building up so that the journey map starts to resemble a group of towers.
We then mirror each of these tasks underneath with existing services, procedures and systems highlighting any that were missing to match their customer needs. This was particularly important when prioritising the features of the prototype and where they needed to be present to the customers and the staff servicing them.
In effect, this was a guerilla-style service blueprint which mapped both current state and future states of what the solution needed to provide in order to achieve successful outcomes.
The team co-designed sketches (low-fidelity prototypes) individually to visualise the kind of solution that matched the majority of these client (as well as staff) needs.
Some people found these initial concept sketches very difficult to understand. This is where we needed to scan them into an interactive prototype so that they were able to show how useful they could be.
In each sprint, the prototype would develop in fidelity from sketches to designs and eventually HTML code. The more we showed our progress and talked with client managers, the more they were able to understand and contribute to the desired solution as a collaborative process.
One of our early discoveries is that Geotechnical Engineers can tend to exhibit risk aversion as a professional trait. This is because they are trained to reduce risk as much as possible in their industry. The results can be disastrous when considering impacts in construction and building developments.
This risk aversion can be challenging when trying to experiment with new solutions when trying to solve a problem. To overcome this aversion, the prototype/testing method presents as “experiments/learning” emphasis. The benefit of this is that the risk is mitigated and reduced when building a scalable solution.
As the prototype developed from interactive sketches to designs with higher fidelity, we observed another challenge. The more that the designs resembled a real system, the more people forgot that it was actually a prototype. This meant that the expectations they had in the prototype’s functionality were increasing. At that point, it was necessary to start building in functionality with front-end development.
Eventually, the client managers and geotechnical experts grew more comfortable as the prototype started taking on a life of its own. It was now ready to be usability tested on their customers.
The results were excellent. The client managers became emboldened that they could now start new relationships meeting the needs of their clients. The clients, upon usability-testing the prototype began to see the usefulness of the tool and suggesting enhancements and more features which was valuable feedback for everyone.
“I can see this being part of BAU (Business As Usual) for us”
“I’d make this mandatory on all our projects”
“This is gold!”
The final sprint resulted in a prototype which served all of their clients’ primary needs as well as allowed the client engagement staff to deliver data of geographical locations in an instant. Indeed, one of their largest clients had expressed such interest that the project needed to pivot.
This pivot involved a partnership with the firms in which the product would become a white-label product to use for all their clients.