With a myriad of sexy consumer-facing UX case studies being showcased on Medium, I thought I’d be a little unconventional and show you a real design problem from a different perspective, following the principles of design thinking.
I’ve omitted or obfuscated confidential information in this case study, most notably the company name — whom I’ll refer to as “CompanyX” for the rest of this post.
For CompanyX, finding and reporting on energy metering assets in the field was an arduous manual process full of human error and recurring problems. External field operatives (field-ops) responsible for handling these metering assets, faced unsolicited contact and penalties when things went mysteriously missing from their inventory.
I was part of a project engaged to design and build a new asset management experience that dovetails the needs of a scaling business with the needs of external field-ops people undertaking the work.
Reform was well overdue.
Since 2010, CompanyX has rapidly grown from servicing commercial and industrial sectors to now servicing residential, small business consumers, embedded electricity networks and water metering across Australia. New government-led changes had surfaced in 2017, calling for the introduction of smart meters to the mass consumer market. For CompanyX, this meant one million of them by 2021.
Current infrastructure struggled to scale alongside the growth of the company. Data integrity was challenged. Visibility of assets fragmented. Deliveries partial, incorrect or late and compliance was around the corner.
Right asset, right place, right time.
Our goal was to improve the working lives of field-ops and asset managers through ensuring the right assets, are in the right place, at the right time, with visibility. We believed this would start to resolve the abundance of issues they experience, whilst also helping overcome the business challenge of scaling and compliance.
- Providing everyone with a single shared view of true data.
- Making inventory management more efficient and informed.
- Providing visibility at all times.
I led the analysis and design of the asset management experience between February 2017 to August 2017 through discovery, inception and delivery. Collaborating with an Agile cross-functional team of developers, a project manager, a product owner and a number of executive stakeholders.
I stopped working on the project after a series of initial releases, and handed over to another team. The application launched in Australia in August 2017.
Understanding the problem space
From the onset, we didn’t have an understanding of the current asset management experience and state of affairs. I partnered with fellow colleagues to undertake user research and see what we could discover.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions” — Albert Einstein
Insights from the field.
Over a week, we interviewed key people affected by the existing experience to understand their pain points. The goal was to understand what worked, what didn’t, and various workarounds that could become future opportunities.
We also went to genba 現場 (Lean Japanese term for “real place”) to see the work done by field-ops by observing them at work in the warehouses.
- Troublesome deliveries. Partial, late or incorrect deliveries arrived in warehouses, which confused field operations staff, costing them time and money to ship back assets or work out a re-allocation plan.
- Frustrated people. Inventory managers couldn’t track the location of assets to ensure inventory levels are correct. Frequently, this led to a mystery search which was wasteful and frustrating for field ops who would be pulled into an investigation.
- Excess motion. A significant portion of the inventory managers’ time was spent copying across data from one system into another to communicate with industry systems for compliance.
- Workarounds. A significant portion of warehouse managers’ time was spent tracking inbound and outbound assets into a manual single-source spreadsheet (or on paper). This was a symptom of the frequent investigations and fuelled a sense of safety.
- Equivalent tooling. It was discovered other suppliers who worked with field-ops had provided mobile/iPad applications to help them with capturing inbound and outbound assets. Field-ops felt excited at the prospect of something similar for CompanyX.
- Suboptimal processes. The returns experience was broken, often leading to confusion and lack of accountability for recirculating the meters into a refurbishment process.
(Key learning) There was genuine hunger for a tool to keep track of inventory across warehouses.
Going into the field, we expected a lot of resistance to change from field-ops given their workload and external interests.
Turned out, it was a base expectation that they be provided with sufficient tooling — especially having been gifted with similar tools that meet their basic needs from other vendors which solve familiar problems.
Excited to hear we were working on their troubles, they were delighted by the idea of being able to spend time doing more valuable activities, and very open to discussing issues and opinions on how things can change for the better. We were on the right track.
(Key learning) There was a communications disconnect between field-ops and the inventory controller.
Inventory management and field-ops were frighteningly divided by communication barriers. Talking to each at different times revealed a gap in empathy for each other, their respective problems and views on responsibilities and accountability.
Part of the challenge was bringing these two halves together, almost in an act of couples counselling. After-all, they needed to work in unison for this to work. The hope was that it would build a space for continuous improvement in the future.
(Key learning) Manual processing and human errors, everywhere.
Field operations teams would receive deliveries of meters by the hundreds (sometimes thousands) at once. Each serial number would have to be marked and recorded, sometimes on spreadsheets, other times on old fashioned pen and paper.
Capturing these was hard. Deliveries of assets were often unpackaged from pallets and stacked, which required flexible manoeuvrability to get visibility
into serial numbers. What’s more, lighting conditions varied depending on the time of day, location and configuration of the assets.
What became a moment of relief for the team was suppliers, who had printed barcodes and serial number ranges on most of the pallets inbound.
Reframing the problem
As a team, we agreed based on research that:
- No visibility into the asset lifecycle caused downstream logistical problems.
- No consistent mechanism to reliably manage assets caused diffusion of responsibility, discord, incoordination and inefficiencies.
Our renewed challenges:
- How might we provide visibility into the asset lifecycle?
- How might we provide a reliable mechanism to manage assets?
Our proposal was StockR. A web and iPad application created for inventory managers and field-ops to provide visibility into assets and manage them throughout their lifecycle.
Capture and manage inbound assets quicker and more reliably.
StockR replaces the need for spreadsheets and paper- work by providing you a performant in-built scanner. From there, inventory can be visualised and managed in real time.
Allocate and track outbound assets, for the first time.
StockR allows you to allocate assets to registered field technicians for installation. The information is fed directly to inventory managers, resolving the need for wasteful communication.
Monitor and optimise supply chain. Report on it.
StockR provides you a snapshot of the overall lifecycle of assets and current allocations. Stock ordering and delivery no longer need be highly wasteful.
How we got to the solution
Right asset, right place, right time, with visibility.
A set of key questions hinged the design approach.
- What does it mean to have the right asset in the right place at the right time?
- What visibility is needed to make informed decisions on the asset lifecycle?
- What mechanism(s) exist which can feasibility support the inventory management experience whilst simple and efficient in the context of use?
The law of supply and demand.
In the pursuit to understanding why the wrong assets were in the wrong place at the wrong time, research revealed that demand wasn’t driven by consumer needs, but rather driven by an internal planning team who allocated install jobs directly to field-ops. They would then carry out the installation on the property.
Since these jobs were incepted around 2 weeks before the installation date, it conflicted with the 4–8 weeks lead time manufacturers needed to build and ship the assets to the warehouses. In short, supply was coming before demand.
In essence, this meant supply had to predict demand to try and reduce waste.
Such predictions were already being made through an existing forecasting process, created in response to the circumstances. Digging deeper, the process suffered from a lack of quality inputs revolving around the asset lifecycle, such that when install jobs came from the planning team, the wrong inventory was in the wrong place at the wrong time.
It struck me as rather odd, as in theory, a more rigorous planning process with the right time frame could remove a lot of the issues we were seeing downstream with supply. Nonetheless, it became clear at this point that the planning process would become a boundary constraint on the experience we needed to improve. Especially since there was limited time, resources and influence to change things at hand.
Good data aids good decisions.
Whilst we didn’t have scope to optimise the end to end process, we could make incremental improvements to supply forecasting to reduce the amount of non-value added waste downstream. Its biggest enemy - inaccurate and insufficient inputs.
To understand what data is needed to make an informed decision on inventory management, I led a card sorting exercise with the help from fellow colleagues.
On each card, I listed data points mentioned in the inventory management journey. Using an invented format to capture the 5 W’s, I had customers of the process rank and combine data points in terms of what would provide usable information to better manage inventory.
After synthesis, I discovered that the most important data was the assets out on vehicles with field technicians. It took me by surprise initially, as I assumed inventory in the warehouse would be the most important. Turns out, there’s no way for anyone to track or contact these technicians who carried hundreds of assets at one time for transport efficiency. Everything else had a possible, albeit painful, workaround.
Thinking outside the box.
As a designer, it’s very easy to be constrained by the comfortable world of desktops, devices and applications. It was important for us as a group to acknowledge that there might be other mechanisms that can solve our problems more elegantly.
In pursuit of such possibility, we came across iBeacons, NFC chips and QR code technologies. What became blatantly obvious is that none of these were the right tool for the job. In fact, most of these were better suited for advertising or supplementing a buying experience.
At the time of research, iBeacons worked up to a 30m range (NFC 1–4cm), have an energy source needing biennial replacement (NFC has none) and costs well over US10 per unit at bulk (NFC mere cents). QR codes? No point when the supplier prints barcodes. Too expensive, too unreliable, too much effort for all parties.
What about licensing a customised off-the-shelf tool (COTS)? It was a consideration, but even then there are expensive ongoing licensing costs, limitations on tooling and tailoring, and once you buy, you’re locked in to their infrastructure.
Retreating to convention.
Whilst we revelled at the idea of utilising the best hardware on offer, there was no denying that a mobile and desktop application was a more practical approach. Field-ops and inventory managers were well versed in using Android, iOS and desktop, had used similar platforms from other suppliers and we could start adding value pretty quickly.
In the days and weeks that followed between research activities, I built rapid prototypes to experiment with ideas and validate critical assumptions. An example of a 10-minute rapid prototype used can be seen on Marvelapp: https://marvelapp.com/54hghhh
As the product emerged, I performed regular usability testing to work out the kinks and regularly obtain feedback to improve the product. The latest
outputs can be seen depicted in the UserFlow, which represents our MVP.
In the months after my involvement on the project, the team continued to build out the roadmap alongside parallel products to offer more support. The new team evolved the design language and took a lot of the learnings we had made into other products.
Although I was no longer part of this process, I was proud to see most of my work brought to life from scratch and positively affecting the working lives of others.
- Large increase in visibility of metering assets*
- Large decrease in capture and allocation error rate*
- Minor reduction in asset rental costs*
Whilst visibility had a huge improvement, there were still discrepancies affecting accuracy of supply. Partly this was due to the limited geographical rollout, but also due to high reliability in on-boarding and uptake which took longer than estimated.
*Note: We neglected to define clear quantitative measures of success. If I was to do this project again, I would have defined them upfront, earlier. Regardless, success was measured and evidenced through qualitative feedback:
“We beta tested the app out in the field with one of our technicians and then took it away to incorporate the feedback we had collected. The person immediately wanted it back, telling us it allowed the work to be done in one-third of the usual time!”
“Our growing business means that large levels of stock will be out in the field at any point in time. The capability to keep track of this is a huge leap forward from the previous situation.”