Compatibility of Cost-Center Development and Usability
Lessons learned over two years and several projects attempting to apply what I had learned after completing my masters in User Experience Design.
What is “cost-center development” anyway?
While not universally true in all cases, in this post I’m using the term “cost-center development” as shorthand for development in support of business-to-business (B2B) or business-to-government (B2G) activity and “profit-center development” as shorthand for development in support of business-to-consumer (B2C) activity.
Generally speaking, cost-centers don’t bring in money but instead aim to reduce cost in some way while profit-centers bring in more money than they cost to operate.
The fundamental problem
Successfully optimizing for user experience requires explicit buy-in from leadership and acceptance that the value UX brings is hard to directly quantify, which isn’t something decision makers of cost-center activities have the stomach for.
Cost-centers don’t bring in money, so any activity that increases cost is allowed if and only if ignoring it will introduce legal/regulatory risk. The process of maximizing usability takes time and intentional thought to get right. In cost-center activities, the customer usually has a large say in the delivery timeline and will look to omit anything that costs more that looks easy to omit. This problem is made worse the further removed the customer’s decision makers are from the customer’s end users.
On the other end, profit-centers live and die by their sales. This makes selling usability much easier as business leadership has become more aware of the relationship between UX and a product’s adoption by a discerning public.
Cost-centers sometimes pretend to be profit-centers…
Many software projects that exist in cost-centers, in a desire to attract developers and designers capable of delivering well-functioning systems that users won’t hate, will downplay the second-class citizen nature of UX to their organization/activity. Some may even outright ask for someone with a solid understanding of UX.
Why does this happen?
The reason for this behavior is usually an effort to secure follow-on work if someone on the other side of the table is wow-ed enough with the results (sadly, visual appeal is often enough to wow both parties).
This isn’t as intentionally dishonest as it sounds. Consider that many people hear “UX” and think “oh this person slings JavaScript and CSS or something” while others think “oh they do stuff with Photoshop”. There isn’t enough concrete understanding out there of what UX actually is. So when the cost-center gets a bonafide but otherwise naive UX practitioner who starts talking about running usability tests and doing research instead of just writing the stinkin’ code and closing tickets, project managers start getting nervous about missing deadlines.
The project manager may humor the UX practitioner’s appeals to process but won’t alter delivery schedules to accommodate anything that’s not explicitly a coding task. This has the effect of “code this” Jira tickets piling up while UX activities are conducted -OR- the UX practitioner scuttles sound usability practice in order to meet their code deliverables. Either way, something gets sacrificed: codebase stability or usability.
So that “naive UX practitioner” up there was me…
I left that company last summer. Despite being constantly asked to “do UX” but not being given enough time to do it properly for fear of falling behind, our customers seemed happy with the deliverables and gave us follow-on work so both parties felt they got their money’s worth. And despite being asked to do two and half people’s jobs, the company paid fairly well so I wasn’t bitter, just tired.
And so, a little older and a little wiser, I reassessed my career priorities and expectations and moved on.
A few months later, as if responding to the disturbance in the force caused by my awakening, one of my old professors posted to LinkedIn a debunking of the corporate legend of the “UX Unicorn” (i.e., UX designers that write code):
This will be a hard pill for many to swallow, but the history of UX occupations proves that coding and programming are NOT truly a part of mainstream UX operation. In other words, one seeking a role in UX need not have programming skills in order to do his or her job.
Can you have coders on your UX team? Yes, but that’s not the point we’re addressing. Programming and coding were and are only a part of the UXer’s role when working for companies in the lower quadrant (at least) of UX maturity. The more mature a company is (or was) the less likely a UXer would be looked to for coding. The less mature, the more hats a person was likely to be asked and/or expected to wear.
Coding does not help with information architecture.
Coding does not help with interaction design.
Coding does not help with research.
Coding does not help prescribe optimal usability.
Coding does not help with cognition.
Coding does not help with empathy.
Coding does not help create experience or journey maps.
Coding does not help with ethnography.
It....just....ain’t....a....thing.... no matter how anyone tries to spin it and no matter how people keep trying to redefine the UX world. Prof. Darren Hood
A hard pill indeed.