I am lying under my 30-year-old Volvo 240 studying the drive shaft and thinking about designing UX for enterprise software. This car began as a $500 solution for a second car 一 something for around town, running errands, going to the grocery store. What could be better than a classic Volvo brick?
There’s a cardinal rule about restoring old cars. Take your best estimate and whatever amount you intend to reasonably spend… and then double it. Give-or-take a few thousand bucks, this new number will be the real number. And unless it is a very rare and special car, it will be completely disproportionate to the actual book value of the car… which for a 30-year-old Volvo sedan isn’t much.
And unless you have an iron discipline with spreadsheets, you won’t notice the cost of restoration is exceeding the value of the car until you’re well past the point of return.
And now you own a car that can’t be driven because it’s in pieces in your garage.
And it can’t be sold with any hope of return on investment.
It’s at this point that a project like this becomes what we call a “labor of love.”
Proactive, reactive, repeat
This is why I am lying under my 30-year-old Volvo 240 studying the drive shaft and thinking about designing UX for enterprise software — because designing UX for enterprise software is a lot like working on a 30-year-old Volvo.
I think one of the reasons why being proactive about UX for legacy products continues to be such a challenge is because, like restoring old cars, UX for enterprise software is inherently reactive by its very nature. Maybe one of the many ways in which one can be proactive about UX with legacy enterprise products is to encourage the ability to imagine what our products can and should be despite the rust; to be able to see the shiny new Volvo underneath.
Imagine what our products can and should be despite the rust
Last weekend, I went through the differential which was seeping oil around its ancient gasket, at which point I noticed the sagging drive shaft, which I’m equally certain hasn’t been serviced since new. I doubt I would have discovered the problems with the drive shaft without working through the differential first and the dependencies between the two becoming clear.
QA uncovers concerns
These dependencies remind me of a situation I encountered when I was a UX designer for Salesforce Marketing Cloud (SFMC). We had a ticket in our sprint that added the ability to create a test audience. This test audience could be consumed by a number of different apps in the SFMC. During QA testing however, it was discovered that these test audiences were displaying inconsistently even though all of the apps in the suite shared the same API/Routes. When the dependency was discovered, I asked one of our devs if we could have possibly been able to foresee this.
“I don’t know how you could.” He shook his head. “When we all use the same routes.”
If our QA hadn’t discovered the inconsistencies with our test audiences and we hadn’t fixed it, the impact would have mostly gone unnoticed. At first anyway… Much like my old Volvo, it wouldn’t be right but it’d still get me down the road.
It’s not uncommon to encounter this “we’ll fix it later” mentality with large, legacy enterprises because “fixing it” will always mean more money and more time. This reluctance is understandable but short-sighted. If we don’t fix it and it blows up on us, the breach of trust it will cause our customers may well be irreparable. This is called a “company-ending event.” I’m thinking of the security breach a few years back at Target Corp. that almost took them down. As a Silverline Consultant and UX Designer, advocating a good user experience for our Salesforce customers means making sure they can trust us to design and build Salesforce solutions that get them where they want to go regardless of the mileage on their Org.
Ready to improve your Org’s user experience? Contact us.
