What is the problem you/ (we) are trying to solve perfectly describes much of my work over the last decade or two.
An example from the real world struck me last time I went to get a WOF for my car. The testing people said that the headlights were murky / foggy and needed an extra clean. This is not a problem I’ve ever heard of before so I wondered how to fix that. It turns out there is literally a product at the “stuff for cars” (not the actual name of the business) called ‘headlight cleaner.’
It is probably the same as other car cleaners but the business has helpfully given it a name to make it easy for car owners to identify and to buy.
If only problems with websites and software systems was so simple. With software platforms and connected networks that are largely out of the control of individual users it is very often difficult to isolate a problem and find a pre-made magic bullet. But if we know what results the business is looking for we can often work backwards and examine the equivalent of plumbing diagrams to see how the business logic works in whatever environment we are working within.
When it comes to websites and technology generally there is often a big gap between the reality of online tools and systems and the way they actually work in practise. I’ve pretty much given up on Google and many of the big vendors / system providers as despite decades of experience they still don’t seem to emply anyone who can write in plain English about how systems work.
The other thing is the problem that is reported by the business owner might not be the actual problem it might be a side effect or collateral damage situation and so diagnosing the problem is not as simple as it should be. Defining the real underlying problem might not be easy but that is what we need to do.
However repeatedly asking the question what is the problem we are trying to solve as various issues are reduced, eliminated, or managed is still one of the best questions to ask.
From there we can identify impacts and issues and what the business owner wants to get out of it. We can then identify options to potential scenarios that might work. As before what appears to be a problem might not be the real cause of the situation but understanding how all of those issues interact and impact the business will help everyone. It goes without saying that solving some problems might also create others downstream and so any planning and project management needs to work out what can be measured and monitored in order to move towards the result the business owner wants.
A very much related issue is that what we think people like about our systems and online services etc. might not be the actual thing they want. I came across this very interesting post on user feedback by Jim Nielsen who is describes himself as Generalist / Designer, Front-end Engineer, Writer. I suspect this is because many of the systems we use online have poor usability design and are clunky and hard to use but it might still be the quickest way for an end user to meet a need. So whatever else we do we need to understand how the business owners customers use their systems too. Seems obvious but it is not.
All they ever wanted was to get a job done, and our interface was nothing more than a delivery mechanism for the thing they actually wanted.
In fact, customers would often specifically mention how little they cared for the “usability” of our software. They vowed they’d go through the most tedious workflows imaginable if they could ultimately get the primary thing they wanted from us, which was not software.
What did they want from us? Access to insurance in high-risk markets where it was scarce.
It made me think of the different kinds of software I use and how I am willing to deal with difficult, obtuse software if it means I can get the thing I ultimately want which is often beyond the software itself. The software is often merely a means to an end.”
And that punchline “The software is often merely a means to an end.”
Image by Mohamed Hassan from Pixabay
