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:
- You send Aardvark a question via instant message.
- Aardvark then finds people who are online and have the knowledge to answer your question.
- Those people answer your question and send it to Aardvark.
- Aardvark sends the answers to you.
- 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:
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)