The Hidden Cost of Cheap – UX and Internal Applications

Sisyphus by Titian

Why would anyone worry about user experience for anything that’s not customer-facing?

This question was the premise of Maurice Roach’s post in the Zühlke blog, “Empathise with your users or you won’t solve their problems”:

Bring up the subject of user empathy with some engineers or product owners and you’ll probably hear comments that fall into one of the following categories:

  • Why do we need to empathise when the requirements tell us all we need to know about the problem at hand?
  • Is this really going to improve anything?
  • Sounds like an expensive waste of time
  • They’ll have to use whatever they’re given

These aren’t unexpected responses, it’s easy to put empathy into the “touchy feely”, “let’s all hug and get along” box of product management.

Roach’s answers:

Empathy does a number of things, but mainly it increases the likelihood that the delivery team will think of a user and their pain points when delivering a feature.

If an engineer, UX designer or product owner will has sat with a user, watched them interact with their current software or device they will have an understanding of their frustrations, concerns and impediments to success. The team will be focused on creating features with the things they have witnessed in mind, they’re thinking about how their software will affect a human being and no amount of requirement documentation will give them that emotional connection.

Empathy can also help to develop a shared trust in the application development process. The users see that the delivery team are interested in helping to solve their problems and the product delivery team see the real users behind the application.

All of these are valid reasons, but the list is incomplete. All of these answer the question from a software development point of view. To his credit, Roach pushes past the purely technical aspects into the world of the user. This expanded exploration of the context is, in my opinion, absolutely essential. What’s presented above is an IT-centric viewpoint that needed to be married with a business-centric viewpoint in order to get a fuller picture.

Nick Shackleton-Jones, in his post “The Future Is… Organisational Usability!”, outlined on the problem:

Here’s how your organisation works: you hire people who are increasingly used to a world where they can do pretty much anything via an app on their iPhone, and you subject them to a blizzard of process, policy, antiquated systems and outdated ways of working which pretty much stop them in their tracks, leaving them unproductive and demoralised. Frankly, it’s a miracle they manage to accomplish anything at all.

As he notes, enterprises are putting a lot of effort into digital initiatives aimed at making it easier for customers to engage with them. However:

…if we are going to be successful in future we need to make it much easier for our people to do their jobs: because they are going to be spending less time with us, and because we want engagement and retention, and because if we require high levels of capability (to work our complex systems) then our resourcing costs will go through the roof. We have to simplify ‘getting stuff done’. To put it another way: in an ideal world, any job in your organisation should be do-able by a 12-yr old.

While I disagree that “any job in your organisation should be do-able by a 12-yr old”, Shackleton-Jones point is well-taken that it is in the interests of the business to make it easier for people to do their jobs. All aspects of the system, whether organizational, procedural or technological, should be facilitating, not hindering, the mission. Self-inflicted, unnecessary impediments are morale-killers and degrade both effectiveness and efficiency. All three of these directly impact customer-experience.

While this linkage between employee user experience and customer experience makes usability important for line of business systems (both technological and social), it has value for peripheral systems as well. Time people spend on ancillary tasks (filling out time sheets, requesting supplies, etc.) is time not spent on their primary duties. You may not be able to eliminate those tasks, but you can minimize their expense by making them quick and easy to complete. The further someone’s knowledge/skill/experience level gets from “do-able by a 12-yr old”, the bigger the savings by paying attention to this.

Rather than asking if you can afford to pay attention to user experience, you might want to ask whether you can afford not to.

Enterprise Architecture and the Business of IT

Turning Gears Animation

I’ve been following Tom Graves and his Tetradian blog for quite a while. His view of Enterprise Architecture (EA), namely that it is about the architecture of the enterprise and not just the enterprise’s IT systems, is one I find compelling. With some encouragement on Tom’s part, I’ve begun touching on the topic of EA, although in a limited manner. When it comes to enterprise architecture, particularly according to Tom’s definition, I consider myself more of a student than anything else. I design software systems and systems of systems, not the enterprises that make use of them.

However…

I’m finding myself drawn to the topic more and more these days. I’m finding it more and more relevant to my work. The fractal nature of social systems using software systems is a major theme of the category “Organizations as Systems” on this site. If the parts fit poorly, then the operation of the system they comprise will be impeded. A good way to ensure the parts fit poorly is to fail to understand the context in which they will inhabit. So while I may not be designing the social system which my systems fit into, an understanding of how that system functions is invaluable, as is an understanding of how my social system (IT) interacts with my client’s social system (the rest of the business) to further the aims of the enterprise.

Tom’s latest post, “Engaging stakeholders in health-care IT”, is an excellent example of how not to do things. In the post, Tom discuss attending a conference on IT in healthcare where the players had no real knowledge about healthcare. They couldn’t even identify the British Medical Journal or the Journal of the American Medical Association, much less have an idea about what issues might be found in the pages of those publications. They didn’t feel that was a problem:

Well, they didn’t quite laugh at me to my face about that, but in effect it was pretty close – a scornful dismissal, at best. In other words, about the literally life-and-death field for which they’d now proclaimed themselves to be the new standard-bearers, they were not only clueless, but consciously clueless, even intentionally clueless – and seemingly proud of it, as well. Ouch… At that point the Tarot character of ‘The Fool’ kinda came to mind – too self-absorbed to notice that he’s walking straight over a cliff

While I recently advocated embracing ignorance, it was in the context of avoiding assumption. The architect will know less about the business than a subject matter expert who will most likely know less than the end user on the pointy end of the spear. The idea is not to remain ignorant of the domain, but to avoid relying on our own understanding and seek better sources of information. It’s unreasonable to think we can design a solution that’s fit for purpose without an understanding of the architecture of the problem, and make no mistake, providing solutions that are fit for purpose is the business of IT.

A Meaningful Manifesto for IT

“Customer-centricity” is one of the biggest tags in the tag cloud to the right. My first post this year was “Is 2016 the Year for Customer-Focused IT?”. It’s a concept that I find vitally important to IT for the simple reason that to the extent that IT is not fit for purpose, it’s a waste of money. How well (or not) we’re meeting the needs of our clients determines that level of fitness.

Seth Godin’s recent post, “A manifesto for small teams doing important work”, contains a great deal of wisdom for IT, primarily because it starts with a customer-centric approach:

If you make a promise, set a date. No date, no promise.

If you set a date, meet it.

If you can’t make a date, tell us early and often. Plan B well prepared is a better strategy than hope.

Talk to everyone as if they were your boss, your customer, the founder, your employee. It’s all the same.

It works because it’s personal.

Trust is a crucial basis for a relationship, and IT is in the relationship business, or it’s operating at a disadvantage. IT is pricey, so without the value provided by a good relationship, there is a tremendous incentive to shop based on price. If corporations had been better at managing outsourced software development, insourcing might not be the current trend. The current issue of “shadow IT” certainly belies the notion that companies are happy with the service they’re getting.

IT doesn’t exist in a vacuum. IT systems, the social system(s) by which they’re provisioned, and the social systems which make use of them must all work together in reasonable harmony or risk dysfunction. I’m of the opinion that embedded IT (whether literal or figurative) would be useful in bridging the gap. Humility and responsibility would go a long way toward helping. Likewise, tailoring solutions to problems would help better than chasing fads is a good strategy. Meeting needs will get a better reception than attempts to control, particularly when we attempt to control what we don’t own. At the very least, we need to learn to communicate.

Those are principles I can get behind.

The Business of IT – Customers, Clients, and Fit for Purpose

Nesting Doll

Over the past few months, I have touched on a variety of what might seem to be disparate topics: the need for architects (or at least architectural design), estimates, organizations as systems/enterprise architecture, customer-centricity, and IT management and governance. I suspect the trend will continue for a while, so it’s time for a post to explicitly tie things together.

The concept of “organizations as systems” is the cornerstone. Software systems do not exist in isolation, but within a fractal set of contexts, each of which are systems themselves. These systems serve as the ecosystem for those they contain and will ultimately end in one or more social systems. Understanding the ecosystem is critical to ensuring that its component systems are fit for purpose, otherwise we risk trying to introduce fish into a desert.

The social system context is, in my opinion, key. Information technology delivery can take place in a wide variety of ways, but a useful high-level differentiation is that between delivery of an off-the-shelf product versus delivery of a service. Is the customer a client?

These two sentences, left alone, could be a source of confusion. Precision isn’t one of the English language’s strong points. Not all products are off-the-shelf, sometimes the service we deliver is the creation of a bespoke product (ultimately, the end user is concerned with the product that they will use, not the project by which we created it). Likewise, in my opinion, clients are customers, just not all customers are clients. In my career, I’ve exclusively dealt with client customers, so I tend to use the two terms interchangeably. That becomes a problem when we have a client that isn’t being treated like a client. Seth Godin’s recent post explained the difference nicely:

The customer buys (or doesn’t buy) what you make.

The client asks you to make something.

The customer has the power to choose, but the client has the power to define, insist and spec.

There is a large number of potential customers, and you make for them before you know precisely who they are.

There are just a relative handful of clients, though, and your work happens after you find them.

If a customer doesn’t like what’s on offer, she can come back tomorrow. If the client doesn’t like what you deliver, she might leave forever.

When a vendor fails to treat its customers as clients, they risk losing the client. When an in-house IT organization treats fails to treat its captive customers as clients, the result is “Shadow IT”. When that result is complained about, it betrays a shocking lack of awareness on the part of the complainer.

A client will have a hierarchy of concerns in relation to IT. The client’s main interest is the job that they’re doing (or will be doing) with a product. Their concern with the product will be shaped by that, as will their concern with the process by which the product is delivered. We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.

Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.

Just as the infrastructure environment can influence design decisions, so can the social environment. While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong. We wouldn’t try to force a square peg in a round hole and we shouldn’t try to force ill-fitting solutions on those who depend on our work. Products generally work best when they’re designed to be used in the way they’re used. The same holds true for services.

[Recursive Matrena 01 image by Vahram_Mekhitarian via Wikimedia Commons]

Updated 4/8/2016 to fix a broken link.