user experience

From NB Referata Wiki
Jump to: navigation, search

A user experience is just that, an experience of an end user of a system or service. Prior to release, all experiences are aspirational. proposed, fictional or otherwise specified as an ideal. The discipline of User Experience is its own profession and involves ergonomics, task design, graphic and audio design, documentation, customer support scripting, etc. A user experience precedent is a well known command grammar that users already know well and includes verbs (like "edit", "like", "share", "follow" or "watch", etc.) that users already understand in the context of software and use to describe not just the system's behavior but their own (i.e. "I liked a few of Joanie's posts, shared them, then followed her.").

User experience terminology[edit]

"User experience includes the practical, experiential, affective, meaningful and valuable aspects of human–computer interaction and product ownership. Additionally, it includes a person’s perceptions of system aspects such as utility, ease of use and efficiency. User experience may be considered subjective in nature to the degree that it is about individual perception and thought with respect to the system. User experience is dynamic as it is constantly modified over time due to changing usage circumstances and changes to individual systems as well as the wider usage context in which they can be found."

The international standard on ergonomics of human system interaction, ISO 9241-210 defines user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". Thus all the users' emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. See epic below.


"Usability criteria can be used to assess aspects of user experience" and generally includes the pragmatic aspect (getting a task done, errors or failures encountered) while experience is more as defined in customer support, including users’ feelings stemming both from pragmatic and hedonic aspects of the system. Many practitioners use the terms interchangeably, or they use usability to mean design, and user experience to mean study of the impact of a design within the marketing process.

user experience (UX) the profession[edit]

UX as a profession ("User Experience") evolved in the 1980s to 2000s through the professional development curricula of mostly major ACM conferences ACM SIGCHI and ACM SIGGRAPH, where academic and corporate researchers presented formal studies of the ergonomics, psychology, sociology and sometimes economics of online work. Today's social media benefit from studies of computer-supported cooperative work or 'telework' conducted as early as the 1990s. The history of graphic user interfaces is at least as old as the 1970s and the Xerox PARC research that inspired the Mac. See Wikipedia for a more extensive introduction to the field's goals and studies.

The purpose of the profession, however is to study real user experience and improve it, something every development project and online service and software company must do, every day.

customer support and quality control professions[edit]

Customer support and quality control are today defined as an inherent part of the UX responsibility, that is, experiences of end users are considered the deliverable, not any particular product. See Pine and Gilmore's commodity/product/service/experience/transformation value chain -> providing an experience pays better than providing a mere service or product, generates more loyalty and confidence.

Large software enterprises like Amazon etc now regularly put developers on the support line to directly experience quality problems. Hardware and operating system companies require use of betas and recently released products inhouse, so that those creating the product will also be the first to discover bugs. This is called eating your own dog food in the profession.

This praxis as a whole is called support-driven development.

user stories[edit]

Any user experience can be related - however poorly - in natural language. For instance as documented on customer support tickets.

All user stories are fractal, i.e. they can be told and re-told at any level of detail, and stretch, i.e. they can be extended to cover earlier moments in time when the interaction with the system is first contemplated and later moments when all implications of the interaction become clear. A fat user story, shaggy dog user story, long user story, also known as an epic [1] or simulated support story is one that tends towards detail and full disclosure of all the reasons for using a system, all the problems of using it, and the implications of same.

The main objectives of user stories are, in order:

  1. Anticipate failures: If a failure condition isn’t in the fictional user stories, it will sure as hell be in the real customer support tickets. When would you prefer to encounter it?
  2. Elaborate ambitions: If you cannot clearly explain to users how your service/software/product will be superior to those of competitors in some future release, how can you keep them? If you cannot convince developers that the product will meet the most difficult needs of users, how can you keep the best ones? If you cannot clarify what the product will do and what it is not, how can you avoid over-promising or over-selling features?
  3. Test use cases and releases: Can the use cases for each release accomodate the user stories completely, or are there unimplemented features, unmet needs, and failure conditions? If a particular desirable user story is not implemented in this next release, then in which release will it be? If a particular undesirable story is still occurring in this release, when will it no longer occur? Critical to managing customer expectations.

in support[edit]

In support-driven development, pre-alpha functional specification stories (fictional), pre-alpha hands-off demo stories (aspirational), alpha user stories (from marketing) and beta-and-beyond user experience (from) are all documented in the same way and ideally with the same tool - see project management. The only difference between them is their levels of detail and their degree of fictionality (true actual paying end user experience, one that came from outreach to real users but is an aggregate or proposed experience, or a fictional aspirational user story that helps guide the system design in the early phases). In other words, a specification stage user experience/story is JUST A FICTIONAL CUSTOMER SUPPORT TICKET. More on SDD [2][3][4][5][6]

in early development[edit]

Before there is any search on any customer issue tracker DB, when all user stories are fictional, as a general rule, each module description must include a section of one-line summaries or titles of stories that involve those modules. This makes it easy to track which stories affect without undue clutter. While stories can be sometimes clustered by theme (see below), epic stories (see below) may illustrate and bring together a theme, or they may be so cross-thematic that they belong on their own pages. Conventions vary for how themes of related short stories should be presented.

There is no general rule possible for how many and how long user stories should be. Be extremely suspicious of such "rules" as they may come from a business context very different from yours.

While a few epic stories are necessary to illustrate potential failure conditions, for sprint purposes developers are often "Breaking down...a 30 day story into say 5 x 6 day stories" As the "agile approach is to pin down Schedule, i.e. time-box; pin down Cost, i.e. have a stable team for the duration; and use Scope as the key lever by which the first two objectives can be honoured." [7]


A series of related user stories is sometimes called a theme [8]. All experiences with one user or type of user can be considered a theme, once the system is deployed. Terminology between customer support and development needs coordination, it's detrimental to have to translate customer data into a different form just so developers can read it.

In SDD themes may be organized by deployment phase:

  • hands-off demo scripts
  • hands-on demo training and pre-sales support experiences
  • alpha test experiences that actual users should be having with the mission-critical aspects of the system
  • beta test experiences that actual users should be having with all aspects of the system as intended for MVP release
  • MVP functions that are guaranteed to function or your money back
  • next release functions that are currently being elaborated
  • later release functions that will not be in the next release

Or, they may be organized by types or classes of user:

  • managerial user concerned with task commitments and resources
  • analytic user concerned with process data and recommendations
  • field user who adds observations, photos, videos, annotations
  • financial user concerned with overall measurement in currency

Epics (stories that illustrate multiple themes)[edit]

An "epic" is a fictional or quasi-fictional sequence of events that torment a particular hapless person who you are supposed to sympathize with. The meaning is the same as it is in English: Homer has us sympathize with Odysseus for instance. You are supposed to sympathize with Ben Hur or Scarlett O'Hara even if they create their own problems. Epics are stories of specific people trying to just get their job done or avoid trouble, and "the system" presents them with lots of nasty challenges. An epic is not abstract, it's a sequence of events and it's typically tragic to emphasize failure conditions. An epic is not a broad abstract goal or theme of related stories'. Use the word "theme" to describe non-sequential non-specific classes of user stories. Use the words properly.

Epics are annoying[edit]

An epic should be aspirational and problematic enough that it both annoys and inspires users. It should contain extreme scenarios that no one really wants to believe could occur, but which are probably just over the bounds of what is likely.

Epics break down into more manageable stories per sprint[edit]

It is certainly possible to deconstruct an epic into multiple use cases, multiple simpler user stories, and break it down into stories that can be fully accomodated and supported in one sprint. That is precisely why epics are useful. An epic that can be wholly dealt with in one sprint or release, just isn't.

The epic should remain however still visible and linked to the stories it inspires which are fractal subsets of its complexity.

Epics are sequences that illustrate multiple themes[edit]

The whole reason to write SPECIFIC, LINEAR, REALISTIC user experience sequences is to imagine exact examples of success and failure. Examples very similar to the worst problems anticipated once the product is released to real users. An epic could be called an extensive and tragic user experience sequence.

An epic can be modelled to some degree as a UML sequence albeit a rather long one involving lots of people and modules and subsystems that become visible because they just failed. If you can't make a UML sequence/trace out of it, it isn't a story, and if you aren't illustrating several themes, it isn't an epic.

Some people confuse abstract lists of goals, or themes that describe many sequences or stories. Were these to be submitted to The New Yorker, they would say "This is not a story. Sorry. It has no characters. It has no drama. It has no moral". And they'd be right. Epics are works of fiction that make it hard to forget the unique sustainable edge of the system they help to specify. One goal of epics is to make actual end user experiences on the customer support line seem fun by comparison, and to anticipate and pre-solve every problem before a customer.

Epics are a simulation of best and worst support stories[edit]

Any system acquires such stories once in actual use, as actual support tickets and call records. Like actual support calls, an epic includes several interactions over time with a system in the course of carrying out a business priority, and encountering various failures (some the fault of the system, and probably most not). Relying on these has the advantages:

  • customer support and design explain UX the same way and deal with real and anticipated failures identically
  • it takes far fewer fat stories to detail all possible failure conditions than relying on short ones
  • design breakthroughs are more likely when stories are elaborated with the user's objectives specified

Once a system is released, the epics come in from the support line. Support-driven development emphasizes preparing for those by already having dealt with the most complex anticipated problems of the system, using fictional epics full of challenge.

Epics illustrate unique competitive edges and risks[edit]

High-reliability, high-availability, privacy-sensitive, or legally- or politically-vulnerable services can only be fully specified using them, because only such stories can illustrate the entire economic and other implications of using the system. Unlike briefer stories, the fat user story includes important business or social implications of use. The intent is to resemble as closely as possible the worst cases of actual use, so as to minimize these vulnerabilities.

For mission-critical features, a "big fat user story" may just be inevitable because it's real, that is, a realistic (albeit fictional) story about what will happen in the field when the product is released. The main purpose of epic user stories ("epic" being a nice word that doesn't have the negative associations of "fat") is to illustrate failure conditions.

Some developers hate epics[edit]

Some "agile" developers advise cutting user stories down to one line so that all the effort goes into use cases. Thus end user experts are expected to look at what amounts to flow charts and try to figure out if intentions are well expressed and failures avoided by that flow. There's simply no way to get a legitimate sign off on use cases, so in practice this means "just trust me" and it risks a lot on the developer's understanding of the field and even the systems administration context the customer is in.

This practice may be appropriate where systems are commissioned by persons who have no ability to document what they know except by feedback from working with real tools, or where the system's ultimate use is not fully understood. As a rule a constrained system trying to meet ISO standards and automate relatively rigorous business processes would not benefit from avoiding epics. It might, however, benefit from documenting experience in demonstrations more than from fictional pre-demo speculation.

double length sprints[edit]

There is no way to limit a user experience for developer needs.

If a double-length sprint is required when dealing with mission-critical features, so be it. Marking that sprint out as exceptional and perhaps using more rigorous methods like UML sequence diagrams to map out story traces, then cross-checking them against UML use cases, is entirely reasonable for that 20% of the system for which users pay 80% of their money and in which they spend 80% of their time. The definition of "agile" was supposed to be rigor as required, not no rigor.

While there's nothing wrong with failing rapidly, there's a lot wrong with failing repeatedly. Mission critical features that cause customers to pay money for software or services need much more elaboration with all failure conditions anticipated, because failures that are not anticipated, will always recur.

Support-driven development[edit]

In support-driven development, deployed systems are specified and debugged using exactly the same methodology as pre-deployment. Epics are the most critical specification tool:

  1. several failure conditions can be included in one story
  2. multiple interactions, i.e. multiple use cases or more than one path through each case, can be included, as would be the case in any actual customer support tale
    1. accordingly it takes far fewer user stories' to cover all the possible failures or confusions
  3. they can be narrative, even funny, thus easier to remember and assign mnemonics
    1. they are much more useful in training and in demos
    2. they are much more useful in sales, e.g. "here's a fail that happens a lot with competing software, and here's how we made it simpler to deal with"
  4. they help train support personnel to deal with difficult customers and cases, i.e.
    1. pretending the story is real on the phone to train the hapless new staff
    2. documenting incomplete customer reports as multiple fat user stories so that all possibilities get tested
    3. seamless integration of theoretical and actual customer support stories/tickets
  5. they encourage anticipating and documenting the worst cases instead of ignoring them until customers see them
    1. developers often dodge responsibility by hiding the worst cases they cannot deal with, fat user stories make that extremely difficult
  6. they are easily translated into work flow notations such as UML event traces.

Practitioners of this approach, including Craig Larman[9] and Craig Hubley, claim that the epic or fat user story approach will pick up even non-obvious or non-functional requirements at the very large scale. Providing a significant edge and comfort especially to early adopters with extreme vulnerabilities or who risk significant liabilities from failure use cases.

where it originated[edit]

This fat user story or epic user experience approach is more common in financial risk management (portfolio stress testing, arbitrage), safety-critical systems (emergency response), privacy-critical communications systems (dating, confidential fax and email) than otherwise.

However, its advantages apply in any type of software or service. In larger scale development, 24x7 service, and sensitive and high risk services, the fat user story should probably be considered mandatory at least for the highest liability uses.


Based on material on SDD from ECG, licensed royalty-free for use in Wabanaki Confederacy and directly relayed Wabanaki ally project needs only. Do not copy without prior permission, do not use for commercial purposes and do not modify records to hide changes that weren't from ECG.