Tag: user experience

Summary of my Playful IAs argument

I thought I’d post a short sum­ma­ry of the argu­ment I made in my Euro IA Sum­mit 2007 talk, for those who weren’t there and/or are too lazy to actu­al­ly go through the notes in the slides. The pre­sen­ta­tion is basi­cal­ly bro­ken up into three parts: 

  1. Future web envi­ron­ments are becom­ing so com­plex, they start to show emer­gent prop­er­ties. In this con­text a lot of tra­di­tion­al IA prac­tice does­n’t make sense any­more. Instead of direct­ly design­ing an infor­ma­tion space, you’re bet­ter off design­ing the rules that under­ly the gen­er­a­tive con­struc­tion of such spaces. In oth­er words, IA is becom­ing a sec­ond order design problem.
  2. IAs tend to argue for the val­ue of their designs based sole­ly on how well they sup­port users in achiev­ing their end goals. I pro­pose sup­port­ing expe­ri­ence goals is just as impor­tant. From there I try to make the case that any pow­er­ful expe­ri­ence is a play­ful one, where the user’s fun fol­lows from the feel­ing that he or she is learn­ing new stuff, is kick­ing ass, is in flow.
  3. Game design is not black mag­ic (any­more). In recent years a lot has become under­stood about how games work. They are built up out of game mechan­ics that each fol­low a pat­tern of action, sim­u­la­tion, feed­back and mod­el­ling. Design­ing play­ful IAs means tak­ing care that you encour­age dis­cov­ery, sup­port explo­ration and pro­vide feed­back on mastery.

Get the the slides, and a list of sources for the talk in this ear­li­er post.

Playful IAs — slides for my Euro IA Summit 2007 talk

After a con­sid­er­able amount of fid­dling with SlideShare I’ve final­ly man­aged to upload a ver­sion of the slides that go with my Play­ful IAs pre­sen­ta­tion. This more or less as I pre­sent­ed it at the Euro IA Sum­mit 2007 and includes an approx­i­mate tran­script of my talk. I hope to get an audio/video record­ing of most of it in the near future as well. When I do I’ll update this page.

Update: I’ve post­ed a short sum­ma­ry of the cen­tral argu­ment of my talk.

Down­load a ver­sion includ­ing an approx­i­mate tran­script (14,5 MB).

I had some great reac­tions to this talk and I want to thank all the peo­ple who engaged with me in dis­cus­sions after­wards. It’s giv­en me a good pic­ture of what areas I should devel­op fur­ther in future sub­se­quent talks. I’m also pleas­ant­ly sur­prised to see that con­trary to what some peo­ple think, the IA com­mu­ni­ty (the Euro­pean one at least) is very much open to new ideas. That’s real­ly nice to expe­ri­ence firsthand.

A lot of peo­ple asked for a list of books and oth­er good sources on the top­ics I cov­ered. Here’s an incom­plete list of stuff I’ve used at some stage to inform my thinking:

If that does­n’t keep you busy for a while, you could always have a dig through my del.icio.us links. There’s plen­ty of good stuff there. Of course of if you ever find any­thing you think would be of inter­est to me, do let me know. Just tag it for:kaeru.

Finding playful patterns at dConstruct 2007

Fortune cookie with design wisdom and dConstruct 2007 bag

I did­n’t announce it on this blog, but if you’re fol­low­ing me on Twit­ter or Jaiku, took a look at the Upcom­ing event page or share trips with me on Dopplr you’re prob­a­bly aware that I attend­ed dCon­struct 2007 in Brighton. 

By way of a short con­fer­ence report I’d like to list some of the ref­er­ences to games and play that jumped out at me dur­ing the day. It might be that I’m slow­ly but sure­ly going a lit­tle crazy or that have real­ly dis­cov­ered the secret order of the uni­verse, but either way I was pleas­ant­ly sur­prised that most talks sug­gest­ed that suc­cess­ful expe­ri­ence design ben­e­fits from an under­stand­ing of the dynam­ics of play. Here goes:

  1. Game design is a sec­ond order design prob­lem, mean­ing you can­not direct­ly design the expe­ri­ence of play but only the ‘stuff’ that facil­i­tates it. Jared Spool point­ed out that suc­cess­ful expe­ri­ence design is invis­i­ble, it’s only when it’s done wrong that we notice it. This makes good expe­ri­ence design hard to sell, and I would say the same goes for great game design.
  2. The prac­tice of game design is very much a mul­ti­dis­ci­pli­nary one, with a lot of spe­cial­ties on board. Sim­i­lar­ly, there is no way you’ll be able to do good expe­ri­ence design when you use a relay-race-like pro­ces. You need to have peo­ple from a lot of dif­fer­ent back­grounds solv­ing prob­lems col­lab­o­ra­tive­ly (or a few peo­ple who can do a lot of dif­fer­ent stuff real­ly well.) Jared Spool briefly point­ed this out, Leisa Reichelt gave a lot of good sug­ges­tions on how to facil­i­tate this with wash­ing-machine method­olo­gies and Tom Coates fin­ished his talk encour­ag­ing cross-dis­ci­pli­nary col­lab­o­ra­tion too.
  3. Because good expe­ri­ence design (like game design) is a sec­ond order design prob­lem, and it can only be done mul­ti­dis­ci­pli­nary, you can only do it in an iter­a­tive and incre­men­tal way. Good games get play-test­ed to death to ensure they’re fun, good expe­ri­ences (on the web or wher­ev­er) need the same treat­ment. Leisa Reichelt had some inter­est­ing ideas on how to actu­al­ly pull this off: Intro­duc­ing UX to Agile, by hav­ing design and devel­op­ment teams both work­ing in the same rhythm, but han­dling dif­fer­ent stuff in their own iter­a­tions, with a lot of hand-over and com­mu­ni­ca­tion back and forth. Well worth try­ing out I think.
  4. More thoughts on the invis­i­ble nature of expe­ri­ence was pro­vid­ed by Peter Mer­holz, who used a quote from Tim O’Reil­ly: “Design­ing from the out­side in”. Start with the UI and then fig­ure out the data and log­ic. I would­n’t equate user expe­ri­ence with user inter­face (because — again — the expe­ri­ence can­not be direct­ly designed) but I think it’s a good quote nonethe­less. I liked Mer­holz’s empha­sis on the impor­tance of an expe­ri­ence vision most of all.
  5. I was great to hear Denise Wilton and George Oates talk about B3ta and Flickr. A lot of peo­ple are prob­a­bly aware of the gamey ori­gins of Flickr but it was enlight­en­ing to final­ly see some of it on the big screen. It came as no sur­prise to hear that Ludi­corp’s process in mak­ing Flickr was very much wash­ing-machine style (although they did 0 user test­ing for a long time!)
  6. Matt Webb was per­haps the speak­er who most explic­it­ly drew par­al­lels between game design and expe­ri­ence design. (He men­tioned Raph Koster’s A The­o­ry of Fun, for instance.) He also point­ed out that cus­tomi­sa­tion is vital to any expe­ri­ence, that a prod­uct should be able to recom­bine with oth­ers in its ecosys­tem, as well as allow for per­son­al­i­sa­tion. Both cus­tomi­sa­tion and per­son­al­i­sa­tion encour­age play. Tom Coates lat­er men­tioned some­thing very sim­i­lar — that your prod­uct (which as he was eager to point out is more than just your web­site) should be re-com­bin­able and extend­able with and by others.
  7. One of the major themes in inter­ac­tion and game design for me is behav­iour, the way prod­ucts encour­age behav­iour in their users and the kinds of behav­iours they have embed­ded in them­selves. Matt Webb also men­tioned that peo­ple love to tell sto­ries about the expe­ri­ences they’ve had. This is very true of gam­ing, which is all about verbs, actions, doing stuff. Game design is not sto­ry­telling, the sto­ry­telling hap­pens after the game.
  8. I had com­plete­ly for­got­ten about Dis­co, the CD burn­ing app with sim­u­lat­ed smoke effects that serve no pur­pose besides play. So thanks to Matt Webb I now have an exam­ple to com­ple­ment the Wii Help Cat! (Come to think of it, the dis­cus­sions sur­round­ing Sta­men Design’s Twit­ter Blocks might be anoth­er good one.)

In con­clu­sion, I think it’s great that Clear­left used this year’s edi­tion to intro­duce the web devel­op­ment com­mu­ni­ty to the won­der­ful world of expe­ri­ence design. I was also very hap­py to see a few peo­ple on stage I had not seen present before, but knew had a lot of good stuff to say. The pre- and after-par­ty were both a lot of fun (thanks to Media Tem­ple, Yahoo! Devel­op­er Net­work and the BBC for spon­sor­ing those with free drink and food.) And if you’re curi­ous, I under­stand there will be pod­casts of all the ses­sions online soon, so keep an eye on the site.

Mirroring mental models — games modelling players

Will Wright demoing Spore at TED 2007

Today I sent in the slides of my Euro IA Sum­mit pre­sen­ta­tion for the pro­ceed­ings. The rough out­line of my talk is done, the most impor­tant thing now is to find the prop­er exam­ples to illus­trate all the fuzzy the­o­ret­i­cal think­ing. That means (at least for me) doing a lot of Flickr pho­to search­es. This time I’ll also be exper­i­ment­ing with using some short video-clips. Games are bet­ter seen in motion after all (and best expe­ri­enced through play of course). Chron­i­cling my think­ing on the sub­ject of play­ful IAs on this blog has been very help­ful in organ­is­ing my thoughts by the way, I’ll def­i­nite­ly try it again the next time I need to do a talk.

On mental models

One idea I man­aged to squeeze into the pre­sen­ta­tion in addi­tion to the stuff I’ve been blog­ging about so far is about men­tal mod­els. I think it was Ben Cer­ve­ny who men­tioned in his Reboot 7.0 talk (MP3) that some of the plea­sure of play­ing games is derived from the grad­ual men­tal mod­el build­ing a play­er goes through. The play­er uses the visu­al lay­er of a game to learn about the under­ly­ing struc­tures. When a play­er mas­ters a game, the visu­al lay­er more or less fades away and becomes a sym­bol­ic land­scape through which he manip­u­lates a far rich­er mod­el of the game in his mind.

From a UX per­spec­tive because usu­al­ly when design­ing web sites and apps we try to adhere to exist­ing men­tal mod­els as much as pos­si­ble to pre­vent con­fu­sion and frus­tra­tion. This is a very valid approach of course. How­ev­er, regard­less of how well done the UX design, there will always be some men­tal mod­el­ling on the user’s part. Best make this as engag­ing as pos­si­ble I guess. This, again, is where games come in.

Will Wright acknowl­edges the fact that play­ers build mod­els of a game but he pro­pos­es to take it one step fur­ther. In an old(ish) talk at Accel­er­at­ing Change 2004 he pro­posed the idea that a game can con­struct a mod­el of the play­er as well. Par­al­lels with online rec­om­men­da­tion engines are appar­ent here. As Wright points out, in games (as in web envi­ron­ments) every­thing can be mea­sured. This way, the expe­ri­ence can be tai­lored to a player/user. He’s apply­ing this prin­ci­ple in the upcom­ing Spore, where game con­tent (cre­at­ed by oth­er play­ers) is dynam­i­cal­ly includ­ed based on inferred play­er preferences.

It can be argued that cer­tain web pro­fes­sion­als are way ahead of the games indus­try in this field. Per­haps there are some inter­est­ing oppor­tu­ni­ties for col­lab­o­ra­tion or career moves here?

The experience of playful IAs

Solving a Rubik's Cube

It’s time for a short update on my think­ing about Play­ful IAs (the top­ic of my Euro IA Sum­mit talk). One of the under-served aspects so far is the actu­al user expe­ri­ence of an archi­tec­ture that is playful.

Bri­an Sut­ton-Smith describes a mod­el describ­ing the ways in which games are expe­ri­enced in his book Toys as Cul­ture. I first came across this book in (not sur­pris­ing­ly) Rules of Play. He lists five aspects:

  1. Visu­al scanning
  2. Audi­to­ry discrimination
  3. Motor respons­es
  4. Con­cen­tra­tion
  5. Per­cep­tu­al pat­terns of learning

Of most impor­tance to my sub­ject is the 5th one. 

Game design, like the design of emer­gent IAs is a 2nd order design prob­lem. You can only shape the user’s expe­ri­ence indi­rect­ly. One of the most impor­tant sources of plea­sure for the user is the way you offer feed­back on the ways he or she has explored and dis­cov­ered the infor­ma­tion space. 

Obvi­ous­ly, I’m not say­ing you should make the use of your ser­vice delib­er­ate­ly hard. How­ev­er, what I am say­ing is that if you’re inter­est­ed in offer­ing a play­ful expe­ri­ence on the lev­el of IA, then Sut­ton-Smith’s per­cep­tu­al pat­terns of learn­ing is the best suit­ed expe­ri­en­tial dimension.

Learning about emergence from games

A game of Go

I’m still try­ing to get a grip on why I think games are such a good ref­er­ence point for IAs and IxDs. I’ll try to take anoth­er stab at it in this post. Pre­vi­ous­ly I wrote about how games might be a good way to ‘sell’ algo­rith­mic archi­tec­tures to your client. Even if you’re not active­ly push­ing your clients to adopt ideas such as on-the-fly cre­ation of site nav­i­ga­tion, soon­er or lat­er I’m con­vinced you’ll find your­self con­front­ed with a project where you’re not asked to devel­op a defin­i­tive infor­ma­tion archi­tec­ture. Instead you’ll be charged with the task to come up with mech­a­nisms to gen­er­ate these pro­ce­du­ral­ly. When this is this case, you’re tru­ly fac­ing a sec­ond-order design prob­lem. How can games help here? 

One of the defin­ing char­ac­ter­is­tics of games are their com­plex­i­ty. A few years ago Ben Cer­ve­ny gave a bril­liant talk on play (MP3) at Reboot 7.0 and men­tioned this specif­i­cal­ly — that much of the plea­sure derived from game-play is the result of the play­er com­ing to terms with com­plex pat­terns. This com­plex­i­ty is some­thing dif­fer­ent from pure ran­dom­ness and most cer­tain­ly dif­fer­ent from a ‘mere’ state machine. In oth­er words, games show emergence.

There are many exam­ples of emer­gent sys­tems. The Game of Life springs to mind. This sys­tem isn’t real­ly a game but shows a remark­able rich­ness in pat­terns, despite (or maybe because of) the fact that it is based on a set of decep­tive­ly sim­ple rules (which appar­ent­ly took its cre­ator, John Con­way, over 2 years to per­fect!) The thing is though, The Game of Life is not interactive. 

A won­der­ful exam­ple of a com­plex emer­gent sys­tem that is inter­ac­tive is the real game Go. It has a set of very sim­ple rules, but play­ing it well takes a huge amount of prac­tice. The joy of play­ing Go for me (an absolute begin­ner) is large­ly due to dis­cov­er­ing the many dif­fer­ent per­mu­ta­tions play can go through. 

So get­ting back to my ear­li­er remark: If you’re con­vinced you’ll need to get a bet­ter han­dle on solv­ing the sec­ond-order design prob­lems pre­sent­ed by the design of com­plex emer­gent sys­tems, games are an excel­lent place to start learn­ing. They are emer­gent first and inter­ac­tive sec­ond, the per­fect twin to the web envi­ron­ments we’ll be shap­ing in the future.

UX and the aesthetics of interactivity

Tetris cookies

I’ve been try­ing to reg­u­lar­ly post some thoughts on the top­ic of play­ful IA here. Pre­vi­ous­ly I blogged about how games could be a use­ful frame for think­ing about com­plex algo­rith­mic archi­tec­tures. Last week I post­ed some thoughts on the appli­ca­tion of game mechan­ics in web apps. There, Rahul was kind enough to point me to the fas­ci­nat­ing blog of ‘Danc’ Daniel Cook, titled Lost Gar­den, where there is one post in par­tic­u­lar that res­onates with my own pre-occu­pa­tions lately.

In ‘Short thoughts on games and inter­ac­tion design’ (which hon­est­ly isn’t that short) Danc Cook looks at some of the ways game design tech­niques can be applied to the inter­ac­tion design of web apps. In sum­ma­ry, accord­ing to Danc Cook game design tech­niques allow you to:

  1. Cre­ate an engag­ing expe­ri­ence that goes beyond sim­ply com­plet­ing a task efficiently.
  2. Sup­port free and deep explo­ration and intro­duce and teach new inter­ac­tions that vio­late conventions.

Some things you should­n’t bor­row from games with­out giv­ing it a lot of thought are:

  1. Spa­tial metaphors
  2. Visu­al themes

These are some of the things most peo­ple think of first as char­ac­ter­is­tic of games but real­ly, they are only sur­face, super­fi­cial, not deter­mi­nant of the actu­al inter­ac­tiv­i­ty of the system.

I think one of the great­est argu­ments for a deep­er under­stand­ing of games by inter­ac­tion design­ers, infor­ma­tion archi­tects and oth­er user expe­ri­ence spe­cial­ists is that they are the medi­um that is all about the aes­thet­ics of inter­ac­tiv­i­ty. It is true that they have no util­i­tar­i­an char­ac­ter, they aim to cre­ate a plea­sur­able expe­ri­ence through sys­tems of risks and rewards, restraints and free­doms, nest­ed feed­back loops and on and on. As a UX prac­ti­tion­er, it can nev­er hurt to have a deep appre­ci­a­tion of the aes­thet­ics of the medi­um you work in dai­ly (beyond sim­ply sup­port­ing user goals, or sell­ing prod­uct, or whatever).

Game mechanics in web apps

A while ago there was a dis­cus­sion on the IAI mem­bers list about game mechan­ics on web sites. Andrew Hin­ton point­ed to the Google Image Label­er and LinkedIn’s ‘pro­file com­plete­ness’ sta­tus bar and asked: “Can any­one else think of a use of a game mechan­ic like this to jump-start this kind of activ­i­ty?” (Where “this kind of activ­i­ty” is basi­cal­ly defined as some­thing peo­ple would­n’t nor­mal­ly do for its own sake, like say tag­ging images.)

I was think­ing about this for a while the past week and seem to have end­ed up at the following:

Profile completeness status bar on LinkedIn

On LinkedIn, hav­ing a (more or less com­plete) pro­file pre­sum­ably serves some extrin­sic goal. I mean, by doing so you maybe hope you’ll land a new job more eas­i­ly. By slap­ping a sta­tus bar onto the pro­file that gives feed­back on its com­plete­ness, the assump­tion is that this will stim­u­late you to fill it out. In oth­er words, LinkedIn seems unsure about the pres­ence of extrin­sic moti­va­tions and is intro­duc­ing an intrin­sic one: get­ting a 100% ‘com­plete’ pro­file and as such mak­ing a game (in a very loose sense of the term) out of its pro­fes­sion­al net­work ser­vice. A good idea? I’m not sure… 

Screenshot of Google Image Labeler

On Google Image Label­er, the start­ing point for its design was to come up with a way to have peo­ple add meta-data to images. Google actu­al­ly ‘bought’ the game (orig­i­nal­ly called The ESP Game) from CAPTCHA inven­tor Luis von Ahn, who before that did reCAPTCHA and after went on to cre­ate Peek­a­boom and Phetch. Any­way, in the case of the Image Label­er (con­trary to LinkedIn) there was no real extrin­sic goal to begin with so a game had to be cre­at­ed. Sim­ply hav­ing fun is the only rea­son peo­ple have when labelling images. 

Note that Flickr for instance has found oth­er ways to get peo­ple to tag images. What hap­pened there is (I think) a very nice way of align­ing extrin­sic goals with intrin­sic (fun, game-like) ones.

‘Pure’ games by their very nature have only intrin­sic goals, they are arti­fi­cial and non-util­i­tar­i­an. When you con­sid­er intro­duc­ing game-like mechan­ics into your web site or appli­ca­tion (which pre­sum­ably serves some exter­nal pur­pose, like shar­ing pho­tos) think care­ful­ly about the extrin­sic moti­va­tions your users will have and come up with game-like intrin­sic ones that rein­force these.

Update: Alper fin­ished the LinkedIn pro­file com­plete­ness game and was dis­ap­point­ed to find there is no pot of gold at the end of the rain­bow, mir­ror­ing the expe­ri­ence many play­ers of real games have when fin­ish­ing a game.

Interface design — fifth and final IA Summit 2007 theme

(Here’s the fifth and final post on the 2007 IA Sum­mit. You can find the first one that intro­duces the series and describes the first theme ‘tan­gi­ble’ here, the sec­ond one on ‘social’ here, the third one on ‘web of data’ here and the fourth one on ‘strat­e­gy’ here.)

It might have been the past RIA hype (which accord­ing to Jared Spool has noth­ing to do with web 2.0) but for what­ev­er rea­son, IAs are mov­ing into inter­face ter­ri­to­ry. They’re broad­en­ing their scope to look at how their archi­tec­tures are pre­sent­ed and made usable by users. The inter­est­ing part for me is to see how a dis­ci­pline that has come from tax­onomies, the­sauri and oth­er abstract infor­ma­tion struc­tures approach­es the design of user fac­ing shells for those struc­tures. Are their designs dra­mat­i­cal­ly dif­fer­ent from those cre­at­ed by inter­face design­ers com­ing from a more visu­al domain con­cerned with sur­face? I would say: at least a little… 

I par­tic­u­lar­ly enjoyed Stephen Anderson’s pre­sen­ta­tion on adap­tive inter­faces. He gave many exam­ples of inter­faces that would change accord­ing to user behav­iour, becom­ing more elab­o­rate and explana­to­ry or very min­i­mal and suc­cinct. His main point was to start with a gener­ic inter­face that would be usable by the major­i­ty of users, and then come up with ways to adapt it to dif­fer­ent spe­cif­ic behav­iours. The way in which those adap­ta­tions were deter­mined and doc­u­ment­ed as rules remind­ed me a lot of game design.

Mar­garet Han­ley gave a sol­id talk on the “unsexy side of IA”, name­ly the design of admin­is­tra­tion inter­faces. This typ­i­cal­ly involves com­ing up with a lot of screens with many form fields and con­trols. The inter­faces she cre­at­ed allowed peo­ple to edit data that would nor­mal­ly not be acces­si­ble through a CMS but need­ed edit­ing nonethe­less (prod­uct details for a web shop, for instance). Users are accus­tomed to think­ing in terms of edit­ing pages, not edit­ing data. The trick­i­est bit is to find ways to com­mu­ni­cate how changes made to the data would prop­a­gate through a site and be shown in dif­fer­ent places. There were some inter­est­ing ideas from the audi­ence on this, but no def­i­nite solu­tion was found.

UX designers should get into everyware

I’ve been read­ing Adam Greenfield’s Every­ware on and off and one of the things that it has me won­der­ing the most late­ly is: are UX pro­fes­sion­als mak­ing the move to design for ubiq­ui­tous computing?

There’re sev­er­al places in the book where he explic­it­ly men­tions UX in rela­tion to every­ware. Let’s have a look at the ones I man­aged to retrieve using the book’s trusty index…

On page 14 Green­field writes that with the emer­gence of ubi­comp at the dawn of the new mil­len­ni­um, the user expe­ri­ence com­mu­ni­ty took up the chal­lenge with “vary­ing degrees of enthu­si­asm, scep­ti­cism and crit­i­cal dis­tance”, try­ing to find a “lan­guage of inter­ac­tion suit­ed to a world where infor­ma­tion pro­cess­ing would be every­where in the human environment.” 

So of course the UX com­mu­ni­ty has already start­ed con­sid­er­ing what it means to design for ubi­comp. This stuff is quite dif­fer­ent to inter­net appli­ances and web sites though, as Green­field points out in the­sis 09 (pp.37–39):

“Con­sis­tent­ly elic­it­ing good user expe­ri­ences means account­ing for the phys­i­cal design of the human inter­face, the flow of inter­ac­tion between user and device, and the larg­er con­text in which that inter­ac­tion is embed­ded. In not a sin­gle one of these dimen­sions is the expe­ri­ence of every­ware any­thing like that of per­son­al com­put­ing.” (p.37)

That’s a clear state­ment, on which he elab­o­rates fur­ther on, men­tion­ing that tra­di­tion­al inter­ac­tions are usu­al­ly of a “call-and-response rhythm: user actions fol­lowed by sys­tem events.” Where­as every­ware inter­ac­tions “can’t mean­ing­ful­ly be con­struct­ed as ‘task-dri­ven.’ Nor does any­thing in the inter­play between user and sys­tem […] cor­re­spond with […] infor­ma­tion seek­ing.” (p.38)

So, UX design­ers mov­ing into every­ware have their work cut out for them. This is vir­gin territory:

“[…] it is […] a rad­i­cal­ly new sit­u­a­tion that will require the devel­op­ment over time of a doc­trine and a body of stan­dards and con­ven­tions […]” (p.39)

Now, UX in tra­di­tion­al projects has been prone to what Green­field calls ‘val­ue engi­neer­ing’. Com­mer­cial projects can only be two of these three things: fast, good and cheap. UX would sup­port the sec­ond, but sad­ly it is often sac­ri­ficed for the sake of the oth­er two. Not always though, but this is usu­al­ly depen­dent on who is involved with the project:

“[…] it often takes an unusu­al­ly ded­i­cat­ed, per­sis­tent, and pow­er­ful advo­cate […] to see a high-qual­i­ty design project through to com­ple­tion with every­thing that makes it excel­lent intact. […] the painstak­ing­ly detailed work of ensur­ing a good user expe­ri­ence is fre­quent­ly hard to jus­ti­fy on a short-term ROI basis, and this is why it is often one of the first things to get val­ue-engi­neered out of an extend­ed devel­op­ment process. […] we’ve seen that get­ting every­ware right will be orders of mag­ni­tude more com­pli­cat­ed than achiev­ing accept­able qual­i­ty in a Web site, […] This is not the place for val­ue engi­neers,” (p.166)

So if tra­di­tion­al projects need UX advo­cates on board with con­sid­er­able influ­ence, com­pa­ra­ble to Steve Jobs’s role at Apple, to ensure a descent user expe­ri­ence will it even be pos­si­ble to cre­ate ubiq­ui­tous expe­ri­ences that are enjoy­able to use? If these projects are so com­plex, can they be even got­ten ‘right’ in a com­mer­cial con­text? I’m sor­ry to say I think not…

Design­ers (used broad­ly) will be at the fore­front of decid­ing what every­ware looks like. If you don’t think they will, at least I’m sure they should. They’re not the only ones to deter­mine its shape though, Green­field points out that both reg­u­la­tors and mar­kets have impor­tant parts to play too (pp.172–173):

“[…] the inter­lock­ing influ­ences of design­er, reg­u­la­tor, and mar­ket will be most like­ly to result in ben­e­fi­cial out­comes if these par­ties all treat every­ware as a present real­i­ty, and if the deci­sion mak­ers con­cerned act accord­ing­ly.” (p.173)

Now there’s an inter­est­ing notion. Hav­ing just come back from a pre­mier venue for the UX com­mu­ni­ty to talk about this top­ic, the IA Sum­mit, I’m afraid to say that I didn’t get the impres­sion IAs are tak­ing every­ware seri­ous­ly (yet.) There were no talks real­ly con­cerned with tan­gi­ble, per­va­sive, ubiq­ui­tous or ambi­ent tech­nolo­gies. Some basic fare on mobile web stuff, that’s all. Wor­ry­ing, because as Green­field points out:

“[UX design­ers] will best be able to inter­vene effec­tive­ly if they devel­op appro­pri­ate insights, tools, and method­olo­gies ahead of the actu­al deploy­ment of ubiq­ui­tous sys­tems.” (pp.173–174)

This stuff is real, and it is here. Green­field points to the exis­tence of sys­tems such as Octo­pus in Hong Kong and E‑ZPass in the US. Hon­est­ly, if you think beyond the tools and meth­ods we’ve been using to com­mu­ni­cate our designs, IxDs and IAs are well-equipped to han­dle every­ware. No, you won’t be required to draw wire­frames or sitemaps; but you’ll damn well need to put in a lot of the think­ing design­ers do. And you’ll still need to be able to com­mu­ni­cate those designs. It’s time to get our hands dirty:

“What ful­ly oper­a­tional sys­tems such as Octo­pus and E‑ZPass tell us is that pri­va­cy con­cerns, social impli­ca­tions, eth­i­cal ques­tions, and prac­ti­cal details of the user expe­ri­ence are no longer mat­ters for con­jec­ture or sup­po­si­tion. With ubiq­ui­tous sys­tems avail­able for empir­i­cal enquiry, these things we need to focus on today.” (p.217)

So, to reit­er­ate the ques­tion I start­ed with: are there any UX design­ers out there that have made the switch from web-work to ubi­comp? Any­one con­sid­er­ing it? I’d love to hear about your experiences.