I'll be live blogging this session initially, and then going back to add some reflection and notes, so if you're reading this Thursday morning, please check back in the afternoon or evening for updates.
Pop Quiz: Which is better: (A) "This company kicks ass" or (B) "This product kicks ass." For example, is a better predictor of success someone raving about an author or a book?
We're having an argument here at the table as to which is correct. We're thinking she may go for (C) a cult of personality or voice.
Ah! I'm correct! Secret answer (C) is correct: "I kick ass!"
This definitely makes sense in the context of courses and professors and universities. When debating whether or not to take a course, students seem to talk most about who is teaching the class.
How can companies elicit first-person language, and create experiences that cause first-person language to happen? It's all about the USER kicking ass.
Next question: What did (do) you want to be really, really good at?
For me: hoo boy, that's a tough one. Maybe being a novelist? Following through on playing the French horn? The consensus at this table is: music. I'm apparently sitting between two aspiring electric guitarists. (Men!)
Question: how can you help people be their best at whatever it is they want to be or do? Sierra calls this "The High-Res User Experience." She throws out the idea of tossing out the marketing department in favor of educators. (Hear, hear!)
Half Dome: she sees a big rock. Her husband, a rock climber, sees handholds. Sierra sees death.
Jazz: Experienced listeners hear more notes.
In programming language, Sierra's wine expertise is one bit: red or white.
Being better is better.
No one is passionate about things they suck at.
The point of software development is to move people from inability to ability relatively quickly. Need to move users to a steeper learning curve--but not necessarily with making it feel harder. (Great graph--photo (hopefully) coming later this evening.)
But it's not about the tools we build. It's about what our tools let them do. Not understanding that is reflected in things like technical manuals. Markting materials before people buy a camera are slick, glossy, beautiful, communicative. The manuals (after they buy the camera) is plain, dull, black and white, confusing. Marketing materials: Taking killer photos. Manual: About the camera.
People want to take awesome photos, not learn to use the camera. So, let's help them get really good at something.
I'm thinking about what this means not just for students, but to museum visitors. Museum visitors want to have an enjoyable experience and maybe learning something. Museum exhibits have learning objectives. Where do the two meet?
Mind and brain are in epic battle. Mind is civilized, brain is primal.
Brain is filtering everything that comes at it, trying to decide what gets through. Answer: not much. Brain is devoted to not writing things to long-term memory. We need to work against that.
Example: Students studying, cramming--they don't retain much, even when they're motivated to learn.
So what does the brain pay attention to? Chemistry--that which it feels. So if we can evoke a feeling, the brain thinks it must be important. Reading textbooks is an emotional flatline.
The brain pays attention to weird things. (Example: fortune cookie that says "You will die a horrible death.") We look at faces, at bodies in a moment of thrill or excitement (e.g. watching extreme sports), cute animals (no one in this room awwww'd at the photo of the baby, but at least half the room awwww'd at the photo of a puppy).
Our brains are tuned to look at things and say, "Look, that's not resolved." There are so many cheap tricks to get people to pay attention to say what's the story.
There are lots of things the brain doesn't care about. The smiley, happy, computer-using person holding a tablet PC: "Yeah, not so much," says the brain. Same thing with photos of teachers standing in front of a screen.
Brain doesn't care about code. So it's important to visualize. So put a face with a code. Wake up the brain, increase attention and memory, but then you risk it being about the wrong thing: e.g., that face looks exactly like my ex-girlfriend.
So. . . Provoke with designs, including ones that might be painful and nauseating (Sierra uses an example of a UML diagram for programmers).
Conversation beats formal lecture and tone. Collaborative learning is far more effective in problem-solving.
Important: Talk to the brain, not the mind.
Example: Trick the brain: code is like a tiger.
10 ways to help users kick ass.
1. Focus on what the USER does, not what YOU do. (Technical writers write a book focusing on the quality of the book. To make the great technical book, however, might mean putting in a lot of topics that aren't serving the user. Focus instead on the user experience rather than on every little thing the product does. Someone needs to kick ass as a result of this. Don't build a better [x], build a better [user of x]. Not how do we build a better camera--how do we build a better photographer,
Again, thinking about the museum visitor. Here, it would be "Don't build a better museum. Build a better visitor." But that isn't specific enough. I know how to improve museum experiences, offline and on, but I'm not sure how to make a better visitor. It's similar, I suppose, to helping students learn to ask good questions.
2. Give then superpowers, quickly. The company Electric Rain's mission: The "user must do something cool within 30 minutes."
3. Make them smarter. What makes you feel smarter? Technical field folks say brain training, brain games, puzzles--but they only help a little. Aerobic exercise actually improves the brain's exercise more. Stand up and stand on one leg: You just got smarter.
We tried this: academics and technologists are an unbalanced bunch. Time to market balance boards to these users?
Improving your balance helps you get smarter because your brain is using extra cycles trying to keep you balanced. Your brain lets other things get by its filter as a result. Any kind of learning materials and experience should focus on patching cognitive leaks.
4. Don't focus on [X], rather ask what [X] is a subset of. What is the cooler thing that your product helps your user do--meaning cooler than what your competition does?
In an age of university budget cuts, I've been thinking about which departments and units will survive. Unfortunately, there's now not just the usual competition for campus funds between, for a hypothetical example, technocultural studies programs and sustainable ag programs. Which young program will (should) survive, if budget priorities are such that small programs must be cut? It may come down to how much cooler your products or services to students are than other departments or units.
Our teaching center, for example, is under the same vice provost as the internship and career center, two honors programs, summer sessions, and more. When budget cuts get deep enough that units need to be eliminated, what evidence can we provide that the teaching center's programs are cooler? Yes, we have stats on users, but documenting cultural change on campus is harder--how have we enriched undergraduate and faculty life in different (and better) ways than our (usually sister, now competitor) units?
5. Shrink the 10,000 hours it takes to really master something. There are ways to shrink that. Two ways: learn the patterns and shorten the duration. Help your users figure out the patterns. Help users do their 10,000 hours in a shorter period of time. Learn do do knowledge acquisition and representation. Bruce Wilcox is a really substantial player in the artificial intelligence world. He didn't know how to play the game of Go. No computers can beat even a marginally good Go player. But Bruce Wilcox decided to make a software program for Go. So he went out to interview Go players. In the process of doing so, he became a master Go player in record time--because he was looking for rules he could represent in software. So how can we extract those bit of knowledge?
Always be practicing. Sierra wants to practice without wearing out her horses. So she took a dressage saddle and now uses it as her office chair. She had to build a custom desk to match its height. . .
(BTW, I heart dressage. Haven't done it for years--too busy with a 3-year-old--but it's a really excellent form of exercise.)
So: create a culture of practice. We expect musicians and dancers and athletes to practice. In certain domains, we expect that of course they'll practice--doing something that is meant for nothing other than practice. But software developers don't have a culture of just practicing. (Do college faculty?)
After 1-2 years, experience is a poor predictor of performance/expertise. (10 years vs. 1 year repeated 10 times) Tiger Woods pop quiz: ow much practice time on his strengths versus weaknesses: 80% practicing his strengths. Offer exercises, games, contests, tutorials that support deliberate practice of the Right Things.
For example, with the horses, if you want to improve one of their gaits, you don't simply canter a lot--because you build in bad muscle memory. So you change gaits frequently, and it's a miracle--the change that needs to happens, happens.
6. Make your product (or docs) reflect their feelings
If we want people to have a better RTFM, we need to give them a better FM. Help and FAQs are not helpful because they are written for the intellectually curious, who would like to know a little more. Users are actually really frustrated.
"Letting them off the hook" is the killer app. Don't let them feel like idiots.
How you make them feel about themselves drives how they feel about YOU. (Think: students.)
7. Create a culture of support.
Hero's journey: Needs helpful sidekicks and mentor.
Look at user community. Look at terms of service from Javaranch: "be nice." Militarily enforced.
Biggest problem for communities: How do you get them to answer and ask questions? Sierra will always think about communities as groups where people get together for learning and support, not as places where people just hang out for fun.
First rule: No dumb questions. People have to feel comfortable asking questions. It's too easy to say "Duh, search the archives of this forum." Same thing in classroom: The prof already covered that, do the reading, etc.
More important rule: No dumb answers. It could just mean having a couple of documents very visible: here's how to answer a question. Get people to consider what it means to really answer a question. In a community, the faster you convert people from askers to answerers, the faster that community is going to grow. (Same thing in classroom--but getting students to learn to ask questions can be tough.)
8. Do not insist on "inclusivity." Because passionate users talk differently--they have jargon and shorthand. It's nice not to have to explain everything--conversations get richer faster.
Measuring community success. Success = more users thinking fast.
9. Make the right thing easy, wrong thing difficult. Horse trainer's advice. Not always easy to implement. For example, for getting fit: treadmill gathering cobwebs. It's not in the corner because you don't use it; you don't use it because it's in the corner. Make it so that you'll literally trip over it if you don't use it.
10. Total immersion jams. 16 hours over two days vs. 16 hours over two months. Frequency matters. Especially important for creativity breakthroughts. Example: Ad Lib from the Game Development Society. So they get together and write entire games over the weekend instead of going through the typical extended development process. The games must be finished over the weekend--even if it's crappy. An add-on: the developers must share the CDs they listened to as they were designing the game.
Quote from 48-hour film jam site: "The surest way to guarantee nothing interesting happens is to assume you know exactly how to do it."
Closing thought: Be brave.
Update: A day later, I'm still thinking about Sierra's talk, and I'm stuck on one piece: In what ways are college students "users"? Part of me is uncomfortable with the idea of students as users--after all, if we're not careful, "users" = "consumers," and it seems that in much of Sierra's talk the two merged. I prefer not to think of students as consumers, but rather as participants. In that sense, Sierra's consideration of growing user participation and expertise on online forums like JavaRanch is closer to what I want to accomplish in the classroom.