{"id":286,"date":"2013-06-25T11:45:10","date_gmt":"2013-06-25T11:45:10","guid":{"rendered":"http:\/\/www.seonthemon.com\/wp351\/?p=286"},"modified":"2013-07-25T03:05:13","modified_gmt":"2013-07-25T03:05:13","slug":"user-experience-in-an-enterprise-system","status":"publish","type":"post","link":"https:\/\/www.seonthemon.com\/wp351\/2013\/06\/25\/user-experience-in-an-enterprise-system\/","title":{"rendered":"User experience in an enterprise system"},"content":{"rendered":"<p>I have a decided fixation on &#8216;<em>user experience<\/em>&#8216;. \u00a0However, I couldn&#8217;t tell you what I am looking for exactly. \u00a0This is an attempt to remove the fuzziness.<\/p>\n<p>It seems to me that there are two primary questions.<\/p>\n<ul>\n<li>Who are the users anyway, of an enterprise system?<\/li>\n<\/ul>\n<ul>\n<li>What should these users be able to expect from a system?<\/li>\n<\/ul>\n<p><b>The users of an enterprise system<\/b><\/p>\n<p>Anyone who interacts with the enterprise system in any way at all, I consider its users.<\/p>\n<ul>\n<li>Employees who use the system to conduct the business of the enterprise.<\/li>\n<\/ul>\n<ul>\n<li>Tech folks who create, maintain, enhance, and run the system.\n<ul>\n<li>Managers<\/li>\n<li>Programmers<\/li>\n<li>Testers<\/li>\n<li>Dev Ops (Software configuration folks, System Admins)<\/li>\n<li>Software Operators<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Business partners who use the system<\/li>\n<\/ul>\n<ul>\n<li>Customers who use the system<\/li>\n<\/ul>\n<p>All of these folks, in their various capacities, must have good &#8216;<em>user experience<\/em>&#8216;. \u00a0 What does &#8216;<em>user experience<\/em>&#8216; mean to each of these folks?<\/p>\n<p><b>Common to all users<\/b><\/p>\n<p>In this post I will only list behavior that I believe applies across all classes of users. \u00a0In subsequent posts, I&#8217;ll go more into what might make sense for various individual classes of users.<\/p>\n<p>Business functions must exhibit the following characteristics.<\/p>\n<ul>\n<li>They must be performant &#8211; must execute just as fast as necessary, regardless of the load on the system.<\/li>\n<\/ul>\n<ul>\n<li>Failure of a function must not leave the system in an incorrect state, which might require invasive, and manual cleanup. \u00a0Rollback as necessary.<\/li>\n<\/ul>\n<pre style=\"padding-left: 60px;\">I've been involved in exercises where dealing with the errors that \r\nproduction code left in its wake, became a full time job.  There are \r\nmany reasons why a development task ends up here, including holes in \r\nbusiness analysis, code construction, and testing.  None of this is \r\nrocket science.  The relevant skills can be acquired, and these potholes\r\ncan, and must be avoided.<\/pre>\n<ul>\n<li>Every business command must be available through three avenues &#8211; 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.<\/li>\n<\/ul>\n<pre style=\"padding-left: 60px;\">A single API must support all these various methods of invoking business\r\nfunctionality.\r\n\r\nYou are taught to create interfaces that are appropriate to all levels \r\nof expertise.  Stepping through 8 web pages in order to make one edit \r\non the 9th page might be acceptable for non-tech savvy customer service \r\nrep.  However, a developer, who is dealing with a customer support issue, \r\ndoes not have to deal with the overhead of all that UI.  Two lines of \r\nscript ought to do the same job just nicely.  You could use SQL and change \r\ndata directly in the system's database.  But wouldn't you rather go \r\nthrough the application's infrastructure, which presumably has essential \r\nchecks and balances in place. That is where the domain specific language \r\n(DSL) comes in.\r\n\r\nA DSL would also enable functional testing, while avoiding the drudgery of \r\ndealing with the UI.<\/pre>\n<ul>\n<li>You must be able to access the business function from the device of your choice &#8211; desktops, laptops, tablets, phones.<\/li>\n<\/ul>\n<pre style=\"padding-left: 60px;\">This is where the world seems to be heading.  Either get on the bandwagon, \r\nor be left behind.<\/pre>\n<ul>\n<li>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.<\/li>\n<\/ul>\n<ul>\n<li>Long lived commands must have these behavior.\n<ul>\n<li>Run them in the background, and bring them into the foreground as necessary.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<ul>\n<li>Expose current status, and progress.<\/li>\n<\/ul>\n<\/ul>\n<ul>\n<ul>\n<li>Allow you to abort in the middle of execution, and return the system safely to the previous state.<\/li>\n<\/ul>\n<\/ul>\n<ul>\n<ul>\n<li>Allow you to stop and resume where you left off.<\/li>\n<\/ul>\n<\/ul>\n<p><b>Required skills\u00a0<\/b><\/p>\n<p>Not every project, at every client, will ask for all the features described above. \u00a0However, I believe it represents a set of skills that an engineering outfit can reasonably be expected to have. \u00a0I want to be able to deliver this functionality.<\/p>\n<p>There is little here that is exotic. \u00a0 I only see three or four main streams of skills, all of which are well understood, and well supported.<\/p>\n<ul>\n<li>Learn to measure, manage, and deliver performance.<\/li>\n<\/ul>\n<ul>\n<li>Learn to architect business functions such that they lend themselves to manipulation from the command line, and GUI. \u00a0This mostly consists of creating well-designed APIs.<\/li>\n<\/ul>\n<ul>\n<li>Learn to create GUI in a browser neutral fashion, and for various mobile devices.<\/li>\n<\/ul>\n<ul>\n<li>Learn to create well-engineered and expressive DSLs.<\/li>\n<\/ul>\n<p>Is it practical for a small and competent team to be able to develop these competencies, and employ them \u00a0successfully? \u00a0 I would have to think so.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I have a decided fixation on &#8216;user experience&#8216;. \u00a0However, I couldn&#8217;t tell you what I am looking for exactly. \u00a0This 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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6],"tags":[8,40,18],"_links":{"self":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/286"}],"collection":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/comments?post=286"}],"version-history":[{"count":10,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/286\/revisions"}],"predecessor-version":[{"id":288,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/posts\/286\/revisions\/288"}],"wp:attachment":[{"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/media?parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/categories?post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.seonthemon.com\/wp351\/wp-json\/wp\/v2\/tags?post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}