While in Moscow, Alan and Chris were interviewed by Igor and Anton Gladkoborodov, who are with edutainment blog Theory and Practice to talk about education and learning in the modern world.

Theory and Practice began the interview with two large questions.

Igor Gladkoborodov: In your blog you write a lot about the specifics of the post-industrial era. The new economy heavily influences all aspects of human life, and now we are entering an era of post-everything. I am most interested in the aspect of education, what can you say about the post-education era?

Anton Gladkoborodov: In the industrialized world, education was reduced mainly to the technology of working with a tool or a machine. Similarly, mental activity was usually reduced to a set of algorithms. Today, we need to raise another kind of worker, one that is more flexible and dynamic. However, modern education does not meet the requirements of modern times; it is still based on the principle of factories. What, in your opinion, needs to be done to education?

It’s a good, long conversation, and if you’re down with the Russian you can read the original at the Theory and Practice website. (Special thanks to our friends at Innova for providing the source translation for us.) Below we’ve excerpted some of the most interesting stuff, and arranged it so we don’t sound as jetlagged and meandering as we actually were.

One team returns from lovely Brasil, while another is off in lovely Japan. As we wrap us this last full week before Thanksgiving, our collective Internet attention was drawn by notions of the future, political wranglings, and thinking deeply about design details.

First, we're keenly interested in Congress's discussions of the Stop Online Piracy Act and the effects it could have on the way people use the Internet.

Author's aside: I personally think it's crazy. It's like legislating the Salem Witch Trials only instead of "witch!" the entertainment industry can scream "piracy!" and squash domains at will. Here's hoping that digital censorship gets nipped right in the bud.

Next, we are proud to post video from Alan's talk at the Commonwealth Club, from September 13th of this year. See clips below with thoughts about education, innovative teams, software alchemy, and the arc of technology. Set aside an hour and sixteen minutes and you can watch the full thing.

We loved reading the "one wish"es that the TED audience had for their computers. (Unsurprising spoiler: Most people wanted computers to be more human.) Thanks to James Patten of Patten Studio for asking the question.

Our mad scientist dreams were kindled with knowledge of Google's secret futures lab dubbed Google X.

So we had loads of fun doing our Halloween personas this year. Seems like a lot of folks enjoyed reading them, too. Being the nerds that we know can sometimes be, we'd like to share a few of the headier thoughts we talked about while going through the exercise.

About the presentation

A few folks asked about this presentation format. Is this really the way we document personas? Can it be this simple? We document them in the ways that work best for our clients, so they take many forms, but yes, this presentation is one we're using lately for an "overview" slide in a presentation deck. Since we want to get the team into an intentional stance when looking at the overview, we like to have a big image that registers as believable. The information contained on the right is the minimum amount of reminders about who they are and what we need to keep in mind as we do goal-directed design: A telling quote, goals listed that embody the voice of the persona, a name, and a role. Of course we had a little fun with the format with Destro and Metansiptah that we might not ordinarily have, but half the fun of this exercise was in picking which rules to break.

About the content

The idea was short and full of promise, but the execution proved more difficult for a number of reasons.

Personas aren't individuals

The first thing that came up was a reminder about the essential nature of personas. When first thinking about which monsters to do, I offered to do Dr. Frankenstein and Igor, but Jenea was sharp enough to catch the mismatch: Personas aren't individuals. They're archetypes that represent large populations. You can't just do Dr. Frankenstein. He's not a persona. He's a...umm...person. So adhering to this principle excluded many monsters we might have done which are individuals. For example, there's only one Creature from the Black Lagoon, so "horrible sea creature" seemed to not fit, even though we <3 the Creature and had a team chomping at the bit to go with him.

Personas are based on research

Personas are best when based on research. Since we couldn't get first-hand research for fictional creatures, we looked to the next best thing: domain research. To do this we looked at web resources (thank you, Wikipedia), a few books from our shelves, and every related movie and story that came to mind. This gave us the range of "individuals" from which we drew. It was, as you can imagine, some fun research.

We try to avoid cartoonishness

That the modeled users were fictional created another problem: How to avoid making them too cartoonish? Yes, we created them for a larf, but we didn't want them to be cereal-box versions of the monsters. Cartoonish personas are much more easily disregarded as design tools or market segments, rather than engaging, intentional agents with real needs and challenges. So we tried to make sure that our vampires weren't "Drac McVampires" whose main goal was to "Zuk your bloot!" but instead had at least a little more realism to them. (The delightful goals for the Zombie Who Looks like an Undead Crispin Glover were a deliberate exception.)

Personas often are created with a target technology in mind

We typically steer goals so that they're useful in the context of the design problem at hand. For instance, everyone (living) has a goal of "Enjoy unhindered breathing" but it's so generic that it's not useful in most contexts. Without a target technology in mind (maybe we'll try that next year) our monster's goals couldn't really lean toward any particular way, and so had to be more about characterization.

Personas have life goals

We distinguish between types of goals, and one category is life goals, which are those things the persona wants to accomplish in his or her lifetime. It proved a little challenging for the undead personas. What is a life goal when there's potentially no end of it in sight?

How do we handle anti-social goals?

One of the most challenging aspects of these spooks and monsters was their clearly anti-social goals. Yes, Alexi in wolf form would want to "rip deep into pulsing viscera" but we as designers certainly don't want to help him do that. Perhaps another article can be devoted to handling this in the real-world, but when thinking about how to help them, we tried hard not to become horrible accomplices. That helped with some of the humor, too, as we obviously dodged the obvious.

Turns out they may be ideal

We were ultimately surprised at some of the promise of these personas. It started as a joke to say that our ghost Juan couldn't touch physical objects, but we realized that we can in fact handle that with gestural and voice input mechanisms. Would Juan be an ideal persona for such an interfaceless system? Or in another example, both Alexi our werewolf and Romulus our sasquatch valued staying out of the public eye. Would they be a useful stand-in for people concerned about the looming threat of ubiquitous surveillance? Of course we wouldn't suggest either for a real client, but designing for the most extremely-constrained persona can sometimes result in the best design.

Hoping you and yours had a happy Halloween!

We're thinkers as part of being designers, and any exercise that gives us a new perspective on the tools and methods we use is a worthwhile one. But our main point in doing this was to have a bit of fun and help celebrate one of our favorite holidays. So now that the holiday is past we can get back to work. And since it's late and dark here in the Cooper offices, we'll just turn back to our computers and...wait. What was that sound?

Cooper teams are jamming on a ton of projects, but it was a rich week with lots of things catching our collective eye.

One team returned from a trip to Russia, where Kendra taught a great course on interaction design practice, followed by Alan and Chris’ speaking at a mini-conference of talented and energetic Muscovite designers. The team reports it is missing its new friends. (привет, y’all!)

We liked the lists from Susan Weinschenk's article The Psychologist’s View of UX Design. We're fond of that elephant story, too.

We both marveled and giggled at Siri, and eagerly read the opinions on them. Two in particular...

• Quoras folk opine about why Siri is important
• TechCrunch talks about what this means to search.

Our artistic imaginations were set on fire with the promise of writeable circuitry. (Way to go, U of I!)

Like you, I’ve been to my share of presentations. I’m that annoying guy near the back who takes a lot of notes during it: jotting down the awesomeness, the nifty sound bytes, the structure, and the ideas it sparks. If the thing is failing, I’ll jot that down, too, and try to suss out the reason to make sure that when I present I don’t make the same mistake.

After years of doing this, I’ve come to group these successes and failures into four big criteria that every conference presentation ought to have. I’m going to share them with you now in the hopes that a) I’m right and b) more presentations will fall into the “awesome” rather than “regrettable” category.

Users use, bosses win, and it's better if we treat users like bosses.

Now I don't mean "boss" in the "supervisor" sense. I mean it in the internet meme sense, which traces its roots to The Lonely Island rap as parodied by Saturday Night Live. (It's SNL, so can be slightly NSFW), and in the sense of someone in charge, confident, and getting things done.

For those who have gone to Black Rock to watch fire or those on the East Coast still dealing with water, here's what went down around Cooper while you were dealing with the elements.

• Opinions are polarized regarding the in-progress Windows Explorer
• We wasted a little time laughing at GifTV
• We enjoyed the design challenges of our second round of "office hours" with the smart health startups at Rock Health.
• Two products for differently-abled people caught our attentions: Sony's augmented reality "subtitle glasses" add subtitles to movies as they're playing so deaf people can enjoy them. Local San Franciscan Steve Hoefer's Tacit glove gives blind people inaudible "sonar."
• The Kno iPad apps made us want to head back to school.
• We've been saying that First Name/Last Name form fields are the wrong way to go for a while now. We're glad to the see the WC3 had our backs.
• We nodded while eating cereal and watching the demo video for the NYT R&D; breakfast table reader.
• We also loved the dashboard on one of Chris Reccardi's illustrations from his Go exhibit in Melbourne.
• We got our last votes in for SXSW 2012 panels (If you're of a mind, consider one of ours.)

Oh hey, know anyone interested in interning with us? Send them our way (or send us to them).

It’s rare, but it sometimes happens. You will be in an interview and you hear something that doesn’t quite ring true. Knowing the warning signs and what to do in these edge cases will help you make course corrections during the interview so that it is still useful.

Screen capture from Rock Star Games' title L.A. Noire

At Cooper, we’re quite fond of pair design as a way to get to the highest quality design quickly. (Even if you have to cheat your way there.) Most of our client engagements involve a pair of interaction designers dedicated to projects full time. Over the years, two specific roles have evolved out of this paired practice.

We struggled to come up with descriptive titles for each of the roles. Though the debate was a tough one, we erred on the side of accuracy at some cost of accessibility, and call the roles generator and synthesizer. (We’re aware that that makes us sound like machines, but with the quality of design teams are able to produce in this way, maybe that’s apt?)

Generator	Synthesizer
The generator is the one whose job is to fearlessly generate design ideas; to walk up to the whiteboard or OneNote page, draw some designs, and say, “OK, here’s how I’m thinking it will work for the persona.” The gen, working with visual design, makes the design solution visual; first with hand drawings, then in illustration software.	The synthesizer is the one whose job is to insightfully keep challenging, improving, and synthesizing the design into a whole. As the “gen” posits ideas, the “synth” will ask questions, help analyze, improve, and iterate it. The synth describes the behavior in words, incorporating the gen’s drawings to create a design specification.
Together they…
…identify and evolve designs, so that the persona using the system we’re designing accomplishes their goals in awesome ways.

Some asides about these distinctions:

1. These roles aren’t cast in stone. Sometimes when the gen is out of ideas, she might hand the pen to the synth so he can draw what he’s thinking, and she’ll “synth” him.
2. We’re experimenting and refining our methods all the time, as with our new integrated product development offering. Not all projects need two interaction designers.
3. Our team structures include additional, invaluable members like visual designers, industrial designers, engagement leads, etc. This article is just about the relationship of paired interaction designers.

This is some heady stuff to explain, whether to our parents, at a cocktail party, or interaction designers applying to work with Cooper. For this reason, we often find ourselves employing metaphors to explain the relationship. Since this is usually when the lightbulb goes off, I thought I would share some of the more effective and engaging ones.

Kia ora. In an earlier blog post, I asked if Kiwis would be interested in a January Cooper U, and despite it being in the “dead zone” of the summer holidays, the answer was an enthusiastic, “Yes!” So, we’re happy to open registration for a Kiwi Cooper U Practicum between 10-13 January.

While there is a lot going on around the holidays with long summers and cross country tramps¹, I thought I'd put the idea out there to see if there is interest. If the course can get enough confirmed registrants by December 1, Cooper will commit to making it happen.

So, if you're in that part of the world, and you're interested, let me know in the comments, or by completing the registration form [PDF].

If we get the numbers, I’ll confirm here on the Journal and directly with registrants. Thanks! (Or, I should say, "Ka pai!")

¹ For non-kiwis, a "tramp" is kiwi for "hike".

I’m going to call it. Apple won on this one.

The whole host of Latin-derived diacritical characters (such as ç, č, & ĉ) are too large to fit into a standard keyboard. The methods by which various operating systems have provided access to them have, in all but one case, sucked.

This sucks. It's hard to access and takes way too much visual hunting, not to mention having to "select" and "copy" the character to the clipboard.

Working with long lists of information over a network, like web email, can be problematic. Very long lists can have a huge performance hit on your servers, leaving the user tapping her fingers waiting on slow page loads, especially on “very thin” clients like mobile devices. To limit the server hit and improve response times, some systems paginate data, that is, break it up into a series of pages.

This works well since most lists can be sorted by smart defaults, and the first page is the one that users most likely want to pay attention to, anyway. In the web email example, you can sort lists of individual emails by date with newest on top, or threads by most recent activity, and be confident that users will find what they’re most often looking for quickly.

But if a user needs to hunt for something, she’s going to need access to other pages, and this article is about how those controls should look and behave.

On a recent project a client confessed some small degree of envy of Cooper’s team structure. He was the sole designer at a medium sized software company doing good work, but unsatisfied doing it alone. In our short project he was able to see the value of paired design and wasn’t looking forward to heading back to business as usual. I’ve got four ideas on what someone can do in this circumstance, but first let me extol the virtues of Paired Design.

Here’s a quick tip for you as you conduct your goal-directed interviews with users and potential users: Leave a four-second pause after your interviewee pauses their response, allowing them to add more information or additional detail.

This is hard to do. In ordinary conversation, people will often step in and fill these silences. Especially with a stranger, we don’t want to leave the conversation “hanging,” preferring instead to offer up some response or reflection on what the other has said.

But an interview is not a cocktail conversation. The interviewer is trying to get as complete a picture as he or she can of the user’s thoughts. To help do this, we want to give them that room to think about what they’ve just said and append as necessary.

One of my favorite scenes in Futurama features a Lucy-Lui-lookalike robot who is programmed to fall in love with the main character, Fry. When she sees him, she purrs, “You’re one sexy man,” and then switches into a harsh monotone to shout, “PHILIP J. FRY”, before jumping in his arms and giving him a kiss. The writers can make this sort of insert-name-here joke because we’re all familiar with this type of communication, mostly from mass mailed form letters and IVR telephone systems that try and composite sentences from prerecorded bits. “If you want to talk to SUZY THOMPSON, press THREE FIVE TWO FIVE…”

Variables in otherwise-static text (like in interfaces) can be good or bad, depending on how you treat them.

It seems that language in software is on the mind of interaction designers. A few bright folks over at UX Matters have thought about whether software should speak to users from a first person or second person perspective. I have been thinking about similar issues after a client recently asked me about whether a piece of software should ever refer to itself. “If we already think about computers as other people, why wouldn’t we?”

What’s he talking about? For those unfamiliar with The Media Equation, in 2003 Stanford professors Reeves and Nass published a series of experiments they conducted which show that humans essentially treat computers as if they were other humans. From Publishers Weekly: 

"People are polite to computers, respond to praise from them and view them as teammates. They like computers with personalities similar to their own, find masculine-sounding computers extroverted, driven and intelligent while they judge feminine-sounding computers knowledgeable about love and relationships."

I'm a Facebook user. I'm also an iPhone user. I'm also a bit lazy about updates. So having the Facebook app on the iPhone seems like a good idea. But there's one interface element in the application that frustrates me and makes me prone to not want to use it at all.

If you use your iPhone to email, you're used to sending it using the SEND control in the upper right hand corner of a message. It's a good place to be for right-handed people, as it's easy for your right thumb to jump right there. I send emails all the time from my phone, so I'm really used to this behavior.

For those who aren’t familiar with South by Southwest, it’s a huge three-track conference that occurs in Austin, Texas each year around mid March. (It’s timed to coincide with UT’s spring break, which makes room for the conventioneers and avoids student-professional brawling.) The first track is music, and lots of bands come and play live, hoping for more fans and maybe a deal from talent scouts. The second track is film, and in addition to a regular set of conference panels and presentations, there is a concurrent film festival going on at the city’s many rockin’ cinemas. The third track is interactive (SxSWi), with conference presentations and a whole lot more.

Many people have seen Marcos Weskamp's brilliant visual design of Newsmap. The site uses the Google News aggregator to rank news stories by popularity across the Web, and then maps them out with the popular items larger, and less popular headlines smaller, all in color-coded categories. Here's a quick screenshot if you haven't seen it, but view it live if you can.

The beauty of the layout is that it allows a user to quickly glance to see what's most popular. But what if you wanted to do the same thing with a set of identically-proportioned graphics? (Like channels of video, CD artwork, or avatar options on a social networking site.) You couldn't use different proportions for the images, as Weskamp does with headlines, without sacrificing the graphics' integrity.

What you could do is use "squared rectangles."

"One free interaction" is a prospective design pattern that gives software and hardware a more humane feel. It exists outside of task flows and the concept of users as task-doers. Instead it sits in the "in between" spaces, suiting users as fidgeters, communicators, and people who play with things.

Snapback pages

When I got my iPhone, I spent time opening up all the applications and playing around. I was keeping an eye open for what new facets of the touchscreen interaction design were fun and useful. When using the Safari web browser, I noticed the funny stretchy-edge pages. Meaning, when you use your finger to scroll above the top of a page or below the bottom of a page, it pulls away from the edge of the browser, revealing a small blank area that sits “behind” the page. When you lift your finger up, the page snaps back into place. It’s kind of hard to describe, so this little video should help.

It was pretty cool, since it provided some visual confirmation of the edges of the page. But honestly I thought it was just a coding oversight. Then I saw it again in the text message page. And again in email menus, and the emails themselves. Nope, I realized, it’s baked into the OS.

I put the feature out of my mind until I found myself fiddling with it. Mulling over an email, or waiting for a text response from someone, I’d sit and idly flick the pages away from the edge just to watch them snap back. Flick-snap. Flick-snap. It was so satisfying, even if it was sort of useless.

Then I started seeing this same pattern in other things.

Numbers abound in interfaces, hopefully delivering a great deal of information. Bigger numbers usually indicate more activity (like when you're looking at comment threads), or more work to do (like when you're looking at your inbox); smaller numbers generally indicate low activity. However, when the number zero must be represented in an interface, it should be treated differently than other values. Why? As I'll show below, "zero" can actually imply a variety of things, depending on its context.

Search results

• Correct term, but no results? You need to find another term or look elsewhere.
• Bad term mis-keyed? You need to supply the correct term.

When the search results are zero, help the user notice the error with attention getting graphic design, and provide options about alternate terms or places to look.

One of the most interesting books we’ve read recently at the informal Cooper Book Club is Bruce Sterling’s Shaping Things

In the book, Sterling extends some salient technosocial trends to construct a prospective new technology he calls a spime. Sterling lauds designers as the only ones capable of making spimes' (arguably) inevitable emergence into something positive and meaningful, and ultimately, save humanity from its current trajectory of self-destruction. (But no pressure.)

In his recent article for TechCrunch, salesforce.com CEO and chairman Marc Benioff frames the web 1.0 revolution as “Anyone can transact” with great 1-to-many online transactional applications like Google and Amazon. The 2.0 revolution was “Anyone can participate” with a host of many-to-many online applications like LiveJournal, Flickr, and YouTube that really put the focus on user-generated content.

Even after you’ve sold them on personas, even after you’ve explained that you want to design for a specific persona first, even after you warned them about the perils of the “elastic user,” you can find yourself hearing things like, “Well, I know this guy who would do it this way...”

To help clients who won't be put off by pop-culture references, I reference the parable of The Homer.

For those who aren’t familiar with the Simpsons episode “Oh Brother, Where Art Thou?” (Season 2, Episode 15), it plays out like this: Homer meets his long lost brother Herb, who happens to head an automobile company. Believing Homer to be the perfect “everyman,” Herb instructs his designers to make exactly the car that Homer wants.

Hey iPhone users, did you know that you have access to special diacritical characters? Neither did I. The bloggers at iSmashphone had to point it out to me in their entry 12 iPhone Tricks You Might Not Have Known.

The way you do it is to press and hold the base character, and the line of diacritical characters appears above. Slide your finger to the correct one and lift up, and now you can properly spell the word háček.

One of the nice things about working with smart people is the conversation. It soars to heights, teleports across topics serendipitously, and can suddenly dive back towards its original target like a bird of prey. As an illustration, one day I slyly documented these topic shifts over a long lunch between myself and two other designers at the company. The results of this exercise are below.

I’ve been entranced with the notion of Slanty Design ever since I read Russell Beale’s article about it in Communications of the ACM in 2007. For those of you who aren’t familiar with it, Slanty Design is kind of anti-affordance, a difficulty-of-use employed to achieve certain design decisions. I think even the acknowledgment of such tools mark a maturity of interaction design: it’s not solely about making things easy to use. (Just, perhaps, mostly?) Unfortunately, the use of slanty design isn’t always to encourage better behavior. Sometimes it’s just greed.

Axel Peemoeller’s wayfinding system for the Melbourne Eureka Tower Carpark has been making the internet rounds. Props to him, it’s a novel and eyecatching design. (See below for one example from his site.) But something about it makes me think it’s disorienting (and possibly dangerous) for drivers. Let me try and articulate my amateur cognitive science/interaction design theory to explain.

While driving, your brain’s 3D systems are in high gear. (Pardon the pun.) Your mind is tuned to look for positioning cues such as occlusion, parallax, and especially size changes. This last is most important, as your visual system is on the lookout for anything that suddenly grows larger than the things around it, which would be a clear sign that you’re about to hit something. It’s called the startle response, and it happens within about 80 milliseconds, far too fast for any rational processing to counteract it.

So now, think of yourself in the Eureka Tower Carpark. Turning a corner, you’re a little confounded by the strange and lovely colored shapes on the wall. What’s going on here? All of a sudden, your visual system puts all these shapes together in a way that could only make sense if there was something (in this case, typography) jumping out right in front of you. Your gut reaction should be to slam on the brakes, even if your logical brain can decipher the thing a few milliseconds later. Hopefully the driver behind you left enough room.

So I haven’t been there, and I don’t know if this conjecture bears out in fact, but the pictures certainly set off my startle reaction.

My team recently completed a set of non-English interviews in Beijing, Moscow, Munich, Paris, Seoul, and Tokyo. To facilitate these meetings, our client arranged translators. Having one was indispensible, but it cost time; and more time than we initially thought.

Have you ever been in a design review where instead of talking about the proposed solution you spend half the time revisiting what the user is trying to accomplish in the first place? Keeping the human-centered models of the processes that lie behind your solution fresh in the minds of stakeholders (and designers) can prevent this unwanted rehashing. One way to ensure this is to create a diagram and give it qualities that make it simple enough and memorable enough so that, on a dime, you can whip out a dry-erase pen and sketch it out as a reminder.

I like to call that collection of qualities whiteboardability. It won't work with extremely complex business processes, but for simpler processes or most consumer domains, it works well.

Goal-Directed Design necessarily involves first-hand research with real-world users. Whether these interviews last 30 minutes or two hours, the first few minutes of discussion are vital to establishing rapport with your participant.

Outside of celebrities and politicians, few people are practiced at giving interviews. And while participants are almost always willing to help as best as they can, there may be some unspoken questions troubling them before an interview begins. This article offers a list of common topics that proactively address these questions and make participants feel at ease.

One piece of advice I have received in my first year here at Cooper is to avoid referring to personas as creations. Of course they are, and everyone knows it, but they work better if we refer to them as if they were real people in the world. For example, the conversation got off track a bit in one client presentation when I said, "We gave Tracy two kids, with one heading off to college…" The discussion went from being about the personas and the design problem to being about why we gave Tracy two kids, and what tweaks might be made to better fit the persona to the client's expectations. Had I instead said something like "Tracy has two children, the older of whom is about to head to college," the conversation likely would have remained on track. Why is that the case?

Most people think of Goal-Directed Design techniques as focused on product design, but they work equally well for services. A service is comprised of the various "touchpoints" between a customer and a business. Touchpoints include public-facing systems such as web sites and web-enabled software, but can include other channels as well, such as brick-and-mortar stores, points of sale, interactive voice response systems, email and postal mail, too.

A service model best fits offerings that are intangible, distributed in space, or play out over a length of time, especially on a routine basis. Some obvious examples include: electricity, hotels, mobile phone service, or even a government. The touchpoints you design as part of your service are critical to the user's understanding of your brand. Increasingly, many touchpoints are interactive systems rather than human contact, so paying careful attention to the design of these things from the user's goals is vital.