This is an actual problem I'm being paid to solve:
Look: We're going to have to spend $100,000 on Web-based infrastructure over the next five years, most of which will be in the first one or two. How do we get that money to perform?
This eventuality came out of a client who has had some form of Web presence since the late 1990s. They had fallen into a pattern such that every few years, they would throw out their inadequate system on the speculation that a newer, more expensive one would address the shortcomings of its predecessor. Of course, they make this move only to find out not only does the new system not solve any significant proportion of the old problems, but introduces an entirely new strain of costs and headaches. Part of my job is to break this cycle.
Technology does one, and only one thing: it takes a process that already exists and makes it way, way more affordable. As the cost drops toward zero, aspirations spring up that could never have been imagined before. But at their root, they're always the same: happiness, freedom, wealth, power, fame, world peace, whatever. Human ambition is eternal, transcendent, mythological in origin. Technology just amounts to whatever method we're using at this very moment to achieve it.
In the immortal words of Alan Cooper: Business is information processing.
It's only an accident of economics that the current trend for handling said information processing is to use software running on computers, and only a different accident of economics that the most convenient vehicle to convey said software is the World-Wide Web.
Seriously. It's really, really, embarrassingly cheap to make and deploy a webpage, and by extension, a control surface for some essential piece of business information infrastructure. Especially when compared to what you had to do before to get a comparable outcome. What isn't cheap, however—irreducibly so—is figuring out what you want it to say.
I was hired initially to vet the fitness of some ERP/CRM-in-the-cloud-as-a-service vendors to replace another one of the same ilk, for which it wasn't working out
would be the euphemism of the century. They each had an impressive list of features, a service-level agreement, 24/7 tech support, the whole five nines. They also wanted colossal down payments and/or a five-year lock-in, with monthly per-seat billing that even my client's modest little office would run up to a cost on par with going out and writing the damn thing from scratch—even before tacking on the standard car-sized outlay for the actual website design, which wasn't part of the deal.
It was clear that going SaaS wasn't going to save my client any money, but what about their original concern? Forget the arguments about privacy, legal jurisdiction, dependency, outages, or any of the other myriad unresolved issues with infrastructure as a service: These deals represented an enormous sunk cost if it turned out that the product was unusable. And cloud-based or no, this ERP/CRM/CMS/LOL/WTF nonsense isn't worth a dime if nobody uses it. In fact, if your staff becomes the de facto user interface to one of these monstrosities because your customers turn their noses up at it, I'm pretty confident its value is negative.
Of course, the only real way to tell if a software product is usable is to use it—for a considerable period—and you won't find a single vendor that doesn't make you at least promise to shell out big bucks for that opportunity, especially if they eat any part of the cost of migrating your data. The next best thing would be if you knew your users well enough that you could exhaustively prove the fitness of whatever the vendor is selling. Better yet: hand the sales rep a dossier and have him do it.
The only way we could begin to intelligently evaluate these offerings up front was if we had a well-researched scenario—or preferably a storyboard—that we could hold up against each feature, squint at it, and see if any alarm bells went off—or, again, have the vendor prove to us that no alarm bells went off. Of course, if we had those assets, we'd be well over half-way to a custom solution.
I pick on The Cloud™ a lot, mainly because what I see most in that space are charlatans baffling their prey into draconian contracts with feature lists and techno-financial babble. Though after speaking with enough vendors, it isn't clear if they're genuinely evil, or just incompetent themselves. As it stands, their livelihood depends on you not understanding what you're getting into, and making it just that little bit too difficult to get out.
But that doesn't mean things won't change, potentially in the very near future. If somebody can really, truly, annihilate a business problem, and do it better and cheaper than you can, why not pay them on an ongoing basis, especially if it means they'll just keep finding ways to serve you better? It just doesn't seem to work when you bundle a bunch of putative solutions to random business problems together and slap a monopoly on top of it, especially one who already has your money.
And now to singe the UX community a little bit, or at least a subset thereof: Too often I see artifacts like personas and scenarios—but certainly not only those—treated as perfunctory stepping stones toward a software implementation, as if code was the only thing that mattered. What I don't see a lot of—though maybe I'm not looking in the right places—is the marketing of user experience design work for other applications: like just having it around as a stand-alone asset so you can do things like vet third-party enterprise software.
If you're careful about how you partition it, there's no reason why a solid kernel of an organization's UX corpus couldn't stay relevant for decades, because at the end of the day, it's indistinguishable from bona fide management strategy. Or at least it should be.
There was one place the SaaS vendors could deliver: time to deployment. If you're a middle manager whose only skin in the game is the need to declare a particular problem solved
to your superiors as soon as humanly possible, then The Cloud™ is the perfect solution. If you actually cared about the outcome—like if you had to use it yourself every day—it isn't clear how you could evaluate the offering with confidence, before committing to it, without at least a few months of design research and synthesis in the can. And if you're going to pay for that, you might as well pay to finish the job. Provided, of course, you don't have to wait until the whole damn thing rolls out at the end in one lump.
In that case, they got the right guy, because that's more or less what I've been developing over the last five years. And just like that, I had a new mandate:
I know infrastructure software, and I know the Web. I have half a lifetime of experience down in the plumbing of organizations large and small. That said, I am increasingly apprehensive about billing myself as having anything directly to do with tech.
The cause of my apprehension is twofold. First, because, as I mentioned, the tech part of business information infrastructure tends to be embarrassingly trivial. The real skill lies in smoking out the local adaptations to the innumerable vagaries of that particular organization, which, incidentally, would be roughly the same no matter what technology they were being applied to. In other words, nothing you can reliably buy off a shelf. Second, and arguably more pernicious, if you enter an agreement under the auspices of tech, it will be an uphill battle to even start that conversation. Why?
Because Business Guys™ only care that things work. They couldn't give a damn about how. They want a solution, they want to know how much and how long, and they're going to drill your ass until they get what they want. And, as a bonus, they're going to try to shift all the risk onto you. They don't understand the obstacles you face, so they have zero empathy. You are going to use your tech geek powers to magic their problem away, or it's your derrière. And, should you succeed, have fun getting them to pay the bill. Frog and scorpion, hombre, it's just in their nature. No disrespect. By the way, my email's been acting up. Can you take a look at it?
I still make extensive use of my technical skills. In fact, I still write a ton of code, albeit for the purpose of instrumenting the process I'm designing, which is ultimately one of finance, risk, and organizational structure. It's an essential part of my job, it just isn't why they hired me.
Acquiescing to the tech epithet invites the suits to dictate to me how I'm supposed to solve their problems, in the fact that they don't pick up the phone until they've decided that they need a website, or an app, or whatever: acceptance criteria which, for the results that I create, tend to be far too narrow. Instead, it seems I should plant a foot firmly into their territory. Perhaps it's time to invest in some suits of my own.