Matt Morphett's UX Blog

How to charge $20 for tea - The T2 unboxing experience

2011-06-24T16:15:00.001+10:00

I recently purchased and had delivered some tea from Australian tea merchants T2.

These guys have a very deliberately designed web and physical store experience as befits their premium offering.

You can buy any old tea in the supermarket for less than five dollars. These guys charge twenty dollars. How do they do it?

Well, the tea is excellent, no question but they have transcended the product by also selling an experience.

This video documents the well designed T2 unboxing experience from the perspective of a customer.

Matt.

The iPad is a Couch-top device

2010-04-11T07:27:00.003+10:00

I previously suggested that the iPad was best thought of as an eBook reader with extras.

In my opinion, the success or otherwise of the #ipad depends on whether they make books available in the store for normal computers / iPhone12:29 PM Jan 27th from Tweetie
My thinking at the time was that if they released the Apple negotiated books catalogue through a laptop based app or on the iPhone, it could seriously harm the unique value proposition of the iPad. In hindsight, I think I was a little off target. I had considered but, I think, underestimated the value of apps in the context of the the iPad.
Thinking about it a little more (and probably with the benefit of 2 weeks post-launch observation) it seems to me that the iPad is best thought of as a couch-top domestic device.
First: Taking our household as a representative user group (which the UCD-er in me is loath to do) we spend a lot the time we have left (after we spend most of our time working and chasing around our 5 year old) at home between the couch, kitchen, bedroom.
We both have iPhones and we spend a lot of time checking news or blogs, playing games or doing quick updates on Twitter etc. The iphone is great for this in that it is portable but it is a little small for most web browsing. The iPad form factor is ideally suited to just plonking on the couch and quickly checking... "stuff". You don't need to mess around with laptop boot-up times or compromised battery life, just grab the iPad when you have a moment.
There are a couple of other things that suggest Apple was thinking "domestic device" too: 1. Initial models lack 3G.Surely this must be the biggest clue. Apple does not expect that you will be standing up on a crowded bus reading news article or whipping out your iPad to check that movie time as you dash to make the session. Certainly, we wouldn't expect to see it running the maps app on a car dashboard.
3. Only the truly fanatical will carry a laptop, iPhone and iPad in their bagIt is simply too much to carry around and Apple have already priced the iPad as a device for the masses.
4. It is an open niche and Apple is looking for a nicheThe iPad is not designed to replace your laptop. Apple have stated this is a deliberate intention. They are still making good money out of their laptops and would be crazy to cannibalise this market. Furthermore, the virtual keyboard and lying down form factor is simply not appropriate for sustained office work. The keyboard dock is a minor concession here and I suspect it will not be used extensively. Nor does Apple wish to chew into the iPhone market considerably with a lower priced device.
Having said all of this, the iPod and iPhone ended up becoming something much more than Apple ever envisaged so it is likely that the iPad will transcend such restrictive pigeon-holing.
None of this negates the desirability for us by the way - I can see one fitting right in.
...but I wonder if it might become a one-per-household thing as a result. We might consequently see more apps that pair the iPad up with an iPhone for collaborative localised gaming.

Men of Usability Calendar - "Mr. April"

2009-08-28T08:11:00.007+10:00

By popular demand I have posted a picture of Mr. April as seen here in a page from the now extremely rare "Men of Usability" calendar of 1989.

This signed page from the calendar was given away as a prize to a very excited crowd at the inaugural UXAustralia conference 2009.

The small print...
Mr. Nielsen, if you ever stumble across this humble page, I hope that this post appeals to your sense of humor and humility and that you appreciate that it is presented as much with love and respect as it with shameless opportunism. Thank you.

Video: Remix 2009

2009-06-19T11:24:00.008+10:00

Design, Sketching and Sketchflow

http://www.microsoft.com/australia/remix/videos/?vid=v16

This is the video of my talk about designing, sketching, and the new "Sketchflow" tool from the remix conference last week. Sketchflow allows User Experience designers to mock up screen flows and screen wireframes very quickly. You are then able to transition the design to developers for them to do their bit.

You need to set aside about 50 mins to watch the whole thing.

There was a few hundred people in the audience, it ramps up about half way through when I demoed the product and people start clapping (nice crowd!). Overall, it was pretty well received.

Death by Corner Case

2009-03-25T06:23:00.010+10:00

So you’ve assembled an engagingly realistic set of personas, each with unique goals and compelling motivations that reflect the realities of the life of users that you observed through your contextual enquiry work.

Also in response to your site visits, you have worked with business representatives and subject matter experts to draft a number of context scenarios, which effectively illustrate the intersection of future business processes and the future system.
Lets assume that business requirements have been developed in tandem with or before this point so it is fair to say that you and your client is starting to get a pretty good idea of:
- What motivates “the business”
- What motivates your users, and
- How the system might meet the needs of both at a very high level (high level as in; we’re not talking about buttons and drop-downs yet)

Next step is to start to determine what functions might be devised to deliver to point 3 above. This may take the form of functional requirements and if you’re lucky, the business analysts (BAs) are preparing use cases in order to draw these out. Your working closely with the BAs so you have road tested the use cases with your scenarios and - after patching holes in either or both – they line up pretty well.

You start designing screens…
The BAs think it is a little early, so does the business (“but the functional requirements aren’t even finished, how do you know what the screens will look like?!”) but they ease into it once they realise that you know what you are doing and they actually see the system (or at least wireframes thereof) assembling itself before their very eyes.

Everything is going (s)well. You have even designed some novel visualisations of data that will help users get an overview of key information, summarised at a glance – something they have never been able to do before!

…but then, one of your particularly detail–oriented business reps regales the assembled workshop with the one-in-a-million story of the client’s client who -back in 1993 - had three different genders at once and 2,500 case notes on file (when the average is 120 case notes), and who was legally deceased while most of this happened! “Consequently”, he proclaims, “your summary at a glance view won’t always work and should be canned”.
One of the technical BAs mentions a very different but similarly exotic example and before you know it your inspired solution is dying under the weight of a small handful of “corner cases”.
To summarise; you are about to sacrifice functionality that will benefit the overwhelming majority of users almost all the time because there are some very rare examples where it doesn’t work quite as well.

This situation arises for me all the time, literally daily (on some level).

To a certain extent, this kind of reality checking is essential. For example, I spend a lot of time running real data through my mock-ups so that I can see if the design holds up to real world volumes and data types. However, when taken to the extreme, this kind of activity becomes a kind of corner case bounty hunt that pays out in personal (not yours) ego points rather than anything of value for the project, let alone users.
So I have a new approach…
Design for 95% of cases and cater for the remaining 5%.

This means that we spend our time and effort (and requirements budget) making things work really nicely for the large majority of people most of the time and as long as it doesn’t totally stuff things up for the remaining very small minority, we’re good.
So, using the example above, if in the rare case of the multi-gendered, really busy, dead client, the summary screen extends below the scroll break in the web app rather than being summarised up on one screen, I don’t give a damn!

It happened once in 1993 – lets move on. I did a few things in the mid nineties that I’d rather forget too, lets do it together people. Kum Ba Yah.

Print one of these babies out, pop it up on your design wall and gesture at it nonchalantly whenever somebody threatens your project with death by corner case.

Since I raised this issue in workshops a few months back and started asking “How often does that happen?”, things have changed on my project. In a very ironic Pavlovian twist, one of the more vociferous corner-case-assassins recently asked the workshop if we weren’t getting bogged down designing for cases that rarely – if ever - happen. Amazing.

I know.. I know...

2009-02-01T11:26:00.002+10:00

...this is supposed to be a UX blog but this video is just too good to overlook. Even if it is off topic.

It is about maths.

Around 50% of the followers of this blog (i.e. one of you) seem to be user experience people, so this video - with simplified maths concepts aimed at the layperson - will be of benefit to you.

Developers may look away now. There is nothing to see here.

For those of you who aren't completely up-to-speed with the latest developments in computer gaming, this next video is for you...

Sometimes there is a good reason to break convention…

2009-01-15T21:12:00.027+10:00

…often there isn’t.

We stayed with family for a week over Christmas, most of which amounted to a thoroughly enjoyable (and generally usable) experience but there were a couple of niggling things that warrant ranting about.

The place that we were staying in was a reasonably modern house in a small beachside town that is a quiet retiree community 11 months of the year and a whoreishly noisy party machine the other month of the year.

At the house there have been a few minor modifications and renovations since said family moved in a few years back, including replacing some (but not all) of the taps.

So the taps…

We all know how taps work, right? “Lefty loosey, righty tighty” and if you are lucky, the hot is on the left and the cold on the right. A set of conventions that has served us reasonably well for quite some time I would venture.

…Until, that is, somebody decides that it is much “cooler” if taps turn on when we rotate the handles outwards – away from each other – so that they part with a sort of opposing symmetry.

In other words; cold turns on by turning anti clockwise (as per normal) and hot turns on by rotating clockwise.

I am baffled as to why anybody would design taps this way but here are a few possibilities:

1. They think it looks more symmetrical in the marketing brochures when both taps are on and water is gushing forth with luxurious abandon.

2. They think it is some hip throwback to an archaic and outdated “Roman” design that “suggests a refined primitiveness and simplicity” or some such gak.

3. Rather than being forged in the glowing coals of greater utility or usefulness, they think new design is forged in the electric fireplace of novel innovation.

Who cares? Well we all should. It is terribly frustrating to find that an everyday action, that almost relies on muscle memory, can be confounded by a “new” design that offers no apparent advantages over the old... particularly when hot water is involved! It is a very odd feeling to need to think consciously and act gingerly when turning on a tap after using the can. After a week we finally got used to it and then had to unlearn everything when we came back to our house.

Don’t get me wrong, I don’t want to sound like some design conservative. If the new approach advances things significantly, enough to trump an established convention then, I’m all for it, but…

I propose that we scrutinise new approaches to determine if they breach the threshold for superseding old conventions.

Items above and to the left of the threshold would be worth pursuing. Anything else is likely to end up as examples in books by Don Norman (bring on the flamefest about Blu-Ray home cinema geeks).

What is the point...

2009-01-15T19:00:00.003+10:00

How many user experience principles does this example break?

2008-12-19T09:39:00.004+10:00

Important: Keep in mind that this particular machine only issues one type of ticket - a free one hour ticket - which needs to be displayed on the dashboard of your car.

Correct answers (posted in the comments) win a page from the "Usability Gurus Scope Their Guns" calendar from 1995. Page is signed by Mr November (Jakob Nielsen) who appears reclining on a bearskin rug - bare chested - with a brandy balloon in one hand and a list of heuristics in t'other.

Do users need to know why design works to get value from it?

2008-12-16T09:56:00.007+10:00

Watching these workmen this morning, as I sit here waiting for the bus, it strikes me that users don't need to know why a design works to know how or when to use it.

So these guys are working on the road verge, essentially in the bike lane, while traffic whizzes past at morning-rush-hour speed. To make the situation even more dangerous, they are often crouched down low and are located on the crest of a hill.

As is likely dictated in their OH&S policy, they have the witches hats out - and I'm sure they feel slightly more comfortable as a result. But, I'm thinking "They only have a few out. Wouldn't you want to close that bike lane out sooner, like over the other side of the crest?"

Then it strikes me that the physical shape (not to mention colour) of the witches hat allows it to be seen from behind small crests. Being a little over a foot high means that it sticks up above the hill and is more visable from a distance on gently undulating road surfaces.

It could have been designed more cheaply like sports field markers, which are little half spheres, but it seems that the conical shape is, so far, winning the "evolutionary" race in this part of some commercial ecosystem. Incidentally, sports field markets are used on flat surfaces - possibly supporting the hypothesis above.

It is clear that a taller safety marker is safer (in a variety of situations) than a shorter one.

So thinking about all of this, I wonder what the answer would be if you asked these users (the workmen) why these safety markers are shaped so. I didn't have the guts to ask before my bus came but I wouldn't mind betting that one answer would be "So that they are easier to pick up and put down".

This brings me to the fundamental point...

Users don't need to understand every detail of a design rationale to experience its utility or usefulness.

If the first step on the path to designerly enlightenment is realising that you (the designer) are not your user, then maybe the next step is realising that your users are not designers. Not sure what the final step is but these things usually come in threes.

Where to start?

2008-12-15T22:26:00.005+10:00

OK, so I have just returned from OZCHI and I'm all fired about getting this blog up and going. Hopefully it won't amount to shouting into an empty chasm. Then again, if it does, at least it will be a private humiliation.

I'm working with a big government client right now who are in the early stages of requirements analysis for a large project. There are a few ways that we can add value as User Experience Designers at this stage of a large project:

1. We can start our user research. For me, this often takes the form of Contextual Enquiry (watching users in their habitat of use) - an applied variation on the broader ethnographic work pioneered by social scientists.

2. From observations made in the above-mentioned site visits, we may be able to articulate personas - which are richly rendered narrative and pictorial portraits of representative users of the system. These include synthesised details about demographics, attitudes (and importantly) goals and objectives. Goals drive users to perform tasks, and we design functions on the system to allow our users to complete tasks. It is important that we think in terms of goals first as these will be our foundation. Tasks may come and go as we bring the technology (or other solutions such as new business process) into play but the original goal will always remain - unless we see a change in scope.

3. Next we might want to describe some Context Scenarios. These are "Day-in-the-Life" type descriptions of the steps that one (or a number) of our personas might undertake to achieve their goals. Through these scenarios, we imagine how the user might do their work with the system supporting them. Cooper suggest treating the system as though it is magic at this stage. In other words, try not to get too bogged down in the detail of technical implementation. On the other hand, any solutions need to be reasonably feasible within reason. This is where we are really doing the first bits of design at a high level. The scenarios help us test out our functional requirements (e.g. use cases) later and give an indication of major user pathways through the functional areas that are already bubbling up in everybody's minds. In other words, they can help us move towards a picture of a conceptual model and therefore, possibly, a navigation model.

Alan Cooper's About Face 3 has much more excellent detail on theses (and more) important steps in the early stages of requirements analysis

Finally, if all else fails at this early stage of the project, we can act as business analysts and help the team get to a point where we have enough information to begin what we should be doing. A good UX person will have most of the skills required to draw out business requirements as well as user requirements (these two types of requirements are quite different and will be the subject of a subsequent post).