Permalink
Browse files

Edit & publish complexity of UX

  • Loading branch information...
1 parent a393b05 commit 63da9afc47318bade392c8b54c059aec6d143ae5 @ept committed Oct 8, 2012
Showing with 80 additions and 63 deletions.
  1. +80 −63 src/{complexity.md → _posts/2012-10-08-complexity-of-user-experience.md}
@@ -29,52 +29,12 @@ developers using an API exposed by the system, or as end users interacting with
will concentrate mostly on user interfaces, but much of this discussion applies to APIs too.
-What's a user requirement?
---------------------------
-
-Brooks introduced the distinction between **essential complexity** (roughly speaking, performing the
-key operations that users care about) and **accidental complexity** (stuff that's just required to
-grease the wheels, but isn't visible to users). Paraphrasing Moseley and Marks, the former is
-beautiful, pure and typically fairly simple already, whereas the latter is typically messy,
-implementation-dependent and should be removed or abstracted away as much as possible.
-
-This distinction hinges crucially on the understanding of what **user problem** is being solved, and
-that's where things start getting tricky. When you say that something is essential because it
-fulfils a **user requirement** (as opposed to an implementation constraint or a performance
-optimisation), that presupposes a very utilitarian view of software. It assumes that the user is
-trying to get a job done, and that they are a rational actor. But what if, say, you are taking an
-emotional approach and optimising for **user delight**?
-
-What if the user didn't know they had a problem, but you solve it anyway? If you introduce
-complexity in the system for the sake of making things a little nicer for the user (but without
-providing new core functionality), is that complexity really essential? What if you add a little
-detail that is surprising but delightful?
-
-You can try to reduce an emotional decision down to a rational one --- for example, you can say that
-when a user plays a game, it is solving the user's problem of boredom by providing distraction. Thus
-any feature which substantially contributes towards alleviating boredom may be considered essential.
-Such reductionism can sometimes provide useful angles of insight, but I think a lot would be lost by
-ignoring the emotional angle.
-
-You can state categorically that "great user experience is an essential feature". But what does that
-mean? By itself, that statement is so general that could be used to argue for anything or nothing.
-User experience is subjective. What's preferable for one user may be an annoyance for another user,
-even if both users are in the application's target segment. Sometimes it just comes down to taste or
-fashion. User experience tends to have an emotional angle that makes it hard to fit into a rational
-reasoning framework.
-
-What I am trying to get at: there are things in software that introduce a lot of complexity (and
-that we should consequently be wary of), and that can't be directly mapped to a bullet point on a
-list of user requirements, but that are nevertheless important and valuable. These things do not
-necessarily provide important functionality, but they contribute to how the user **feels** about the
-application. Their effect may be invisible or subconscious, but that doesn't make them any less
-essential.
-
-
Examples
--------
-Some examples may help (all based on real applications that I have worked on at some point):
+Let me first give a few examples, and then try to extract a pattern from them. They are examples of
+situations where, if you want, you can go to substantial engineering effort in order to make a user
+interface a little bit nicer. (Each example based on a true story!)
* You have an e-commerce site, and need to send out order confirmation emails that explain next
steps to the customer. Those next steps differ depending on availability, the tax status of the
@@ -85,7 +45,8 @@ Some examples may help (all based on real applications that I have worked on at
generated by `if` statements based on the order parameters. So you go and build a natural language
grammar model for constructing emails based on sentence snippets (providing pluralisation,
agreement, declension in languages that have it, etc), in such a way that for any one out of 100
- million possible edge cases, the resulting email is grammatically correct and easy to understand.
+ million possible parameter combinations, the resulting email is grammatically correct and easy to
+ understand.
* You have a multi-step user flow that is used in various different contexts, but ultimatively
achieves the same thing in each context. (For example, [Rapportive](http://rapportive.com/) has
several OAuth flows for connecting your account with various social networks, and there are
@@ -94,7 +55,8 @@ Some examples may help (all based on real applications that I have worked on at
the user feel good, you need to imagine what state their mind was in when they entered the flow,
and customise the images, text and structure of the flow in order to match their goal. This means
you have to keep track of where the user came from, what they were trying to do, and thread that
- context through every step of the flow --- fiddly and time-consuming.
+ context through every step of the flow. This is not fundamentally hard, but it is fiddly,
+ time-consuming and error-prone.
* You have an application that requires some arcane configuration. You could take the stance that
you will give the user a help page and they will have to figure it out from there. Or you could
write a sophisticated auto-configuration tool that inspects the user's environment, analyses
@@ -105,39 +67,92 @@ Some examples may help (all based on real applications that I have worked on at
around that the product "just works".
-Emotional design
-----------------
+What's a user requirement?
+--------------------------
+
+We said above that simplicity is good. However, taking simplicity to an exaggerated extreme, you end
+up with software that does nothing. This implies that there are aspects of software complexity that
+are **essential** to the user's problem that is being solved. (Note that I don't mean complexity of
+the user interface, but complexity of the actual code that implements the solution to the user's
+problem.)
+
+Unfortunately, there is a lot of additional complexity introduced by stuff that is not directly
+visible or useful to users: stuff that is only required to "grease the wheels", for example to make
+legacy components work or to improve performance. Moseley and Marks call this latter type
+**accidental** complexity, and argue that it should be removed or abstracted away as much as
+possible. (Other authors define essential and accidental complexity slightly differently, but the
+exact definition is not important for the purpose of this post.)
+
+This suggests that it is important to understand what **user problem** is being solved, and that's
+where things start getting tricky. When you say that something is essential because it fulfils a
+**user requirement** (as opposed to an implementation constraint or a performance optimisation),
+that presupposes a very utilitarian view of software. It assumes that the user is trying to get a
+job done, and that they are a rational actor. But what if, say, you are taking an emotional approach
+and optimising for **user delight**?
+
+What if the user didn't know they had a problem, but you solve it anyway? If you introduce
+complexity in the system for the sake of making things a little nicer for the user (but without
+providing new core functionality), is that complexity really essential? What if you add a little
+detail that is surprising but delightful?
+
+You can try to reduce an emotional decision down to a rational one --- for example, you can say that
+when a user plays a game, it is solving the user's problem of boredom by providing distraction. Thus
+any feature which substantially contributes towards alleviating boredom may be considered essential.
+Such reductionism can sometimes provide useful angles of insight, but I think a lot would be lost by
+ignoring the emotional angle.
+
+You can state categorically that "great user experience is an essential feature". But what does that
+mean? By itself, that statement is so general that could be used to argue for anything or nothing.
+User experience is subjective. What's preferable for one user may be an annoyance for another user,
+even if both users are in the application's target segment. Sometimes it just comes down to taste or
+fashion. User experience tends to have an emotional angle that makes it hard to fit into a rational
+reasoning framework.
+
+What I am trying to get at: there are things in software that introduce a lot of complexity (and
+that we should consequently be wary of), and that can't be directly mapped to a bullet point on a
+list of user requirements, but that are nevertheless important and valuable. These things do not
+necessarily provide important functionality, but they contribute to how the user **feels** about the
+application. Their effect may be invisible or subconscious, but that doesn't make them any less
+essential.
+
+
+Data-driven vs. emotional design
+--------------------------------
-What these examples have in common: as an application developer, you can choose whether to take on
+Returning to the examples above: as an application developer, you can choose whether to take on
substantial additional complexity in the software in order to simplify or improve the experience for
the user. The increased software complexity actually **reduces** the complexity from the user's
point of view. These examples also illustrate how user experience concerns are not just a matter of
graphic design, but can also have a big impact on how things are engineered.
-The features described above do not contribute to the utility of the software --- in the e-commerce
-example, orders will be fulfilled whether or not the confirmation emails are grammatical. In that
-sense, the complexity is unnecessary. But I would argue that these kind of user experience
+The features described above arguably do not contribute to the utility of the software --- in the
+e-commerce example, orders will be fulfilled whether or not the confirmation emails are grammatical.
+In that sense, the complexity is unnecessary. But I would argue that these kind of user experience
improvements are just as important as the utility of the product, because they determine how users
**feel** about it. And how they feel ultimately determines whether they come back, and thus the
success or failure of the product.
One could even argue that the utility of a product is a subset of its user experience: if the
-software doesn't do the job that it's supposed to, then that's a pretty bad experience, but there
-are many ways to create a bad experience while remaining fully functional from a utilitarian point
-of view.
+software doesn't do the job that it's supposed to, then that's one way of creating a pretty bad
+experience; however, there are also many other ways of creating a bad experience, while remaining
+fully functional from a utilitarian point of view.
-The expression "icing on the cake" usually refers to something that is nice but not essential.
-Maybe the cake fulfils its nutritive purpose perfectly well without icing; maybe the icing would
-even harm its dietary properties. But if most people choose to buy the cake **with** icing, then
-that icing sounds pretty damn essential to me.
+The emotional side of user experience can be a difficult thing for organisations to grapple with,
+because it doesn't easily map to metrics. You can measure things like how long a user stayed on your
+site, how many things they clicked on, conversion rates, funnels, repeat purchase rates, lifetime
+values... but those numbers tell you very little about how happy you made a user. So you can take a
+"data-driven" approach to design decisions and say that a feature is worthwhile if and only if it
+makes the metrics go up --- but I fear that an important side of the story is missed if you go
+solely by the numbers.
Questions
---------
-This is as far as my thinking has got: recognising that it is not just the utility of software, but
-also its user experience, that determines its essential complexity. But that still leaves me with
-some unanswered questions:
+This is as far as my thinking has got: believing that a great user experience is essential for many
+products; and recognising that building a great UX is hard, can require substantial additional
+complexity in engineering, and can be hard to justify in terms of logical arguments and metrics.
+Which leaves me with some unanswered questions:
* Every budget is finite, so you have to prioritise things, and not everything will get done. When
you consider building something that improves user experience without strictly adding utility, it
@@ -152,7 +167,8 @@ some unanswered questions:
be tricky. Emotionally-driven people tend to let emotional choices overrule rational arguments,
and rationally-driven people vice versa. How do you find the healthy middle ground?
* If you're aiming for a minimum viable product in order to test out a market (as opposed to
- improving a mature product), does that change how you prioritise core utility relative to "icing"?
+ improving a mature product), does that change how you prioritise core utility relative to "icing
+ on the cake"?
I suspect that the answers to the questions above are *"it depends"*. More precisely, *"how one
thing is valued relative to another is an aspect of your particular organisation's culture, and
@@ -161,4 +177,5 @@ have your own personal answers for how you decide these things in your own proje
articulate them. But it's difficult --- I don't think hard-and-fast rules have a chance of working
here.
-I'd love to hear your thoughts in the comments below.
+I'd love to hear your thoughts in the comments below. If you liked this post, you can
+[subscribe to email notifications](http://eepurl.com/csJmf) when I write something new :)

0 comments on commit 63da9af

Please sign in to comment.