The Return of the User.
My organisation fixed something recently. We had a terrible loose-the-will-to-live form that prospective students had to use. It came to the attention of our new CIO, and - bless him - he said let’s fix that. And it got fixed good. Now where there was pain there is joy.
In the breakdown, the story I'm hearing around the office goes something like this...
Student services have been trying to get if fixed for a long time, but a) it was too small to deal with, and b) we are too process-locked and slowed down by heavy governance to respond to problems like that.
Which is all quiet true. And I acknowledged as much in my previous post Is Enterprise Architecture Broken? But why something didn’t get fixed interests me a lot less than why such a bad experience was tolerated in the first place.
I suspect it happens most often when the customer is not the user. In many contexts, (nearly all of those involving a marketable product), they will be the same person. But that only obscures the critical difference between the two. The customer and the user have a different relationship to the built world - and it is really very important;
The customer transfers value.
The user creates it.
I have seen it over and over again in the design of processes, of information, of interfaces. The needs of the customer are paramount.(1) Make sure this gets measured, record that, don't let that happen. The user is only there as a projection of the customer's imagination - often quite a negative projection. Or worse, the users are the customer's subordinates - because "management goggles".
I have worked as an enterprise architect for a fair number of years, before that as an enterprise information architect, before that as a process designer and before that as a developer. In all that time I am struggling to remember one project that was driven by what the users wanted. It was always the customer.
And looking back, the best work I did was always the work where I had some way of interacting with the user and putting their needs front and centre.
Inside organisations the "customer" has, for decades, been well served by architects and program managers and portfolio managers. The user has been left to feast on crumbs...
For very large sums of money vendors sell us information systems that haven't been near a decent user experience team. Often, to the credit of long suffering and caring people on projects and in various departments, valiant and far too costly efforts are made to address the needs of the user. Sadly, there is often too little they can do, because it's too late, and the user is left out in the cold.
As I said above, the customer is well served, and as a byproduct our organisations often are not.
All those things we give people to do their jobs, all those automations, all that information, all of it is so the people using it can create the value an organisation will trade with its customers. (The other ones).
What the current surge of interest in design thinking heralds is the return of the user.
When our CIO got that awful form fixed it was a team of designers and developers who got the job done. They used a common service design technique called journey mapping. They built for the user.
Design thinking leader Tim Brown spoke recently in the Harvard Business Review, about design thinking and competitive advantage. (It's great and worth a look.)
But because design thinking is focused on the value of the thing itself, and not derived management values like efficiency and effectiveness, it naturally gravitates to the user and their needs - whether they are a customer or not.
Which is the other advantage design thinking brings - the productivity advantage - because it's users who produce the value.
Notes:
1: I am focusing on the experience of working to design and implement things inside organisations. I am an enterprise architect, not a product developer or manager. But all those poorly designed, bad products and services that plague modern existence still often make it to market because the same dynamics apply, (derived abstract values, people who already "know" what the market wants, etc), and the user (who in this case actually is a customer) is an a priori composite of other people's imaginations.
"the people who actually use the application to carry out tasks" That's a pretty broad statement. This group of user could include: people who input data into the app; people who use or query data stored or retrieved by the app. people who maintain and administer the app. While I admire you attempt, you've picked and are trying to simplify a pretty complex situation. Your role as an Enterprise Architecture is to get consensus from a wide range of stakeholders classed as users. No one says that role is easy.
From my point of view a more differentiated view is needed between B2C and B2B. In B2C context the user and the customer are very likely to be identical, they act for themselves. In the B2B context the user in general has a role and act on behalf of the company. The needs of the B2B user are in my opinion motivated by other goal, like "get the things done". Sometimes the B2C viewis just transfered to B2B context, without the needed second thougt, delivering nice Ux with too little functionality. Just my 2 cents
Ric the point is in the built world there could be several users, especially for enterprise wide builds.
Which Users are being welcomed back, or did they never really leave. A customer is but one of the stakeholders involved in the operations of an organization. Customers, along with numerous others are the external stakeholders whose activities impact or are of interest to of an organization. These external stakeholders (part of the so called wider enterprise) include: the tax man; financial regulators, product regulators, suppliers/ partners/ service providers and the general public to name a few. These external stakeholders will impact how the organization designs, manages, implements and operates its business processes and information resources. The interests of the external stakeholders are represented by various internal to the organization stakeholders. These internal stakeholders would include The Finance Function, the HR Function, Industrial Engineering & Production Functions, Supply Chain functions, marketing and Sales Functions, Legal Functions, etc. Finance would represent the interests and needs of the Tax Man and Financial Regulators. HR would represent the workplace and other social regulators. Supply chain would represent the interests of suppliers and service providers. Sales and Marketing would represent the interest of the users. And so. In my view these internal to the organization stakeholders are the users. The Users roles are to represent and advance the needs of both the internal and external stakeholders they are responsible for. As an example the Finance stakeholders would ensure that the needs of the Tax man (income and sales tax) are addressed by the processes and information that enable the Organization’s Order to Cash value stream. The Finance Function would also make sure that Order to Cash processes would capture and make available the accounting and costing data that the firm’s internal stakeholders need. Ric, I’ve worked on many enterprise and local business transformation initiatives. I’ve played the Enterprise Architect, Business Architect/Analyst, Data Architect/Analyst/Modeler and Processes Analyst. I’ve acted these roles from within the quote business functions (accounting, HR, Program Delivery) and the IT function. I’ve yet to work on a project were the Internal Stakeholders (Finance, HR, Marketing, etc.) , or as you say the “Users” have NOT had a strong presence to advocate and represent the architectural and design interests of both internal and external stakeholders. Of which The “customer” is only one. Ric, back to my original questions, which Users are you welcoming back.
Strong agree on all of this, Ric - perhaps especially your aside that "the best work I did was always the work where I had some way of interacting with the user and putting their needs front and centre". The only comment I'd add is that often there can be even more facets to this kind of mess. In a B2B context, for example, the person who uses the software or whatever is usually not the same person who buys it (the 'customer', as in your example), but also neither are the person who controls the budget to buy it with, nor are they the person whose needs are served by the user using that software (the 'end-customer' or whatever). Disentangling that kind of mess can be, uh, tricky... :-|