The UX of Desire

The Botany of Desire by Michael Pollan gives a compelling perspective on how desirability determines viability and how plant species have thrived by co-evolving with humans. Michael Pollan’s insights are wildly applicable to software User Experience (UX).

Pollan begins with the premise

Design in nature is but a concatenation of accidents, culled by natural selection until the result is so beautiful or effective as to seem a miracle of purpose.

He demonstrates how four plants have survived through adaptation, and have ultimately thrived by capitalizing on human desires and needs:

  • The Apple – exemplifies our desire for sweetness & intoxication (apple jack),
  • The Tulip – exemplifies our desire for beauty,
  • Marijuana – exemplifies our desire for pleasure, and
  • The Potato – exemplifies our need for sustenance.

Human Desire & Software

Facebook grew from an idea in a Harvard dorm room to over 500 million active users in a hand-full of years (cf. Facebook Timeline). My hunch is that Facebook’s popularity is based on its appeal to human behavior and its fulfillment of human desires. That is, by tugging at our narcissism, our curiosity and our instinct to connect with others, Facebook enables us:

  • to know what our friends, and would-be friends, are saying & doing, 
  • to surreptitiously learn more about particular love interests, 
  • to be flirtatious within a socially removed virtual cocoon, or simply 
  • to be noticed.

The Botany of Desire reversed my bias about humans domesticating plants like corn or apples or cotton. Perhaps it was the other way around – could it be that the plants domesticated us? Plants have, at the very least, used humans to co-evolve and thrive.

I now think of my killer app as a “species” co-evolving with humans. Future startup software might well have to be every bit as cunning as a Venus Flytrap. Our software must provide the sensory lures, then deliver on needs. Future apps might well be like successful plants — spawned by and grown by adaptively fulfilling specific human needs in a survival-of-the-fittest environment.

The Lean-Startup approach seems a fitting platform for the evolutionary experimenting that future killer apps might require. Lean-Startup is rooted in the principle of iteratively adapting and refining a business model (i.e., an evolutionary concept), based on proving the viability of features (meeting needs that customers desire).

INot only will killer apps have to provide features and fulfill needs, they will also have to present desire fulfillment in an alluringly positive experience not unlike a flower’s nectar lures and intoxicates a honey bee to better serve the flower’s ongoing reproductive purpose.

The UX of Desire means attracting and delivering (…so beautiful and so effective) as if the life of your app depended on it!

Posthumous Retrospective on Google Wave

By beaching Google Wave little more than a year after heralding the engineering leadership of Lars and Jens Rasmussen at the Google Wave Developer Preview at Google I/O 2009, Google now sets the high water mark for the familiar rapid prototyping mantra

fail early, fail often.

What’s to be learned from the demise of Google Wave?

What is the Google ethos? The Google ethos, lifted from my post Lessons From the Google Rocket, is

  • Have the audacity to be different
  • Maintain a healthy distrust for suits
  • Let data be indicators that trump notions
  • Release early and learn

One demonstrably productive prejudice that pervades Google group-think is

Stuff gets invented by engineers, not hucksters or charlatans.

Google values the engineering method. To an admirable fault, Google pursues an engineering-centric path. Introducing Google Wave inventors Lars and Jens Rasmussen to the Google I/O audience, Google Engineering VP Vic Gundotra extols the Rasmussen brothers’ engineering chops, gushing about the Rasmussens’ previous triumph, Google Maps.

Few companies do more than Google to feed the engineering pig. Google are legendary in engineering circles.

Usability Gets Short Shrift

Unfortunately, product usability at Google gets short shrift. Usability of Google products is often relegated to lipstick on a pig. Google is remiss in dismissing interaction design – usability – as lipstick.

As one who occasionally muses about burning his TV remote in a flaming, ball of confusion effigy, I believe

Usability is as fundamental to any product as any whizz-bang functionality

Google Wave was an engineering triumph – a creative mash-up of tried and tested technologies like XMPP and established web concepts like Wiki. However, usability was never improved. User experience was never demonstrably considered by Google. Most users just didn’t get it.

Perhaps the engineering tent at Google needs to include interaction designers. Why not?

Google could even refer to these insightful creative-types as “usability engineers”. Heck, the folks at Cooper, some of the most talented interaction designers on this hairball, are only 30 miles up the road from the brain trust ensconced at the Googleplex.

As cyber buddy Ergun Çoruh says in RIP Google Wave:

Google Wave was too stressful to use.

What Worked… At the Google Wave Developer Preview held at Google I/O 2009, Google VP Vic Gundotra said, “Frankly we need developers to help us develop this product”.

The strategy to release a half-baked concept to the open source community is laudable. The ink wasn’t dry on the Federation spec when eager developers attended the Google Wave Hack-a-thon in June 2009.

Developers were jazzed to get in the ground floor building. Bullish on the potential uses for Google Wave, I wrote Google Wave and Collaborative Projects and Will Google Wave Overtake Microsoft Groove?. With the advent Story Board for Google Wave, I was hopeful that the Agile community finally had a software tool that helped rather than hindered.

  • Half-Baked Product
What Didn’t Work… For execution metaphors & ease of operation, Google Wave was the TV Remote of collaborative software. It was a pinball waste-land of bells & whistles.

Many of the operational metaphors that make things easy for users to understand were never explored or realized for Google Wave.

Why did Microsoft Bob, an epic product failure, last longer than Google Wave? Perhaps because it used the familiar metaphor of a house with rooms.

Google Wave vs. Google Maps: Google Wave was bereft of metaphors to guide skittish users. One reason Google Maps is wildly successful for inventors Lars and Jens Rasmussen is because online maps have a direct and familiar analog on paper. The Rasmussen brothers didn’t enjoy the same advantage with Google Wave.

  • Half-Baked Product

Google will bake the lessons-learned into future forays into social networking and collaborative apps. Perhaps we’ll see user experience improvements in Google’s upcoming Facebook-killer Google Me?

Value Experience Over Features

As a software developer, it requires vigilance to temper my tendency toward joining feature frenzy. Like you, I like to build features.

My lazy inclination is to forget about asking why or how we justify the new-fangled feature that I’m itching to build.

Features represent our bread and butter, but we are also professionals. We want to be proud of our work.

Since

  • our business partners are utterly, in many cases, clueless;
  • we aspire to be better professionals; and
  • we identify with being craftsmen in the best Alan Cooper-ian sense,

it’s up to us to

Value experience over products & features.

How-To Value Experience?

Be an advocate for users. Politely question what’s motivating improvements. Are improvements driven from hard data or the soft notions of some muckity-muck over in operations? Resist your tendency to join the feature frenzy.

Let yourself be dragged kicking and screaming before you contribute to BAD user experience by layering in Over-Featured Confusion.

Over-Featured Confusion

Case in point of Over-Featured Confusion is LinkedIn’s new and improved Discussions feature.

As soon as LinkedIn released its groups concept, I founded two LinkedIn software groups (i.e., the global Agile .Net Practitioners and the local Twin Cities Software Consultants).

Laudably, LinkedIn has steadily rolled out features that have improved our group experience. Until now…

LinkedIn’s new Discussions feature amounts to a ball of confusion. The most glaring improvement is a horizontal slider bar with options to Like, Pass, Comment or More? as a mashup of blog, news and discussion items scroll past (horizontally).

At best, it’s confusing. At worst, it’s unusable.

  • May I Pass on this colossal FAIL by LinkedIn? No.
  • Did my feedback to LinkedIn about this improvement disappear into a black hole? Probably.

LinkedIn replaced simple & serviceable with confusing & dysfunctional.

Considerations

As design luminary Don Norman says

Forget the complaints against complexity; instead, complain about confusion.

Perhaps it’s excusable to transform something complex into something confusing. But it’s inexcusable to transform something simple, like a discussion board, into something confusing.

Google UX researcher Paul Adams says in his presentation Designing Experiences, Not Products

We need to understand how people think, and what motivates them to behave in certain ways. The best way to do this is to design from the outside in. To observe people in their own environment, probing them so that we understand their behavior. This understanding enables us to design things that are meaningful and valuable to people.

Prepare for Informed Improvisation

Software developers, like many mammals, are sheep-like and slow on the uptake.

We spent the better part of a decade celebrating our avoidance of Big Design Up Front (BDUF).

I jumped on the Agile Software Development hay-wagon. It was

  • liberating, 
  • professionally acceptable, and 
  • socially, much cooler,

to be Agile.

Agilists like me eschewed BDUF. Our approach to design was emergentWe programmed on the fly.

Yes we were faster. Yes we delivered.

In some cases we moved software into production more frequently than the Milkman delivered milk.

The question I ruminate over is

Did we deliver lasting value?  

The cows are still grazing, but I for one, contributed to several steaming cow pies in the name of agile software development.

The voices I respect in our community suggest we’re avoiding the fruits of experience design considerations at our peril. Sorry Milkman, but delivery isn’t everything.

Software Delivery is the milk jug, NOT the experience of gulping cold, fresh milk

There are signs our community is moving beyond the ominous clouds of Deliverence – pun intended – toward reasonable preparation & design discovery.

Building Benches
Design is premeditation. It is never an immutable concept. It is never written in stone. Ideally, my premeditations grow with me into active (perhaps subconscious) meditation during execution whether programming or building benches.

Last weekend I built a cedar bench. Much thought was devoted to who would be sitting on the bench BEFORE I cut wood. I considered comfort and aesthetic appeal. I chose a height of 19″ following simulated user acceptance tests. I made a sketch. I thought about the materials in the context of human contact (choosing naturally rot-resistant cedar over treated lumber).

Our golden retrievers Lucy & Libby seem to be turning their noses up at my handiwork, but my family likes it. I had premeditated design considerations, but allowed myself the freedom to adapt on the fly.  

For me, these up-front considerations, design, or call it what you will, are no more than sound preparation.

Sound Preparation

Sound preparation is not the same as BDUF. I prepare to build something with the tacit understanding I will adapt as the unforeseen emerges.

Sound preparation allows for informed improvisation

Like performers, well-prepared programmers are freer to improvise because preparation considers eventualities – not all eventualities, but some. Preparation frees us to be creative without mucking things up, even if all we start with are a few baseline considerations like

  1. Who’s going to use it?
  2. What do they need?
  3. What do they like or dislike most?

I want to be open to discovery. I want time for up-front user research. I want time to respond to user feedback. I want clear and verifiable benchmarks of value. I want enough information about users and benchmarks of value to allow for informed improvisation once the building commences.

Scrum’s Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that’s good about Scrum (see Anders’ post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent “velocity” when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that

It doesn’t matter how fast we deliver, if we deliver junk.

Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.

In almost all cases I can think of,

the people actually using our software is where the scratch meets the itch. 

Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.

More

Integrating Interaction Design Into Agile Projects

Thanks to advocates in Agile community, many software developers have gotten proficient at delivery. Perhaps now it is time to examine what we’re delivering.

Better questions and attentive listening might avert those occasions where we do an outstanding job of delivering the wrong thing.

Discovery & Delivery

At last week’s last week’s CodeFreeze 2010 on the University of Minnesota campus (my alma mater), speakers David Hussman and Jeff Patton were wearing t-shirts that said Discovery & Delivery.

The authorized theme of CodeFreeze was Redesigning Agility. The unauthorized theme might well have been as David and Jeff’s t-shirts said — Discovery & Delivery.

How do we integrate Interaction Design into our Agile projects?

Looking retrospectively beneath the vaulted glass and wood ceilings of Memorial Hall, where CodeFreeze was hosted, one might conclude that the Agile community deserves kudos for improving our ability to deliver software. One also might conclude that we have yet to make significant progress integrating interaction design and usability into the Agile cookbook.

Interaction design and usability considerations will continue to play a significant role in whether people are satisfied using our products. We had better jump on the design band-wagon, or at least appropriate all the most forward-thinking interactive designers as our own.

Jeff Patton posed the following question to the CodeFreeze audience

If you evaluated the quality of your process based on customer satisfaction, what would that process look like?

Jeff’s question helped solidify an approach I have been considering for months. Three influences on my thinking are:

  1. Google’s slogan of Launch Early and Iterate (see my post Launch Early and Learn);
  2. Eric Ries‘ concept for startups of a Minimum Viable Product; and
  3. At CodeFreeze, watching Alan Cooper talk about Interaction Design and watching David Hussman and Jeff Patton talk about Discovery (e.g., Story Mapping).

I have concocted a recipe for a discovery & delivery process that I am eager to share and to take for a test drive.

User-Driven Rapid Prototyping

Lets call it User-Driven Rapid Prototyping. As the name implies, the approach involves rapid prototyping. It is also user driven because the people who use the application help the software team prioritize the backlog.  The challenge and proposed approach are a follows:

Challenge Integrating Interactive Design into Agile projects
Proposed
Approach
Iterative Cycles of

  • N weeks discovery and 
  • N weeks coding & delivery

The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like

Where

  • The hand palming the spiral is a Discovery or Re-Discovery Iteration
  • The subsequent handless spirals are Delivery Iterations
  • Discovery iterations, after iteration zero, are called Re-Discovery
  • Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).
The software team consists of developers and interaction designers working hand-in-hand. Since the backlog will be now driven by the people using your software, the over-worked and frequently clueless Product Owner we’re familiar with from Scrum, becomes redundant.

Iteration zero –  Iteration zero is a discovery iteration. The goal is to learn as much as is reasonably possible about the community for which you are developing the product. Iteration zero might include chartering, creating personae, and story mapping. Also it might include any of the groundwork you typically lay before iterating in earnest.

Iteration 1 (and Odd Iterations) – Iteration 1 is the first coding and delivery iteration. Iteration 1 might only include some user feedback screens, or a polling mechanism to enable the people using your application to help the team prioritize features, to call out usability snafus, and to bring to light potential design problems. In general, odd-numbered coding/delivery iterations are for adding new features and releasing a deployable prototype. During coding iterations, developers are coding while the interaction designers are working to stay ahead of the coding/delivery curve with ongoing user research and design deliverables.
Iteration 2 (and Even Iterations) – Iteration 2 is the first re-discovery iteration. The re-discovery iteration is a chance for the interaction designers to account for any feedback, then implement course corrections as needed. During this time, developers work with interaction designers to address the feedback, to re-factor code as needed, and to plan the next delivery.

Designers engage in “designing with your hands” which involves making multiple, low-resolution prototypes quickly
~Tim Brown, CEO of IDEO

There is no one-size-fits-all software process. There are conditions that are likely more amenable to the approach proposed here. Greenfield software projects and startup projects might be most suitable. For example, in the evolution of a startup, an ever-improving prototype might be used to attract rounds of investment to fuel continued development phases.

Wouldn’t it be a kick if the picture below could just as easily be the people using your software as the people crafting it?

More…

  • Tim Brown urges designers to think big in this video on Design Thinking.
  • In Usage-Centered User Stories & Story Mapping Part 1 and Part 2, I explain what post-Agilists like Jeff Patton and David Hussman, have been telling the Agile community how we might help teams enrich poorly conceived user stories and how we might better use our iteration zero time for product discovery. That is, how discovery might be improved.

The Missing Link in Google Wave – UI For Primates

The transitional fossil between a transformative concept and a useful tool is probably always going to be the answer to:

Would a primate find it useful?

Okay naysayers, New Caledonian crows are an example of a non-primate clever enough to use a stick to poke food, but the scope here is primates; the nearly hairless apes like you and me.

An amusing poll at EasierToUnderstandThanWave.com asks,

Which is easier to understand?

On the left hand side of the EasierToUnderstandThanWave.com poll, is a screen shot of the Google Wave inbox. On the right hand side, is a sequential series of screen shots of stuff that’s notoriously difficult to understand like:

Google Wave Inbox Notoriously Difficult to Understand
Google Wave Inbox

  • The Geopolitical Climate of Southeast Asia
  • Self-Balancing Binary Search Trees
  • Polymodal Chromaticism
  • The Raison d’être for the Movie The Sandlot 2
  • Mating Habits of the Red-Sided Garter Snake
Having an unfinished thesis on a hopelessly academic model for the flow of two immiscible fluids based on complex analysis, I added:

The 2D analytic manifold of a Riemann surface

to the mix of stuff easier to understand than Wave. The picture (above right) is a butt-simple graphical rendition of the surface of a square root, f(z) = Sqrt(z). To everyone’s dismay, the f(z) in my unpublished thesis took an entire typeset page. No wonder I drop-kicked a PhD fellowship to procreate; mating was the only thing I figured I could do as well as a snow monkey.

Google Wave is a transformative concept. To be fair, the monkey nuts of Google Wave are built on the shoulders of forward thinkers (Ray Ozzie) and well-established technologies and standards (XMPP). But it remains to be seen if humans will find it useful.

Last July I was excited about Wave, after attending the Hackathon at Googleplex with the inimitable Garry Smith. I wrote about Google Wave and Collaborative Projects.

I was talking to everyone who would listen. Now that WikiWikiWeb founder Ward Cunningham thinks Wave is cool, every curious person in the agile community and beyond is clamoring for Wave invitations.

Where’s the Grand Metaphor for Wave?

Primates need metaphors to understand. It is not human hubris to say that humans might need a smaller rock than an orangutan, nonetheless a confused human appears every much as pitiful as a confused orangutan.

Email has a metaphor. Email has snail mail where the internet is a carrier pigeon or IPoAC (IP over Avian Carriers). Instant messaging has the metaphor of Morse Code operators sending and recieving messages. A Wiki has a bulletin board metaphor. Google Wave has nothing. Yet.

Where are the Visual Cues in Wave?

To thrive in complex social interactions, primates form mental maps representing the social hierarchy of thier posse. One of the confusing things about a Wave is the absence of visual hierarchy.

In a Wave, there are no clear relationships between elements in one’s inbox. Every blip carries equal weight. One might issue a mind-bogglingly-profound blip that’s answered by

That’s awesome dude

Both blips carry equal weight to a subsequent participant joining the Wave.

A Wave needs some kind of tag cloud do-hicky, or real-time executive summary. When there’s information overload, humans need a lazy way to

Cull the salient from the slobber

Everyone at Googleplex, Younger and Smarter

I remain steadfastly bullish about Google Wave. Everyone at Googleplex is younger and smarter. The billiards-playing Stanford graduates toiling at Google’s Mountain View sweat shop, and the fledgling community of adopters and gold-miners, are bound to make Wave useful to the masses. But for now, I’ll continue using cotton string and re-purposed cans. tin can phone