On my return journey, I was reflecting on everything I had learned at the conference, when I had an experience that reminded me how important it is for us as BAs to really understand our stakeholders and the goals that they are trying to achieve.
I arrived at Hollywood tri-rail station, and went to an automated machine to buy a ticket to Miami International Airport. As someone from outside the area, and from a different country, these machines were alien to me. Of course, I’ve used automated ticket machines before, but not these ones and although they were fairly intuitive it took me a few seconds to work out how to operate them and what ticket I needed. I figured out I needed a ‘two zone’ ticket, so I selected the relevant option and put in my payment card. This is when the ‘fun’ began…
The machine rejected the first card I tried to pay with, so I tried a different one which it duly accepted. The system then asked me to input my zip code before it could take payment, allowing only numbers to be input. As a customer, I felt that frustrating moment of confusion that we’ve all felt from time to time when our personal circumstances don’t fit the ‘standard process’. I don’t have a zip code because I don’t live in the USA – I do have a UK postal code but this is made up of numbers and letters. I quickly went through the options in my head:
- Fake zip code: The only zip code I have memorized is 90210, but I’m not sure anyone would believe I live in that area. I could try using this, but there’s always a risk the system might block my card if it actually tries to validate it. This would be an issue given I need to get to the airport.
- Hotel zip code: I could use the zip code of the hotel I’ve been staying at. But this would mean fumbling through e-mails and reservations to find it, and I’ve still no idea whether it would validate it.
- Numbers from my UK postcode: If it is trying to validate postal code, I could just enter the numbers from my UK postcode (ignoring the letters)
- Pay with cash: As a last resort, I could go ‘old-school’ and pay with that awkward, retro, paper ‘hand money’ that is still in circulation.
Crucially, there was no indication on why a zip code was being collected, which made it hard to know what to do. I decided to use the least-risky option and paid with cash. The machine then helpfully dispensed the change entirely in dollar coins. This surprised me again, as a foreigner I had no idea dollar coins even existed, but I now have a pocket full of them!
Better Stakeholder Understanding Brings Clarity
In this situation, whilst the ticket machine was easy to use, it appears an entire group of customers had been forgotten—international visitors. For a service that starts in a tourist hotspot and terminates at an international airport, this seems somewhat of an oversight, but it highlights a consideration that is relevant for all of us (irrespective of the industry we work in): The services we design are probably going to have to cater for more variety than we initially think. With this in mind, stakeholder analysis absolutely cannot be a check-box or a one-off activity—it’s crucial that we understand the types of direct and indirect ‘users’, ‘customers’ and ‘beneficiaries’ of the service, and get to know their needs, wants and constraints.
This will often involve ‘zooming out’ to understand the actual goals of the stakeholder. As a ‘passenger’ of the tri-rail it might be tempting to assume my goal was to ‘buy ticket’. Whilst that is true, the ticket was just a means to allow me to travel to the airport. That was a means of getting me back to London Heathrow. My overall goal was to ‘travel home’.
At first glance, this might seem unimportant. Why would the designers of a ticket machine care about stakeholder goals that are outside of their control? Surely they should focus just on effectively and efficiently selling tickets. Well, yes and no…. Of course, efficacy in dispensing tickets is important. Yet knowing the broader stakeholder goals might fundamentally change the way the machine’s interface is designed. Perhaps, if a ‘user’ selects the airport as their destination, it asks whether they’d like additional help (and if they accept this, the machine tells them the time of the next train and the platform it’ll leave from). It might also tell them the estimated time of arrival, and maybe it could even integrate with the departures board of the airport to show them any cancellations (after all, if the flight had been cancelled, maybe there’d be no need to travel at all). In any case, it ought to provide a way to input a non-US zip code.
Feedback and Adapt
Even with the best insight and research and the most robust stakeholder or persona analysis, there will quite likely be something that gets missed, or a need that changes over time. Even with piloting and prototyping, it’s not until we put a service ‘live’ that we’ll know how it really works. It’s therefore important to ensure that there are mechanisms to get feedback—ideally qualitative and quantitative—to see if things are working well. This isn’t primarily about measuring ‘performance’ in the traditional sense, it is more about measuring whether the stakeholders can get whatever they want to get done, done. For example, if we monitored the tri-rail ticket machine, we might find that a significant proportion of people ‘drop out’ at the zip code stage of the payment process. This might lead us to ask ‘why’, and look for ways of improving. It’s also important to get qualitative feedback from people actually using the service.
In summary, understanding stakeholders who are directly or indirectly involved or affected by a product or service that we are creating or changing is crucial. By ‘zooming out’ and understanding broader goals, we collaboratively specify and design services that will balance their needs and help them effectively and efficiently do what they need to do. This is an area where business analysis can contribute significant insight.