42

Everyone knows that the secret to life, the universe, and everything, is 42.  But what is the question?  I would assert that Happiness is the question.  How do I achieve happiness?  Pay attention, because I'm about to tell you something that can change your life.

Happiness = Perceived Experience - Expectations

Think about it. I can't name one thing where this isn't true. From the inane (changing lanes in traffic) to the existential (what do I want out of my life?), and everywhere in between (keeping our boss happy!), it fits.

Happiness comes from an experience and how we perceive that experience, with a baseline set by our expectations. The higher our expectations, the more difficult it is to be happy with a situation. Lower expectations will result in the same situation being more pleasurable. But it's not just about managing our expectations… it's also about managing our perception of a situation. What details do we notice or ignore, how do we take it all in?

The cake is a lie!

Let's say I got a chocolate cake for my birthday. If I had high expectations (I wanted a 3-layer yellow cake with white frosting and 3 candles delivered as part of a surprise party), then I'm probably unhappy with my chocolate cake. But if I had only expectation of "cake", or even no particular expectation of cake one way or the other, I'm probably pretty happy with my cake. If my expectation was that everyone would forget my birthday and there would be no cake at all, then I was probably delighted by my cake!

Now let's look at the perception of the experience. Did I notice that my friend had a very busy day, and still somehow managed to make time to get my cake ready for me? Wow, what a great friend! I'm delighted with my cake! What about other details of the situation? Maybe my sister is being snarky, and fighting with everyone at the party. If I notice this, even though the cake met my baseline "cake" expectations, I will probably be more unhappy (unless snarky is my sister's default modus operandi, in which case hopefully my expectations were already modulated accordingly).

I stumbled across this idea when reading Steve Seow's work on engineering time, which is around how users perceive duration, timing, and responsiveness. Early in the book, he makes reference to Maister's First Law of Service:

Satisfaction = (Experienced – Expected)
Satisfaction = (Perception – Tolerance)

This got me thinking. We cannot change the reality of situations, which are our experiences. They are what they are. The only thing we have power over is our own thoughts: our perceptions of the experiences, and our expectations for the situation.

I don't mean that happiness comes from lying to oneself about what we really want and need. There is a limit to how much we should--or even can--alter our own internal expectations. All I'm saying is that there are ways of seeing things which alter our perception of an experience, and thus alter the happiness we receive from it.

Look at the learning process, and making mistakes. If our expectation is that we should not make mistakes, then learning will necessarily be a painful experience, because mistakes are a necessary part of learning something new. But if instead of bemoaning our mistakes, we look at them from a different point of view, as something we have overcome which has made us better, stronger, wiser and more knowledgeable, then there is a great deal to be thankful for, and even happy about, in every mistake we make.

Be the Great Unifier: Seeing what's the same

Thanks to Robby Ingebretsen, from whom I stole this picture

One of the most important things we can do as designers is back off to see the entire picture. This kind of holistic, pattern-recognizing thought style is valuable to teams because in the day-to-day push and shove, it’s all too easy to focus too closely on the trees and forget about the forest entirely.

Knowing each of the infinitesimal differences between this object and that is a necessity when it comes to getting a quality product out the door. It is the unavoidable result of the kind of careful, detail-oriented thinking that avoids bugs and creates elegant algorithms.

But switching gears from this detailed thought style can be very difficult. Once we know each of the infinitesimal differences between this object and that, it easily comes to a point where the objects seem COMPLETELY different to us. We forget that the reason these things have to interact, the reasons we learned the differences in the first place, is that they are often fundamentally the same in some way, or at least closely related.

This is where letting our more innately-human style of thinking take over can really pay off. We have to forget everything we know about object A and object B, and look at them in their normal context with fresh eyes. We have to take off our smarty-pants engineer hats, and put on our user hats. What similarities do we see? Do we often want to interact with them in the same way? Do we always want to interact with them in the same way? When are the differences between them important, and when are they not?

If the nature of a thing defines how users interact with it, then seeing the commonalities in disparate objects defines the common language through which both can be manipulated in the same ways.

It’s important that we not forget that the similarities and differences are highly context-dependent. For example, to someone who is concerned primarily about flavor of food, sugar and sugar substitutes are comparable, because they both provide sweetness. But in the context of a natural-foods-only diet, sugar substitutes are no longer an acceptable equivalent.

As always, the context of a situation must come from our users’ goals and mental models.

Taking a minute, an hour, a day, to go through this exercise can do immense good. If we’re thinking too much (read “more than our users”) about the differences, the result will be a clumsy system that doesn’t work intuitively. Our users will have to tell the system about what they want every time they want it, rather than the system understanding implicitly what should be done. But the same result will occur if we’re thinking less than our users about the differences. If our users think two objects are different and we treat them as the same, the user will have to go out of their way once again to tell the system what they really wanted.

Let’s always try to be Baby Bear: not too much, not too little, but just right.

Caring too much, and how to stop

If I had to settle on one thing as my greatest weakness, it would probably be this: I care too much about everything.  Lest you think this is one of those "turning a weakness into a strength," glass-is-half-full, dancing in the rain sentiments, let me explain why this is a bad thing.

Have you ever heard the expression "If everything is important, then nothing is?"  Well to me, darn-near everything is important, both professionally and personally.

I tend to think I'm Wonderwoman: omnipotent, capable of doing anything and everything.  Help you design this task flow?  Sure, no problem.  Design an Information Architecture for an entire new product?  No sweat.  Debate 50 options for the right control to use on this single wizard page?  Of course!  Design a fully-extensible architecture for the next GUI and still achieve all of our other design priorities?  "...What do you mean you don't think I can??"

But where does it end?  I wake up exhausted in the morning, drag my tired butt to work, pump myself full of caffeine to make it through the day, weigh in on any and all of dozens of issues, go home, eat dinner with my husband, and go to bed.  And the next day it starts all over.  I'm too tired to do the housework, too tired to take part in my hobbies, which all gets left for the weekend when I try to cram a week's worth of personal life into 2 short days.

That interest in everything, which makes me so good at what I do, is also my foil.  And I know that I'm not alone.  All over the US, and in my generation especially, there are little girls and boys who grew up being told they could do anything they could dream of.  But the well-intentioned message back-fired: We grew up believing that we could do anything, but we never learned we couldn't do everything.  And frankly, there just aren't enough hours in a lifetime for that.  But in spite of this, we try.  And then we fail.  And that failure is attributed NOT to the rational reason that it's impossible, but to some enigmatic personal failing.  "Clearly, if I was a better person, I would not have failed."  That path is not one that anyone should try to walk.  It doesn't lead anywhere good.

So how do we stop?  Personally, I stop when I feel that something is "enough."  The problem is, very seldom do I instinctively feel that something is "enough".  The UI could always be cleaner, simpler, smoother, more intuitive.  My house could always be neater.  My dogs could always be happier, more well-adjusted.  Thank goodness we don't have any kids yet! ;)

In my work life, at least, I've finally found a "good enough" indicator.  I recently attended a customer-focused design session where the facilitator presented a methodology for prioritizing improvements.  Here's how it works:

1. We start by building a list of the different improvements we're considering
2. Next, we stack-rank them according to customer priority, where #1 is the thing that customers most want, and N is the least craved feature on our list.  This can be a guess, but it really should be based on customer data.
3. Rank them according to current capability:
     1 = Can't be done at all, no way, no how
     2 = Can be done, but only using one of the competitors' products
     3 = Can be done with our product, but not easily. The solution requires a lot of thought and some effort from our customers.
     4 = Can be done with our product, somewhat easily.  This is where customers are beginning to be satisfied with our product.
     ...
    10 = Bliss. Customers are so happy with it, they tell everyone they meet.

Now we plot our features on this chart:

The relative priority we should place on improving any given feature is equal to that feature's horizontal distance from the 45-degree line.  The idea here is to only give priority to those features which will pay off in customer loyalty.  The lower the priority for a given feature, the less the effort will pay off after a certain point.  According to this method, that point is defined by the 45-degree line.

Shown below here is an imaginary example of 9 features that a team might be considering improving for their next version.

1. Plot them on the chart by priority and capability:

2. Measure the distance from the feature point to the 45-degree line:

Now we can see the relative improvement priority for each of these features:

1. Feature 2 - with high priority (2) low capability (3), this feature is 6-points away from the line, which means it will give us the most bang for our investment buck: investing a lot in this feature will make our customers very happy.
2. Feature 3 - still high priority (3), but better capability (5), this feature is only 3 points away from the line, which means that customers won't see as much improvement when we work on it, but they'll likely appreciate the little that they see.
3. Feature 1 - Even though this was the highest priority (1), because it's already such a good experience, customers will not value improvements as much here as in the previous two features.  This one only gets an investment level of 2 points.
4. Feature 9 - This is the lowest priority feature, but customers can't do it at ALL today.  This feature gets a score of 1: don't invest much, but do give it a little.

The rest of the features, 4 - 8, are already satisfactory to users.  In fact, Feature 4 in particular is much better than users care about already!  In the real world, this might be like a cellphone that reads my mind to dial: Am I going to pay more for a phone that can do this, or will I choose the phone that doesn't drop my calls as often?  Personally I'd go with the second phone.  Even though the mind-reading feature is wicked-cool, once the novelty wares off I'm going to get annoyed by those dropped calls.  Ultimately that feature is higher priority to me, because I find the existing dialing experience perfectly fine.

I'm so grateful to have found this algorithm, because it creates a stopping place for me.  For anything I'm weighing in on, I can ask myself, in the scope of ALL of the features that this team is dealing with, where does this rank?  After some gut-reaction, back-of-the-envelope graph plotting, I can tell whether it's worth my time to push on an issue, or to let it go.  And do you know what I've found?  More often than not, I can let it go, giving myself more time for the things that really matter.