Joe Lamantia.com

Read­ing about the recent release of Social­Text 3 I was struck by the strong par­al­lels between the defin­ing char­ac­ter­is­tics of enter­prise envi­ron­ments in 2003/2004, and the emerg­ing pub­lic Web 2.0 land­scape. The essen­tial char­ac­ter­is­tics of many enter­prise envi­ron­ments are:

• Syn­di­ca­tion: streams of mod­u­lar con­tent and func­tion­al­ity broad­cast widely to sub­scribers within the fire­wall, such as enter­prise data feeds, ERP, BI capa­bil­i­ties, CRM, cus­tom capa­bil­i­ties shared via SOA
• Ser­vices (e.g. envi­ron­men­tal, like the bees we used to have for pol­li­na­tion): iden­tity, secu­rity, pub­li­ca­tion, data man­age­ment, cloud stor­age, imap email, etc.
• Social Struc­tures: tan­gi­ble net­works & com­mu­ni­ties of like-minded peo­ple, ori­ented around a com­mon prac­tice, pur­pose, process, or pain; think of all the matrixed, hor­i­zon­tal org struc­tures and ad-hoc net­works encoded via inter­nal email lists, IM, sprawl­ing intranets, cor­po­rate direc­to­ries, etc.

These same attrib­utes are emerg­ing as the hall­marks of the pub­lic Web 2.0 land­scape. This is how the three S’s man­i­fest for Web 2.0:

• Syn­di­ca­tion: A lit­eral and fig­u­ra­tive tor­rent of con­tent in the form of blogs, RSS, feeds, streams, APIs, for social objects of all types, as well as cat­a­logs of rentable content
• Ser­vices: This layer is grow­ing rapidly for the pub­lic inter­net, with OpenID / OAuth, map­ping, visu­al­iza­tion, backup, cal­en­dar­ing — the list is nearly infi­nite, and still expanding
• Social Struc­tures: The Web (and soon the mobile uni­verse) is pro­foundly social now, and will con­tinue to become ever more so.

I think you can eas­ily see the strong par­al­lels. It’s this sim­i­lar­ity between the older enter­prise envi­ron­ments and the emerg­ing Web 2.0 envi­ron­ment that user expe­ri­ence prac­ti­tion­ers, — and espe­cially any­one prac­tic­ing infor­ma­tion archi­tec­ture — should note.
Why? As I’ve writ­ten before, mod­u­lar­ity is every­where in this new envi­ron­ment, it’s appar­ent at all lay­ers of the infor­ma­tion world, from util­i­ties like pro­cess­ing power, to ser­vices, to the ele­ments that make up the user expe­ri­ence. The effects of mod­u­lar­ity in syn­di­ca­tion, ser­vices, and social struc­tures on devel­op­ers and IT have been pro­found; prac­tices, processes, orga­ni­za­tional struc­tures, and busi­ness mod­els have all shifted in response.
This wave of change first affected the devel­op­ers who build and work directly with code and sys­tems. But inevitably, dis­ci­plines fur­ther up the stack are feel­ing the impact of this shift, though many of us (and I’m putting user expe­ri­ence in this class) may not know it yet.
How will we feel that impact? One obvi­ous way is in the pres­sure to adopt agile and other mod­u­lar prod­uct con­struc­tion prac­tices cre­ated by and for devel­op­ers as the pre­ferred way to struc­ture user expe­ri­ence and design efforts. This is a mis­take that con­fuses the dif­fer­ent stages of soft­ware / dig­i­tal prod­uct cre­ation (as Alan Cooper explained well at Agile2008). Design is not con­struc­tion, and shouldn’t be treated as if it is. And one size fits all does not work when choos­ing the process and toolkit used for cre­at­ing com­plex dig­i­tal prod­ucts, ser­vices, or expe­ri­ences.
One result of this mod­u­lar­ity rules all approach to user expe­ri­ence is the ero­sion of bounded or well-structured design processes that bal­ance risk effec­tively for the var­i­ous stages of design, and were meant to ensure the qual­ity and rel­e­vance of the result­ing prod­ucts and expe­ri­ences. Ero­sion is vis­i­ble the trends toward com­pres­sion or elim­i­na­tion of rec­og­niz­able design con­cept explo­ration and usabil­ity ver­i­fi­ca­tion activ­i­ties in many design meth­ods.
More imme­di­ately — in fact star­ing us right in the face, though I haven’t seen men­tion of it yet in m/any user expe­ri­ence forums — is the grow­ing num­ber of sit­u­a­tions wherein there’s “No designer required”.
Exam­ples of this abound, but just con­sider this fea­ture list for the Social Text 3 Dash­board:

• You decide what matters
• Cre­ate your dash­board in minutes
• Include 3^rd party infor­ma­tion and applications
• Track & attend to what’s most impor­tant to you
• Sta­tus updates flow auto­mat­i­cally, as you work

If that’s not spe­cific enough, here’s what comes out of the box, in the form of pre-built widgets:

• My Con­ver­sa­tions — changes oth­ers have made to any Social­text work­space page you authored, edited, or com­mented on
• My Col­leagues — recent updates made by peo­ple you are sub­scribed to
• Work­spaces — work­spaces you have access to and their activ­ity metrics
• Work­space Page — any page from any of your Social­text workspaces
• RSS Viewer — results of an RSS feed you configure
• Work­space Tags — a tag cloud of all tags in a par­tic­u­lar workspace
• All Peo­ple Tags — a tag cloud of all tags on peo­ple in Social­text People

No archi­tect required for most peo­ple here… and this trend is every­where.
And then there’s the awe­some spec­tre ofcom­modi­ti­za­tion. Lis­ten­ing to a friend describe the con­fus­ing expe­ri­ence of try­ing to select a short list of design firms for inclu­sion in an RFP made the link­age clear to me. I’ll quote Weil’s def­i­n­i­tion of com­modi­ti­za­tion from the paper ref­er­enced above, to make the point explicit.
Please recall that com­modi­ti­za­tion denotes the devel­op­ment of a com­pet­i­tive envi­ron­ment where:

• Prod­uct dif­fer­en­ti­a­tion is very difficult;
• Cus­tomer loy­alty and brand val­ues are low;
• Com­pe­ti­tion is based pri­mar­ily on price; and
• Sus­tain­able advan­tage comes from cost (and some­times qual­ity) leadership.
• Com­modi­ti­za­tion is dri­ven by excess capacity.

Please note that I’m not imply­ing user expe­ri­ence prac­ti­tion­ers face overnight obso­le­tion.
But I am say­ing that I doubt our cur­rent dis­ci­pli­nary world­view and toolkit ade­quately pre­pare us for the real­i­ties of the new envi­ron­ment emerg­ing so rapidly. Code, by con­trast, is and always will be mod­u­lar. (After all, that is the defin­ing attribute of our alpha­bets.)
But user expe­ri­ence is holis­tic, and has to learn to build in its own way from these smaller pieces like a writer com­bin­ing words and phrases. Even­tu­ally, you can cre­ate works of tremen­dous depth, rich­ness, and sophis­ti­ca­tion; think of Ulysses by James Joyce, or the Mahab­harata. These are richly nuanced expe­ri­ences that are the result of work­ing with mod­u­lar ele­ments.
My sug­ges­tion for one response to the oncom­ing wave of mod­u­lar­ity and com­modi­ti­za­tion is to focus our value propo­si­tion in the cre­ation of tools that other peo­ple use to define their indi­vid­ual expe­ri­ences. In other words, shift our pro­fes­sional focus to higher lay­ers of abstrac­tion, and get into the busi­ness of defin­ing and design­ing frame­works, net­works, and sys­tems of expe­ri­ence com­po­nents. Prac­ti­cally, this will mean things like observ­ing and defin­ing the most valu­able pat­terns aris­ing in the use of sys­tems of mod­u­lar ele­ments we design, and then advis­ing on their use to solve prob­lems. This is the direc­tion com­mon within enter­prise envi­ron­ments, and in light of the appear­ance of pub­lic pat­tern libraries (Yahoo’s UI), I think I see it hap­pen­ing within parts of the user expe­ri­ence com­mu­nity. I’m not sure it’s hap­pen­ing fast enough, though.
I hoped to com­mu­ni­cate some of these ideas in my talk on why frame­works are the future (at least for any­one prac­tic­ing Expe­ri­ence Archi­tec­ture) for the 2008 EuroIA Sum­mit that just took place here in lovely Ams­ter­dam. I’ll post the slides shortly. In the mean­time, what do you think? Is user expe­ri­ence ready for the mod­u­lar­ized, enterprise-like envi­ron­ment of Web 2.0? How are you respond­ing to these changes? Is com­modi­ti­za­tion even on your radar?