Design Quest – Interaction Design Day #1

Day One of Cooper’s Interaction Design Practicum had many highlights. Some of the topics covered includes the following ideas, practices & tips:

  • Design Is – Groundwork Definitions
  • Synthesizers and Generators 
  • Pretend It’s Magic
  • Goal-Directed Design
  • Alan Cooper Q&A
  • User Interviews – Guidance & Tips


Design Is…
Cooper managing director of interaction design Doug Lemoine was our practicum leader. Doug established groundwork design definitions.

Design is the conscious and intuitive effort to impose meaningful order.
~ Victor Papanek, Design for the Real World: Human Ecology and Social Change

Good design ensures usefulness. The web-based file hosing service Dropbox is useful. The Segway Personal Transporter, not so much.

Humorous snark about the perceived need and Segway price point from fellow-attendee Matthew:

I wish I had 10 grand to make me even lazier.

In a well-executed design, people delight in simple, intuitive interactions


Synthesizers and Generators

It has been said that Cooper’s secret sauce is to work in design pairs. Cooper pairs consist of a Generator and a Synthesizer. The Generator leads concept creation,while the Synthesizer leads narrative creation.

Generator Synthesizer
  • Good at visualizing systems
  • Versed in usability & IxD principles
  • Responsible for screen sketches
  • Good at narrative, facilitation, and detail
  • Versed in communication and process
  • Responsible for documenting Research & Development

Cooper’s paired design balances generative thinking (what could the product do) and evaluative thinking (what should the product do).

Pretend It’s Magic

One pitfall is thinking about what the system can do at the expense of what the system should do. Edward de Bono‘s Lateral Thinking was presented as a problem-solving technique that uses an indirect, creative approach. Problem solving can follow a practical path, or a magical path (shown below). Often considering the ridiculous, the ludicrous, and the impossible — the magical path — leads to a great idea.

Sometimes a product vision is blurred by a natural tendency to focus on product implementation. That’s when it is time to switch off our internal editor and pretend it’s magic (e.g., what would a magical device do) or pretend the product is human (e.g., what would a human assistant do?)

Goal-Directed Design

Goal-Directed Design considers what should be built before starting to build it. Cooper has observed that goals are stable targets. The supporting example is a cross-country trip. The goals of cross-country trip, whether in 1850 or today, are the same. Cross-country travelers want get there as soon as possible, be as comfortable as possible, and travel safely.

Context, tasks, needs and tools change, but the goal remains the same. For example, air travel can be non-stop where one needs something to read for 5 hours, whereas stage coach travel had 20 stops where one needed something to read for 22 days. With air travel one wants to clear airport security, whereas with stage coach travel one had to be sure to bring a firearm.

A visualization of Cooper’s Goal-Directed Design appeared to be a DNA chain with the following elements:

  • Research – Understanding business and user’s needs.
  • Modeling – Digest the research and build consensus among stakeholders and project team. Modeling of personas and modeling scenarios.
  • Requirements Definition – Define the product experience (i.e., key user goals, functional needs, and emotional needs). Looking for the sweet spot of business goals, user needs, and technical constraints.
  • Framework Definition -A holistic view of the design using scenarios as the foundation. Focus on most appropriate concept.
  • Detailed Design – Design the product in enough detail to prove feasibility. Collaborate with engineers to ensure feasibility.
  • Implementation Support – Ensure the product is built as intended. Advocate and build empathy for the user.
Rinse and repeat!  The process is iterative

Alan Cooper Q&A 

Alan Cooper entertained questions in the afternoon. One of several things Alan said that resonated with the audience involved the conventional title of Software Architect. Cooper feels Software Architect is a misappropriated of term. The role of an interaction designer is more akin to the title Software Architect.

An architect is a person at the nexus of people, purpose, and technology — not someone working in isolation close to the metal. ~Alan Cooper

User Interviews

User interviews are one of the primary methods of acquiring intelligence for the product design. Two approaches found to work are:

  1. One-on-One Interviews – looking for an understanding of user motivations, biases, and concerns;
  2. Conduct Workshops – looking at multiple stakeholders thinking creatively and moving toward a shared vision of the product.
Some fundamental questions discussed for an effective interview:
  • What’s your role?
  • What are the benefits for the business? For you?
  • How will it make money?
  • How do you define success?

Snapshots

View of Bay Bridge from Cooper Reception
Alan Cooper signing my copies of his books

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?

We’re Fast, We’re Not Cheap, But Are We Good?

Using the software term Sprint Velocity, I’ve mistaken Velocity for Speed for several years. Truth is, when I think of a treadmill, I might be confused about Speed too.

Speed and direction define Velocity. On the dashboards the software community is so enamored with, at best, we depict speed. Direction is mysteriously absent without leave (AWOL).

With Direction AWOL…

If you don’t know where you are going, it’s easy to iteratively not get there.
       ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Good at Delivery, But Not-So-Good at Discovery

I have programmed with development teams that range from pretty good to pretty stellar vis-à-vis rapid incremental product delivery. But the products we built could have been better – particularly if we had been better discovering what our user community valued about our software.

The consensus at Code Freeze 2010 and DevJam’s developer Jam Session last night is that few of us have much of a clue about the people trying to accomplish things with our software.

Many projects cling to monitoring speed, but that’s not good enough. It reminds me of lyrics from the Steely Dan tune Babylon Sisters.

Well I should know by now
That it’s just a spasm
Like a Sunday in T.J.
That it’s cheap, but it’s not free

It doesn’t matter how fast we deliver if we deliver junk. Are there ways to measure quality? The Interaction Design community says so.

My Pet Product

I am laser focussed on a pet product. I want to experiment with giving my future user community a place at the table in iteration planning. I want my future user community to help us prioritize the product backlog.

I want to be abundantly transparent to them that their suggestions are acted upon and not ignored.

The cheapest and most direct measures of quality I have considered for this particular product are

  • How many community members can we enroll? 
  • How active are they? 
  • How long can we retain them?

Enrollment, Activity, and Retainment are the legs of this product’s stool.

Averting Usability Calamity Software

Can Usability Calamity Software – you know who you are – be averted by paying better attention to users?

What would the measures of quality be for your pet product?

Credit Due

Most of the observations I make about software these days –

the notable exception being giving the user community a hand in prioritizing incremental improvements

have been adapted, or stolen verbatim, from the folks on my software luminaries list. The gist of this post is derived from things David Hussman has said (and I probably mis-understood).

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.