So last week I’m with a client, discussing the finer points of navigating a new release of their flagship web application. We had come to easy consensus on virtually every aspect of the design save one, and the group around the table was pretty evenly divided on just how the function should be implemented on the page. Should it be a button or a hyperlink? Should it go here, or there?
Easy enough, I say. It’s a single element on the page — let’s just mock it up both ways, and see how it tests. [Silence] You know, the user testing sessions we’ve got scheduled after we render the pages to HTML? [chirp, chirp, chirp]
Okay, I say. Did you want to tell me something?
Well, says the project manager, the project’s budget has been cut. And its timeline. The only way to keep it under budget and on time was to take out bits here and there. And user testing–all user testing–was the first bit to go.
I could have given my stump speech on the importance of user testing — on how it saves money by eliminating rework down the road, how it can reduce customer call-center needs, and makes for a better customer experience overall by not making the user feel stupid. But I’d already converted this group. They knew, too, that cutting user testing from the project was foolish and shortsighted. But all of their projects’ budgets were being cut — all development was being scaled back to trim expenses. They are a publicly held company, after all. They have to meet analysts’ expectations for the quarter. If they miss their target by even a penny, their stock’s share price will slip. A lot, maybe.
So, to meet the expectations of some faceless Wall Street analyst — somebody who will never use this application, and probably doesn’t even use this company’s products’ — the folks who are customers and will use this application every day will probably suffer for it.
Am I the only one who finds this absurd?