Rob Spiro on Design at The Mechanical Zoo

Last week, I went to BayCHI to see Rob Spiro, one of the founders of The Mechanical Zoo, talk about their product,  Aardvark. Aardvark is a subjective search engine built on the idea that conversations are the best way to get answers to subjective questions.

A typical interaction with Aardvark goes something like this:

  1. You send Aardvark a question via instant message.
  2. Aardvark then finds people who are online and have the knowledge to answer your question.
  3. Those people answer your question and send it to Aardvark.
  4. Aardvark sends the answers to you.
  5. You ask a followup question or just say thanks.

Pretty simple, huh? You might think people would do this more often without Aardvark as the go-between, but as Rob described, there are several reasons why people don’t. The main is that it’s costly, both in terms of time and social capital. It takes a long time to find to right person to ask, and once you find that person you have a limited number of interactions with them before they get annoyed and start ignoring your requests.

Aardvark reduces the cost of these interactions.

It does the heavy lifting of getting the right questions to the right people and lowers the social capital cost by acting as the intermediary and setting expectations regarding asking and answering questions.

Ok, with that background out of the way, I want to highlight a couple interesting points from Rob’s talk.

 

Discoveries made while designing a conversational product

Rob and team learned pretty early on that they needed a controlled vocabulary. They also learned that no one wants to talk to a bot. They needed a vocabulary that didn’t make Aardvark feel like a phone tree or a command line.

They kept Aardvark friendly by using neutral language, in first person present-tense.

Also, through the use of some ingenious, Wizard of Oz-style testing, where they had interns respond to questions as if they were the Aardvark service, they learned that conversational systems work really well for:

  • When you’re new to a topic and don’t know the vocabulary of the topic
  • For social recommendations
  • “Someone must know the answer to this” questions
  • Homework help
  • Local recommendations

 

Research Driven Design Methods

The other really interesting part of Rob’s talk was about The Mechanical Zoo’s design process. It was refreshingly pragmatic and focused on results. Here are my notes:

Rob Spiro talks about TMZ's design process
Rob Spiro talks about TMZ's design process

Identifying user needs
1. Guided in-person interviews
2. Case studies of individual interactions
3. Push suggestion box

Sanity-Check Feature Ideas
4. Wizard-of-Oz simulations
5. Paper prototypes

Assess, Tweak and Polish Features
6. Heavy statistical analysis
7. Remote usability testing – finds it most useful for usability Q/A  (they use usertesting.com)

Additional note: They use agile (see picture)

Congratulations, Humanized!

At this time last year, I was hard at work with a team of extremely talented developers, designing and building the humane computing environment that Jef Raskin described in his book, The Humane Interface.

That project basically fell apart after Jef passed away (for a number of reasons), but some of the developers went on to start a company founded on the principles of humane computing. That company is Humanized.

Today, Humanized released their first product, Enso, which comes in two flavors, Launcher and Words.

Launcher gives you lightening fast, mouse-free access to launching your programs by making use of a quasi-mode that you invoke by pressing the caps lock key. Finally, caps lock does something useful!

Words is invoked in the same way, but is adds a spellcheck that works exactly the same in every program – even programs that don’t have spellcheck built in. Brilliant!

Both of the products do other things as well. I recommend checking out the demos on the Humanized site. You can also download trial versions of both products. You might also want to check out Walt Mossberg’s review of the products.

I’m very proud of what the guys at Humanized have accomplished in less than a year. They’ve carried on Jef Raskin’s work in a practical, accessible way that I’m sure will lead to some exciting innovations in both user interfaces and ways of interacting with your computer.

Side note: Some of the work we did is still available at the Raskin Center for Humane Interfaces website.

Rethinking Designing for Experience

A few months ago, a friend of mine, Todd Wilkens, posted some provocative thoughts on the Adaptive Path blog. Essentially, Todd says:

  1. Instead of a framework focused on tasks, goals, and states, designers should use a framework focused on behaviors, motivations, and contexts.
  2. A new framework is needed because the framework based on tasks, goals, and states doesn’t explicitly account for behaviors, motivations and context. Because of this, it’s difficult to account for those concerns in our designs. That is, we fail to realize certain solutions because our framework for thinking about the problem actually prevents us from considering some solutions.

I agree with Todd. A better understanding of peoples’ behaviors related to, motivations with regard to and contexts of use concerning our designs will lead to better designs.

But why stop there? Why not move even further, toward an integral framework for design? The more considerations we can integrate into our framework for design, the better our resulting solutions should be, yes?

Why not consider an even higher calling? What if, for example, our designs could help people become better people?

Imagine the level of integration into someone’s life your design would need to have for someone to say, “That [service] has my back,” or “My [product] actually cares for me.”

Now, when I say caring, I’m not simply talking about displaying kindness and concern for others. I’m talking about something deeper than that. I’m talking about having a relationship that facilitates self-actualization.

Self-actualization is probably not a word you use every day, but the concept is simple. Self-actualization is the fulfillment of one’s talents and potentialities. Self-actualization is about becoming the best “you” that you can be.

What I’m talking about are designs that are deeply ethical, not only in terms of environmental sustainability and social responsibility, but also in terms of caring.

I think few will argue that this is a bad idea, but all we have so far is an interesting thought experiment. In my mind, there are several important questions that remain:

  1. Can a system be designed such that it can actually have a relationship with a person?
  2. Are the concerns that go into designing such a system really that different from the concerns that go into user-centered design as we practice it today?
  3. In practice, how do we go about understanding these concerns?
  4. What would an integral framework for design look like?

What are your thoughts? Are there other questions I should be answering?

Daniel Kahneman

I was getting ready to go hear this year’s Symbolic Systems Distinguished Speaker talk at Stanford this afternoon, when I discovered that the video from last year’s talk (which I also attended) is online!

Daniel Kahneman’s Symbolic Systems Distinguished Speaker talk (videos are linked near the listing for 2004) was one of the most interesting, thought provoking lectures I’ve ever attended.

Update: I posted my notes from Daniel Kahneman’s talk.

Definitely take a look at the video though. Kahneman reviews his research on how people experience pain. It’s really fascinating and should be relevant for anyone designing those “pain pill” solutions that all the VC’s are looking for.

Design the Cooper way

Kim Goodwin gave a really nice talk entitled, “Getting Your Design Built,” at Cooper world headquarters last night in San Francisco. That’s right, in case you didn’t know, Cooper is now in San Francisco and not Palo Alto.

The most interesting part of the talk for me was her discussion of the process Cooper uses. It goes like this:

Research → Modeling → Requirements Definition → Framework Definition → Design.

Which generally maps to:
Domain → Users → Analysis → Solution → Form & Behavior

Here are the notes I took. Take ’em for what you will.

  • Research (domain)
  • Interviews:
    • Stakeholders
    • Subject matter experts
    • Customers
  • Domain and Literature review
  • Ethnographic user research
  • How this helps with buy-in:
  • Stakeholders help determine interview targets
  • Each stakeholder get private air time
  • Larger team does not participate in interviews, but we gather pictures and stories to share with them
  • We hear about doubts, concerns, and questions early in the process
  • Modeling (users)
  • Requirements Definition (analysis)
  • Identify usage patterns
  • Create & Prioritize
  • Analyze workflows
  • Create context scenarios
  • Determine “requirements”
  • Determine visual messages
  • Deliverable: always a presentation, sometimes a document
  • How this helps with buy-in:
  • Personas are a critical design tool
    • Archetypal users
    • Represent observed behavior patterns
    • Eliminate elastic user
    • Avoid edge cases
  • Conclusions based on actual data, not opinion
  • Presenting this to everyone is the same room lets them:
    • Develop a shared view of users and customers
    • Agree on what problems we are / are not solving
  • Framework Definition (solution)
  • Create high-level sketches of the concept
  • Define major elements and relationships
  • Validate concepts with scenarios
  • Develop visual style studies, if applicable
  • Deliverable: presentation
  • How this helps with buy-in:
  • People can see the big ideas early and get excited
  • Faster than doing incredibly detailed text requirements before drawing any screens
  • Having something to respond to helps bring out more questions and challenges
  • Design (form & behavior)
  • Iterate, refine, & validate using details scenarios
  • Conduct usability testing if desired, once you have detail
  • Collaborate with development team
  • Refine / apply visual design
  • Deliverable: Form and Behavior Specification
  • How this helps with buy-in:
  • Check in with developers (and SMEs) every week or two to make sure your design is feasible within the timeframe
  • Pull stakeholders in if developers resist what you feel are critical aspects of the design
  • When you’re done, everyone sees how the product should look and behave.
  • Development Support (implement)
  • Provide design consultation on implementation priorities and trade-offs
  • Create additional documentation for development team

Comment: Emotions ≠ Experiences

A comment I posted on nundroo™:

“Sorry, but I’m going to nit pick. When you say you can’t design happiness, satisfaction or frustration, you’re talking about not being able to design emotions, and I agree. We can’t design emotions. I also agree that experiences are tied to emotions in that our emotions are the manifestation of our experiences. But dismissing experience design because we can’t design emotions seems unsound. An experience is not equivalent to an emotion, nor is there even a 1:1 relationship between the two.

Now, I’m not saying that experiences can be designed. Lately, my position on whether we can or can not design an experience vacillates daily. The more I read about neuroscience, the more I think we can design an experience…but I digress.

My point here is not to argue for what it should be called, but to help us make sure that, in this time of definition, we are clear with our words.”

Design as Experience Placebo

Randy Dotinga’s Wired.com article, Why Sugar Pills Cure Some Ills, made me wonder if design could be used as an experience placebo?

That is, could a person’s perception that a product, service, object or system has been “designed” have a positive affect on the person’s experience with the product, service, object or system?

This also brings up the question of whether or not design processes will become part of a product’s marketing collateral? Will certain design methodologies or even user-centered (or any other philosophical approaches to) design ever become mainstream enough to be advertised?

Personal shout-out: David Spiegel, who is quoted in the article, runs the Stanford Emotional Coding Lab, at which I volunteer occasionally.

Daniel Kahneman – Intuition: Between Perception and Reasoning

Several weeks ago, I saw Daniel Kahneman speak at Stanford. Daniel Kahneman won the 2002 Nobel Prize in Economics, and is currently the Eugene Higgins Professor of Psychology at Princeton University.

He gave a fascinating talk entitled, “Intuition: Between Perception and Reasoning.” Here are some of my notes from the talk:

A thought I had during the talk: Intuitive interfaces are those that can be used without computation (time to think).

If you keep the mind busy with cognitive tasks (what Kahneman calls System 2 tasks), you can’t simultaneously evaluate your experience.

One rather interesting thing Kahneman suggested was that episodes are recalled (experienced) as an average of the most predominant emotion, not a sum of all emotions. For example, he described a study where patients rated their experience while undergoing a colonoscopy (Redelmeiner and Kahneman, 1996). The results suggested that the episodes were recalled as an average of the pain, not a sum.

Phenomenological Foundations of Cognition, Language, and Computation

CS378: Phenomenological Foundations of Cognition, Language, and Computation

I guess you could say I’m not so much auditing this class as I am reading along. I’m only about 20 pages into the book, but I can’t imagine not recommending it when I’m done – sheer brilliance. It blows me away that Flores and Winograd were thinking about this stuff in 1985!