Whitespace killed an enterprise app

This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.

They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...

In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.

We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.

I wound up spending 6 weeks before even proposing anything that had to do with technology.

My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.

From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.

As a domain expert, I was for a sparse UX that emphasized the awesome just-works power of the product. I'll never forget how one bank IT director customer said, "I just can't pay for something with this little on the screen. Can you add more stuff?"

I think the key PM-fail on my part was privately scoffing to the architects afterwards that while we reduced the whites pace, we should also implement the ruby acts_as_enterprisey module to make the product seem crappier. This lack of people insight (and downside of visionary personality type attitude) pretty much summarized my limits as a PM.

Real lesson for us was: enterprise users trade on demonstrating their value by performing complex work. It's job security. The stakeholders you need to close an enterprise sale include those users. If your product or UX trivializes someone's job, they are going to fight you.

When they say they don't want your UX but they want your data, what they are really saying is, they don't need the problem you think you are solving solved, they are indexed on finding a way to demonstrate their value.

I"m learning this the hard way now with a product that doesn't quite close the knowledge gap for non-experts, but am finding it's simplicity is undermining to the authority of experts. Solving problems and demonstrating value are very different things. It's like building a tools vs. building instruments.

The UX question I need to answer is, does my product solve a problem, or help a problem solver demonstrate value? If a) then the end user is not my customer, if b) it's going to need a lot more knobs and whistles.

White space isn't just white space, it represents the expression of functionality to the customer.

The UX design question always takes you back to first principles, who is your customer and what do they need?

a plumber doesnt ask his customer how to plumb. just which pipes need fixin! doesn't go fix the toilet if the shower is broken :S