I have a decided fixation on ‘user experience‘. However, I couldn’t tell you what I am looking for exactly. This is an attempt to remove the fuzziness.
It seems to me that there are two primary questions.
- Who are the users anyway, of an enterprise system?
- What should these users be able to expect from a system?
The users of an enterprise system
Anyone who interacts with the enterprise system in any way at all, I consider its users.
- Employees who use the system to conduct the business of the enterprise.
- Tech folks who create, maintain, enhance, and run the system.
- Managers
- Programmers
- Testers
- Dev Ops (Software configuration folks, System Admins)
- Software Operators
- Business partners who use the system
- Customers who use the system
All of these folks, in their various capacities, must have good ‘user experience‘. What does ‘user experience‘ mean to each of these folks?
Common to all users
In this post I will only list behavior that I believe applies across all classes of users. In subsequent posts, I’ll go more into what might make sense for various individual classes of users.
Business functions must exhibit the following characteristics.
- They must be performant – must execute just as fast as necessary, regardless of the load on the system.
- Failure of a function must not leave the system in an incorrect state, which might require invasive, and manual cleanup. Rollback as necessary.
I've been involved in exercises where dealing with the errors that production code left in its wake, became a full time job. There are many reasons why a development task ends up here, including holes in business analysis, code construction, and testing. None of this is rocket science. The relevant skills can be acquired, and these potholes can, and must be avoided.
- Every business command must be available through three avenues – a GUI, a DSL that you use at the command line, and as pluggable units in external systems like schedulers, ESBs, and workflow management systems.
A single API must support all these various methods of invoking business functionality. You are taught to create interfaces that are appropriate to all levels of expertise. Stepping through 8 web pages in order to make one edit on the 9th page might be acceptable for non-tech savvy customer service rep. However, a developer, who is dealing with a customer support issue, does not have to deal with the overhead of all that UI. Two lines of script ought to do the same job just nicely. You could use SQL and change data directly in the system's database. But wouldn't you rather go through the application's infrastructure, which presumably has essential checks and balances in place. That is where the domain specific language (DSL) comes in. A DSL would also enable functional testing, while avoiding the drudgery of dealing with the UI.
- You must be able to access the business function from the device of your choice – desktops, laptops, tablets, phones.
This is where the world seems to be heading. Either get on the bandwagon, or be left behind.
- Command line access must be in the form of a domain specific language (DSL) with which you can write scripts to tie together various functions in a workflow.
- Long lived commands must have these behavior.
- Run them in the background, and bring them into the foreground as necessary.
- Expose current status, and progress.
- Allow you to abort in the middle of execution, and return the system safely to the previous state.
- Allow you to stop and resume where you left off.
Required skills
Not every project, at every client, will ask for all the features described above. However, I believe it represents a set of skills that an engineering outfit can reasonably be expected to have. I want to be able to deliver this functionality.
There is little here that is exotic. I only see three or four main streams of skills, all of which are well understood, and well supported.
- Learn to measure, manage, and deliver performance.
- Learn to architect business functions such that they lend themselves to manipulation from the command line, and GUI. This mostly consists of creating well-designed APIs.
- Learn to create GUI in a browser neutral fashion, and for various mobile devices.
- Learn to create well-engineered and expressive DSLs.
Is it practical for a small and competent team to be able to develop these competencies, and employ them successfully? I would have to think so.