Matt Morphett's UX Blog
A sporadically updated set of ramblings on the things that influence - and are influenced by - User Experience (UX).
Friday, 24 June 2011
How to charge $20 for tea - The T2 unboxing experience
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.
Sunday, 11 April 2010
The iPad is a Couch-top device
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.
Friday, 28 August 2009
Men of Usability Calendar - "Mr. April"
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.
Friday, 19 June 2009
Video: Remix 2009
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.
Wednesday, 25 March 2009
Death by Corner Case
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)
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!
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.
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.
Sunday, 1 February 2009
I know.. I know...
Thursday, 15 January 2009
Sometimes there is a good reason to break convention…
Friday, 19 December 2008
How many user experience principles does this example break?
Tuesday, 16 December 2008
Do users need to know why design works to get value from it?
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.