According to Jared Spool, design is best when it’s invisible. Just like air conditioning. People only notice it when it’s not working, or too hot, or too cold. No one ever mentions how great the air conditioning is when it’s working perfectly. Microinteractions work in a similar way.

Do you think about the ringer on your phone and the ability to turn it off? Dan Saffer uses this example to kick off his book Microinteractions. Silencing the ringer on your phone is a common feature. If that feature is clunky or hard to find it interferes with needing to silence it quickly, in a crowded movie theatre for example. These tiny interactions that surround the main functionality are integral to rounding out the entire experience.

Microinteractions work best when you don’t think about them. If your product or experience is riddled with minor annoyances it detracts from the overall functionality. But effortless and elegant microinteractions allow for a streamlined experience.

Dan will be presenting one of 8 daylong workshops at the User Interface 18 conference in Boston, October 21-23. For more information, visit uiconf.com.

Recorded: May, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello there. Thanks for joining us again on the SpoolCast. Today is going to be a fabulous day. You’ve chosen the right podcast to listen to today because we have with us Mr. Dan Saffer, who is one of the brilliant designers over at Smart Design. He just came out with a fabulous new book called “Microinteractions.” We’re going to talk about microinteractions today.

He is also teaching a workshop at the User Interface 18 Conference, which is going to be October 21st to 23rd in Boston. He’s speaking on the 23rd, a full day of designing microinteractions. I’m very excited about the workshop and the new book and talking to Dan today. Hi, Dan.

Dan Saffer: Hello, Jared. Glad to be here.

Jared: Thank you for joining us. This is just so awesome. What is this microinteractions thing that you speak of here?

Dan: What is microinteraction? Microinteractions are the small pieces of functionality that exist around or sometimes in place of larger features. The example that I give and I start the book off with is turning the ringer off on your phone.

Nobody is buying your phone because you can turn the ringer off, but it’s still this little important piece of functionality that if it’s not there can cause a lot of problems. People, if they’re struggling to find it, will return the phone. There are all these little pieces of things that can be really important to the overall user experience of your product.

Jared: It’s an interesting thing, that ringer-off button. I remember having generations of phones that didn’t have that. You would discover in the middle of a movie that you hadn’t turned off your ringer and have to dig the phone out and struggle and find the software menu.

Even on my iPhone, I’ve noticed that a lot of people don’t know that if you press the lower-volume button or the little button on the top when a phone is ringing, it actually makes it quiet. You just have to find that button and press it. You don’t have to do anything else but a lot of people don’t know that, so they fumble with the screen.

Dan: Right. That’s it’s own microinteraction right there. It’s another little piece of functionality. It has what I call in the book these invisible triggers. It’s something that you may never discover, ever. How do you make that a little more discoverable or at least learnable? How do you latch onto something like that? How did you find that out, just by trial and error or was it something that you read online. Did someone mention, “Oh, you could do this.”

Jared: I don’t know. I think a lot of these are what I’ve been calling, “Socially transmitted functionality.” You find out, it’s drag and drop. You find out about it. You’re sitting there are you’re watching somebody.

I was watching somebody I was working with work a keynote. We were working on a presentation together. She just grabbed from the little color palette. She just grabbed the color and dragged it over to a word that was in the keynote slide and dropped it.

Suddenly, the word changed into that color. I’m like, “Whoa, whoa, whoa, what did you just do?” We had this sudden “Oh, my gosh, I didn’t know you could do that” thing.

Dan: There’s all, God, my phone is just chock full of those kinds of things. Your operating system is full of all those kinds of things. I mean, they’re just everywhere. It’s “Wait, I didn’t know that.” Socially transmitted is a funny way to put it, but yes.

Jared: I remember having, years and years and years ago, someone gave me one of these Casio watches that had 16 different functions. It had a built in thermometer and barometer, all these crazy things but it only had four buttons.

You had to know the right magic sequence of buttons. Of course, none of the buttons were labeled. There’s a button on the top left. There’s a button on the bottom left, a button on the top right, a button on the bottom right.

You had to find the right sequence to do anything. It was really overloaded, in terms of its functionality. I’m going to guess that a lot of micro interactions live in the land of overloaded functionality.

Dan: I think that’s probably true. As you were talking, I was remember back the little strips that you would put on your computer keyboards that you would remember, “Oh, this is what F9 does.” All those kinds of crazy things.

Jared: You know the craziness still happens. I’ve been working in Google Docs or as I like to call it, “The Land of Never Finding Your Document.” I notice that they now have keyboard shortcuts for bullets and numbers, but the keyboard shortcut is command shift seven for numbered lists.

For bullet lists, it’s command shift eight. I’m like, “How the hell am I going to remember that?” I have to move my mouse over the thing to get the tip, only to, “Well my mouse is already there. I might as well just click on it.”

Dan: There you go. [laughs]

Jared: Let’s go back to the buttons. Microinteractions isn’t limited purely to just buttons, right? It’s gestures and mouse movements and it’s even things that the device does on its own.

Dan: There are two ways that any kind of microinteraction gets triggered. One is a manual way where you are pushing a button, clicking on something, waving or a voice command, or any of those physical ways that you’re doing things. The other way is a more system-initiated trigger, where a certain set of conditions are met. When I get near my Nest thermostat, it has a proximity sensor. It turns on and shows me what the temperature is.

Some of the examples I give in the book are when you’re reading on Instapaper on your phone you start to tilt the phone, but then you jerk it back really fast because you don’t want it to change the orientation of the text. It pops up this little thing that says, “Do you want to keep the rotation lock on there?” You’re like, “Sure. Yeah, I do want to do that because I’m reading on the subway or whatever it is.”

It’s these really great little moments like, “I didn’t have to go search through settings to go find that. It intuited what I really needed at that moment. That set of conditions happened, and it popped up the micro-interaction that could use right there. I really love it.”

Jared: That’s one that works well. The one that I find that’s very amusing is, every so often I look at my phone and it says, “Nothing to undo. Cancel.” I guess on the iPhone there’s an undo function for typing, which is shaking your phone, but nobody knows that. Every so often, my phone will shake. Like, I’ll take it out of my pocket. It will have gotten into that mode, and it will say there’s nothing to undo.

Dan: Depending on what you’re doing, shake can also be shuffle. That’s another one. I forget. One of the new Google apps, it might be the new Gmail app, if you shake it really hard, it thinks that you’re angry at it, and it brings up a thing that says, “Do you want to send feedback?” I think that’s really funny. “You damn phone.” It pops up this little thing.

Sometimes it depends on what app you’re in or what mode you’re in, what’s the trigger in that particular thing.

Jared: In this day and age, anybody who’s doing any sort of app, whether it’s desktop or mobile or even just building some content-related stuff, there are microinteractions involved in that.

Dan: There are microinteractions involved in every product. The question is whether you’re actually going to spend the time and care to make them the best that they can be. In my opinion, you’re only as good as your worst microinteraction. Your product can live or die based on the microinteractions that you have with it. There’s a lot of things that are completely undifferentiated, but if you have some really nice microinteractions around it, that makes all the difference in the world.

An obvious example is your operating system. Most operating systems are doing the exact same things. You can launch applications. You can put things in a folder. You can do blah-blah-blah. How all those things work is all about people focusing on the microinteractions inside the operating system. The same is true with your phones. Both Android and iOS and Windows phone, they all take calls. They all take texts, but it’s all about the microinteractions of the operating systems on those devices that really differentiate one from the other.

Jared: If I’m developing, let’s say, an online banking thing — I’m working on paying bills and stuff like that — do I have to worry about the microinteractions, or is that all taken care of by the operating system?

Dan: No, no. Let’s start with the most basic microinteraction. There are things like logging in, choosing A password, even just what happens when you launch the app. What happens when you’re pressing on/off? How does it power up? What happens that first moment that it turns on?

There’s this great app, Waze, which is a navigation app. When I turn it on, it launches a microinteraction that says, “It’s 6:00. Are you going home now?” This is at night when I leave my office and I turn it on. It doesn’t start from zero. It knows something about me. It knows something about my use of the app and can offer me choices based on what I’m already doing. In this case, all I was doing was turning it on at a particular time. It launched this little system trigger. “Oh, it’s 6:00. You’re at your office. You’re probably going home.”

I think those are the kinds of things that no matter…You could be working a financial services app. When I launch this app, if every time I launched this app and I go to check my account and transfer money, maybe after a couple times, that should be a default thing that pops up and says, “Hey, are you trying to do this? Is this something that you might be interested in doing?”

It’s those moments when it’s like, “Wow! Somebody thought about me, thought about my needs, about what I was going to use this for and what I do use this for,” that I think really makes a lot of customer loyalty. It makes people really love your product and really want to use it, even if they’re doing something “boring” like financial services or that kind of thing. It makes people really appreciate your product because it feels designed. It feels like somebody cares about my needs and my use of this thing.

I think no matter what you’re working on, paying attention to the microinteractions is always going to improve your product.

Jared: I think that there are some things to that. I recently signed up for the Starbucks app. I got myself a Starbucks prepaid online card. Now I can go into the Starbucks, and I can just hold up my phone. It has a little barcode. They scan it, and they charge it against my card. It’s a fabulous way to basically pee through money.

The thing about it is that it has this neat interaction, but the first time it happened it startled me a little. You can tell it which Starbucks are your favorite Starbucks. When you go near them, it reminds you that you’re there, but more importantly…

Like, I always get something at the airport before I get on the airplane. It reminds me that I’m at terminal B at Logan Airport. When I click on the reminder — this is while my phone is off — t gives me this reminder thing while the phone is in the dark state. When I press on it, it then automatically brings up the gift card thing. I haven’t logged in. I haven’t had to put in my password, but at that Starbucks, I can just scan my card without having to press 15 keys. That’s really sweet.

Dan: That’s ingenious of them to get you so easily to spend money.

Jared: Well, that’s Starbucks’ number one superpower.

Dan: For sure.

Jared: OK, I get this microinteractions thing. It feels to me like this is one of those things where our design processes aren’t very good at making sure we’ve got our bases covered here, and that when all these cool microinteractions we’ve talked about happen, it’s almost accidental in the process. It’s like, “Wouldn’t it be cool if…?” It doesn’t feel to me like we have a good way of making sure that we are tracking all the microinteractions and, more importantly, that we are not putting in clumsy, awful microinteractions and not realizing it.

Dan: Right. When I started thinking about this and writing about it and doing the book, as I stated to think about all the standard microinteractions there are, turning things on and off, logging in, changing your password, adjusting a setting, all those kind of things, I was like, “Oh my god! These are the things that we ignore until the very last minute.”

It’s like, “Oh, right. We need to wait for people to log in to get you things.” I think they are often really overlooked. In some cases, that’s OK. In some cases, you can deal with a dull login screen, for instance. It may not kill you. But in some cases, it can be really detrimental. If I can’t log in, it doesn’t matter how great your feature is. I’ll never get to it.

We forget about what’s dismissively called “product hygiene.” People just expect it to be there. But I think that, particularly when you actually take care and do and look at this stuff…

What I’m trying to do with the book is give people a model to start looking at these particular things and saying, “This little piece of functionality has got these four parts. Maybe if I turn the dial on one of these pieces of it, I can make it a lot more interesting.”

That was what I was trying to do, was make a model so that you can look at, “Hey, there’s this icon sitting at the top of my laptop. It’s dull when I click on it. It pops up this little thing. It’s just sitting there. It’s blah. That would be the first thing that people engage with every day with my app. Maybe there’s something better that I can do with it. What is it that could make that more interesting, more valuable to the people who are using it?” They are these things that, because they can be so easily overlooked, they often are.

A lot of people have talked to me. “How do I get time to do this?” It does take some extra time. One of the reasons I wrote the book and tried to say, “All these things that you’re doing? They’re microinteractions. We’ll start calling them that name,” although people have been using the word “microinteractions” for many, many years. If you’re able to say, “Here’s this thing that I want to spend a little bit of time on” — really, they don’t take that much time — then you improve your product.

I was laughing. We were doing a project here at Smart Design a couple weeks ago. It’s for video calling. There’s a little privacy thing so you could turn off the video part of your call and just have it be voice or have it be muted. We came up with this little microinteraction. When you go private, a little shade pulls down over your little avatar picture of the video.

Jared: Oh, nice.

Dan: It took us a couple hours to come up with this thing. We showed it to the client. Literally, it was like we had reinvented sliced bread. They loved it because it took something that…You could’ve just grayed it out or something like that, but just by making it a little bit more interesting, it became like, “Wow, this is something we could sell. This is something that our marketing team will like.”

This is something we call a signature moment for you. If you do these microinteractions really well, they can become part of the brand. They start becoming part of the product. People expect it to be there in future iterations of your product or if you take your product to another platform, they expect it to be there.

Jared: The other day, I was flying on Southwest Airlines. I got up to the front of the line. You can hear the tone that the scanner makes when they scan a boarding pass to check in someone. It’s the exact same tone that’s in their commercials. They have apparently trademarked the tone that they use for checking in. They now use it in their marketing. When you’re standing in line to get on the plane, you hear it 60 times for all the passengers before you, so it becomes this thing. It’s very distinctive.

Dan: Yeah, I know. It’s a complete, what they call, earcon. It’s a really great thing. There was the article that came out this week about Facebook. The new Facebook sound is actually the notes F, A, C, E, like a F major seventh chord, or something like that.

Jared: Oh, really.

Dan: They are trying to make a little signature moment out of that little sound, and Facebook is the king of this. The “Like” button is an amazing microinteraction that is such a signature moment for them.

If they came out with a product that didn’t have a “Like” button. You would think it was broken. You’d think, “What are they doing? Why did they get rid of the “Like” button?”

We’re seeing this now with Microsoft, with the Start button. They launched the new Windows without the “Start” button, and people are like, “This isn’t a Windows product. Where is the Start button. Where is that thing that I turn to all the time?”

Jared: Yeah. Just this week, they’ve put it back in.

Dan: Exactly. They’re like, “OK. We give up. You can have the Start button back.”

Jared: Yeah. That’s very funny that it’s there.

Dan: One last one, which I like, because I can tell the joke about it is that “You’ve got mail.” That has lasted longer than AOL has lasted. I mean, that was such a signature moment for them, that they made a movie out of it. It’s such the thing.

Jared: Yeah. The video conferencing thing you mentioned reminded me, back in the day, I worked on one of the first PC video conferencing systems. We were doing usability testing on people, and most people had never ever used video conferencing before. They had only ever seen it in science fiction movies, so it was really foreign to them.

We did all these prototypes. In the prototypes, you would start the connection up and the person you were talking to would immediately appear, and you’d immediately appear. We found that this freaked people out. They didn’t like the idea that they were instantly broadcasting.

What it was they needed a moment to get ready, and the way we fixed it was we had an intermediate state. You would say, “OK. I want a video conference.” The first thing it would do is it would put up a window with your picture in it, so you could see yourself.

This was actually technically really hard to do, because we were running these things on 386 processors. Showing the video from my camera, and then showing the other side was computationally difficult. We had to come up with a way of making sure that we didn’t make it look clumsy, because of the hardware constraints, but at the same time put this up.

We found that if we just for a few moments let them see themselves, so they could adjust their hair and make some comment about, “Oh, this is not a good day for me,” and then connect to the other person, then that was suddenly OK.

It was interesting, because we had modeled the whole connection after a phone call, but you don’t preview your phone call. We needed this new thing that never existed before.

Now when you fire up FaceTime on an Apple device for example, you get that. You get a moment while it’s dialing of seeing yourself, to adjust yourself. It’s a little mirror of what is going to be transmitted, and then the other side connects and it’s right there.

That all started with the design we had, but this was like a new social convention that we had to put into what we thought was a pretty well-established social protocol of how you make a call to somebody. We had to add this new thing, because we needed this new microinteraction.

Dan: Exactly. In the book I make the case that the history of technology and the history of microinteractions are all intertwined, like as technology changes, the microinteractions around them have to adjust, or improve, or get enhanced based on the changing technology.

I mean, if you look at things that we think of that are totally basic now like the scroll bar, how that has changed in the last 40 years from something that is super primitive, that only you could scroll like one line at a time to now scroll bars that disappear and that are super thin, because they only appear in using your finger for them, just stuff like that.

The micro-interactions have totally changed as the technology is changing. So things like the video call is a great example. Here is something that people are coming to with different expectations, because it is new technology. We are not aware of them, until we start to play with them. Sometimes they need these little microinteractions around them to help manage them and to help make us feel secure in how they work.

Here’s a great one; it’s checking your teeth or something before you go out on a date or something like that, or you are seeing someone for the first time, or something like that.

Jared: Yeah. It’s interesting that the technology sort of demands these little pieces of attention. Of course, one of cases where it is really annoying is filling out one of those forms where it only wants to give you one error message at a time.

You press the button to do the thing, and it says, “Oh, wait. You haven’t put in your birth date.” You go, and you put in your birth date, and say, “OK. Is that done?” It says, “Oh, no. No. You haven’t put in the security code.” “Well, OK. I am going to put in the security code.” “Well, no. You didn’t do the CAPTCHA right.” It’s like, “Can’t you just tell me everything up front?”

Each of those loops through the validation system, those error messages and stuff, that’s a microinteraction, and it’s really annoying.

Dan: Oh, sure. Any situation where you may encounter some kind of error is almost always some kind of microinteraction, and figuring out like ways to either prevent that from happening.

I talk a lot in the book about preventing human error or preventing ways for your system to be abused either accidentally or on purpose by users. I think those are important moments. When things do get messed up is also a great time for your product to show a little bit of personality.

Error message and stuff are a great way to convey, “Hey. We are human. Something bad happened. Let’s figure out to fix this together, and let’s be reasonable about this.” I think that errors in particular are really great places for microinteractions.

Jared: Yeah. Just doing clever things like saying, “OK. So you didn’t put in your birthday. Maybe in the error message box, I’ll give you a way to put in the birthday.” Just not make it feel like, “Oh, you were stupid. You filled out the form wrong,” but “Hey. I just need one more thing. I need that birthday from you.”

Dan: Exactly. Instead of making you like, “OK. Now I have to go back and scroll through the entire form again looking for that. What’s the thing that I didn’t do?” It makes you feel like an idiot.

Jared: This is really cool. In the workshop that you’re giving at UI18, you’re going to go through the framework, and you’re going to help people understand how they hone in on this stuff, and really make sure that their applications and their designs have the right micro-interactions.

Dan: The framework has got four parts, and basically the workshop is divided up into four main chunks. The first thing we do is talk about the triggers, which we touched on here. How do you design manual and system triggers? Trying to figure out what the user behavior is there that could cause triggers to happen.

Then we go into the rules where we figure out: What are the rules of the system? Have you played this microinteraction? What are ways that we can make the rules so that errors don’t happen, or so that things are more streamlined and more efficient?

Then in the afternoon, we talk about feedback. We get deep into everything from visual feedback and some animation, even some talk about writing microcopy. How do we write microcopy in a way that is really polished and that really speaks human, so that human beings can actually respond to it.

Then the last bit is all about that kind of loops and modes, which make up the meta part of microinteractions.

Then at the end of the day, we put everything together and design a couple of sample ones, and make sure that everything that you have learned the entire day is all put together so that when you leave, you can immediately go back to your desk and think about the model, and really just dig down and start polishing the microinteractions wherever you find them, and in doing so, making your product something that is really interesting and that people love, and not just tolerate.

Jared: That sounds fabulous. I am really excited about the workshop. I can’t wait to attend it.

This has been great. Thank you for taking the time to talk with me about all this today. I am really excited about this.

Dan: I am super excited too. I think the workshop is going to be great, and I am really excited about the topic. I think it’s something that people really can go and immediately start using. I bet a lot of people will be like, “Now that I’ve heard about microinteractions, I can’t stop seeing them everywhere.”

Jared: Yeah. It’s just amazing. Everybody, you got to go out right now. Here’s what I want you to do. I want you to go to the Amazon, and then type in “Microinteractions,” all one word, It will present you in the search engine results the name of the book “Microinteractions.” You go there, and then there is a button on the right that says, “Buy Now.” Go get that. Do that right now.

Also checkout the UI18 Conference workshop that Dan is giving. You can find that at UIconf.com, because that is going to be really amazing.

Dan, thanks again for taking the time to do this.

Dan: Oh, my pleasure. Glad we had this macrointeraction.

Jared: Yes. It was pretty awesome.

I want to thank the audience again for spending the time. Please go to the iTunes and let us know what you think of these podcasts, if you like them, if you don’t. We love the reviews. We love to hear from you.

Of course, thank you again for encouraging our behavior, and we’ll talk to you soon. Take care.

Here’s an excerpt from the article:

Everyone assumed the old way of long lines was how you did it. They built their stores with dedicated space to accommodate the lines during busy periods, such as after the holidays. Apple’s new approach meant their architects didn’t need to build in that space, letting them put it to other uses, such as product displays.

Here’s the thing: Apple didn’t invent making an appointment. Yet their approach to using it for customer service seemed completely innovative.

Why was that? If we want to produce innovative products and services, there are lessons to learn from what Apple did.

Read the article: What Makes an Experience Seem Innovative?

How have you created innovative experiences? Tell us about them below.

Assumptions tend to be the downfall of many research projects. Making design decisions based on generalizations of what people are likely to do leads to surprises once you finally get your product in front of actual users. The result? Rework and frustration due to an overall lack of communication within the team.

Jeff Gothelf suggests starting with an attitude that you’re testing a hypothesis which leads to a more open discussion. The main thing is, hypotheses, just like design, can change. Being flexible and iterative in your design process encourages an environment of collaboration.

Working this way allows you to work free of heavy design documentation as well as collaboratively in real time. Jeff finds that simply changing your thinking about your product from “we know” to “we believe” is the catalyst to a more productive workflow.

Jeff will be presenting one of the daylong workshops at the User Interface 18 conference in Boston, October 21-23. For more information, visit uiconf.com.

Recorded: May, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everyone, welcome to another episode of the SpoolCast. I have with me today the wonderful Jeff Gothelf, who is, once again, gracing our presence with a full day workshop at the User Interface 18th Conference. This time, he’s doing a workshop on escaping product requirement, how using Lean UX.

Jeff is the author of a fabulous book, cleverly titled, “Lean UX,” which he co-wrote with Josh Seiden. It’s a great book, and today, guess what we’re going to talk about? We’re going to talk about Lean UX stuff.

Hey, Jeff.

Jeff Gothelf: Hey, Jared, how are you?

Jared: Doing fine. I thought that we could talk about some things. When you and I were talking about your workshop, we got onto the subject of sort of testing out hypotheses. I’m really interested in this idea of testing hypotheses, because I grew up in this world where, when we tested a design, it was to see how usable it was. It was to see how easy it was to use, to find places where it wasn’t easy to use, to iron those kinks out of things.

But as I’ve been reading through the Lean UX stuff and the Lean startup stuff, there’s a lot of this discussion about taking a hypothesis and testing it. I’m really curious how that’s different from what we’ve traditionally done in terms of putting users in front of a design and seeing if they can use it.

Jeff: Well, the first thing that testing hypotheses does is it simply changes the conversation. The moment you start to use the syntax of, this is a hypothesis.

The syntax that we use in the book and the syntax that we teach in workshops is, instead of we know, it’s we believe. As soon as you change the conversation to, well, we believe this to be the case. We have, with an educated guess, we have historical data that perhaps points to this. But until you actually put something in front of customers and have them interact with it to some extent, you don’t really know.

The conversation becomes a much more collaborative and, I think, productive conversation that says, OK, we’ve got this idea and the idea is that we should build this feature, or that we should change our product strategy. Or that we should make the button red or whatever that idea is, depending on, there’s obviously different levels of granularity. But we believe that this is the way to go.

The next thing you need to do is assess the risk of that assumption. You’ve just made an assumption. The assumption is that this feature or this product will cause some change in your customer’s behavior. you’ve declared those assumptions. Depending on the risk of those assumptions, we would recommend, if there’s any kind of significant risk there, that you test to those assumptions.

If the risk for you to run an A/B test, changing the button color from red to blue, to see which one gets clicked more, is relatively low, then that’s fine. You can run that test. You can make that decision and see what kind of change happens. But if there’s a fundamental risk here, whether it’s to your existing user experience, your product, or whether it’s a costly feature to implement, there needs to be an opportunity given to the team to prove out whether it’s worth investing that time and money in that feature.

That’s where this idea of a hypothesis comes in. You’ve written this hypothesis based on your assumptions. You’ve made an assumption that a particular customer type exists and you’ve made an assumption that that customer type has a particular pain point or a series of pain points.

You’ve made an assumption that your produce offering can solve those pain points. You combine all those assumptions into a hypothesis that says, “We believe that building this feature for these people will achieve some kind of outcome.”

Now your job is then to test that hypothesis as quickly as possible and in as lightweight a fashion as possible. The difference here is that you’re not testing usability. You’re testing value. You’re testing the viability of an idea or the value of a proposed feature. To see if it’s worth investing in. You’ll get to usability testing should you choose to invest further in this feature. You’ll get to usability testing. But do you even want to design something that people don’t want or need, or spend any time building it?

Jared: I’m thinking about a website that they’ve decided to undergo a major change in their pricing model. They used to be $25 a year and now they’re going to $49 a year. They’ve got different features that they’re offering for that.

Someone in the business department thinks that this is going to reach a wider audience, make people happier, give more value. Walk me through. The hypothesis is that this is an improved model. Is that right? Or do we have to refine it a little further?

Jeff: This is a business assumption. There’s no product assumption to test there.

Jared: There’s feature packaging that’s going to go with this. The idea is… Let’s say the $25 a month thing was a limited package, but now we’re going to unlimited storage and ad-free content and being able to share with your friends in a new way. This is what the business dude thought up. Do we break that into several different hypotheses? Is that what we do?

Jeff: You can. Again, it really depends on the amount of risk. If all these things already exist and you offer them in one capacity or another, it’s simply a pricing test, then running a pricing test is a relatively simply process. That doesn’t require that the hypothesis is simple. Will people pay $49 for this thing that we used to charge 25 for? You set up a landing page that offers the new pricing scheme. You drive traffic to it with some Google AdWords or however you’re driving traffic for your target audience.

And you just see if people will start paying that kind of money for it. That is a hypothesis, but it’s a relatively easy hypothesis to test. It gets more interesting when the business dude says, “We’re going to charge $49 for a more complete package, but we’d like to include these two new features in that package. We’d like to upgrade the functionality of the product in this way for that package.” Now the question becomes, is there a significant investment in making the product do these things?

And is there a need in the marketplace for these additional things for the product? The question then becomes not only, “Will people pay for it?” But, “Is it worth our while to even build this? Will people use it? Is this something that will make them more satisfied customers? Other than just making us more money, will this make them more satisfied customers?” That’s the question that we need to ask.

If one of the features that was suggested is a high risk feature, than the hypothesis becomes, “We believe that building this high risk feature for this portion of our target audience will alleviate this particular need for them and, in turn, will drive greater subscriptions of the premium product.” So we’ve got a clear definition of success there as well.

Jared: What makes something a high-risk feature? Is it just the complexity to implement? Or are there other things to?

Jeff: There’s a variety of choices. Ultimately, your company needs to decide how it quantifies risk. But yes, technical complexity, for example, is high risk. It may be simply something that takes a lot of resources to implement. It may not be technically complex, but it’s just going to take a lot of time to build these features. So there’s financial risk to your company. Maybe you are taking on a new target audience.

You’re opening an exclusive product to a broader audience. There’s a risk of either erosion of your existing customer base or a cannibalization of that base. Maybe you’re stepping into a new market that you really don’t know that much about. You’ve been working in one vertical for a while and you’d like to move over to a new vertical. These are all things that, as a team and as a company, you need to decide how you’re going to prioritize your hypotheses.

Ultimately, you can’t test them all at once. You don’t want to test them all at once. And so you need to be able to figure out, “How are we going to prioritize a backlog of hypotheses so that we have a clear plan as to which ones we’re going to test first and then second and then third?” That’s really a team level or a company level decision about what are the riskiest things that you’d like to go after.

Jared: Let’s say I’m a dude who’s been doing user research now for a while. Standard user research stuff. I conduct usability tests and give feedback to the team on what features to the change. Maybe I’ve done a good job of convincing folks to go out in the field with me.

We go out, meet our customers and being to see who they are. What skills do I have to pick up now, to move into doing more of this hypothesis testing? Or is it basically just the same thing? We’re just re-framing the way we look at the problem?

Jeff: The skill sets that researchers bring to teams that are working in a more iterative, rapid fashion or delivering in a more agile fashion are invaluable. The thing that we’re testing and the formality of the testing changes a bit. As well as who’s doing the research. So the skill sets that are brought in are the same. You’re utilizing those same techniques that you’ve used to extract information out of customers for years.

It’s just the creativity comes in now, as to what we’re going to test and why we’re testing it. The question is, we’re not going to test pixel-level detail right off the bat. Maybe that’s not where we want to spend our time. Maybe where we want to spend our time is with a paper prototype or an approximation of a work flow through a couple of screens that we hacked together in a keynote flow.

Anything to just get the conversation started with customers. Maybe the smallest thing that you can test is not even digital at all. Maybe it’s simply getting folks to read a paragraph and react to it. Maybe that’s it. So it’s understanding how to apply the skills you’ve been using for years, in a context that requires you to share those skills with your teammates. Because we want to empower everybody on your team to be able to talk to customers and get those questions asked appropriately.

And then also to help the team understand how to structure conversations with customers when they’re looking at these less than polished experiences, or approximations of an experience.

Jared: Part of this means that we have to think about where we’re coming from, in terms of our process. But some of it also has to do with the assumptions that we bring to the table. When I talk to teams, there are people on the teams who have all these different assumptions. “Our users can’t handle this sort of thing. Our users really want this type of functionality. Our market, traditionally, hasn’t responded well to things that do X.”

I often wonder where a lot of these assumptions come from. We were working with a company that produces software for human resources departments. They were pretty much convinced that the human resources people knew exactly what they needed the product to do. So it was just a matter of going in and having enough options in their product to do everything a human resources department could ask for.

When we went out and actually met with the human resources folks, one of the things we quickly learned is, they aren’t very good. A lot of them don’t know how to do the things they need to do. They were looking for the software to give them best practice suggestions. They took the defaults in the software that they had and assumed it was the best practice, when in fact it probably wasn’t. To me, it seems like there’s a big problem that teams have with the assumptions that they are basing everything on.

They build assumptions on top of assumptions on top of assumptions. Have you seen that problem?

Jeff: Certainly. Every time that we engage with a new team, the first thing we do is have them declare their assumptions. The first assumptions we have them declare is who they believe they are building products for. Personas. Not a big secret. We have them talk about who they believe their building products for. It amazes me. The same way the anecdote that you shared… I kicked off a project with a client about a month ago.

We were there. We were on-site, kicking off with our inception workshop. One of the first exercises we do is get everybody to tell us who they think we’re building products for. When I spoke with the client in advance, I said, “Yeah, we’ve got personas defined. We’ve got the catchy little names for them and the pictures. We’ve got the PowerPoint presentation with them. They were defined five years ago. So this section shouldn’t take but 15 or 20 minutes to review the personas.”

We sit down and spent over two hours bringing them to consensus, as a team, around who they believe they’re building products for. We see this all the time. The most critical mistake that teams make is assuming they’re on the same page with their colleagues. The work that we do, when we start building products with teams and when we’re kicking things off is just to get those ideas out of their heads.

What does the engineer think? What does the product owner think? What does the stakeholder think? What does the designer think? It’s amazing how different the worldview is. For people who’ve been working next to each other for years, in the same domain. And then bringing them to a consensus. Again, the consensus that we bring them to, they don’t have to necessarily agree 100 percent that these are the three or four personas that we absolutely are building product for.

They just have to agree these are the three or four we believe we’re targeting. Then we go out and test our hypotheses. One of the things that we’re testing is the personas, the validity of the personas. Does this person exist? We just made Jared the Jewel Collector. We assumed that Jared has these characteristics that drive the way he would use our service, that he has these needs and that our solution maybe has value for Jared.

One of the first things we do is go look for Jared the Jewel Collector. Does he exist? OK, he exists. Terrific. We found 10 or 15 people that embody this archetype. That’s terrific. Does this person have these pain points, these needs? Yes. Yes, they do. Or no, they don’t. And if they don’t, what needs do they have and can we adjust our thinking to accommodate that? It’s one of the first things. One of the anecdotes I tell all the time when I’m in front of teams is a story about a team we were working with in New York, who was building… It was a food targeted at locavores, people looking for locally grown, organic food.

They were targeting women in their late twenties who like to cook, single women in their late twenties who like to cook. They made a proto-persona, one of the lightweight ones we talk about in the book, called Susan. Coincidentally, we happened to be up the street from Union Square, in New York, where there happens to be a farmers’ market. We sent a team out into the farmers’ market, in search of Susan.

They went out and talked to all the single women in their late twenties that they could find. They couldn’t find a single one that liked to cook. All these women that they found liked to buy pre-packaged, prepared foods they could heat up or warm up very quickly, because they were just too busy to spend time cooking. What they did find were a bunch of men in their thirties who loved to cook and were always looking for these unique recipes and these unique local ingredients.

So they went back, after spending a half day creating this persona and validating whether it exists or not. They adjusted Susan. Susan became Timothy, over the course of an hour. All of a sudden, they had a slightly more realistic view of who they were targeting. They set up a series of assumptions, then went out and knocked them down. Then realized where they had to make some tweaks and what they wanted to adjust in their personas.

That helped them focus their product further. One of the first things we tell teams to do is to go out there and just make sure that these customers actually exist. Some customers and some companies are very well researched in this. They know these things. That’s terrific. Let’s get that information out. Let’s make sure everybody else on the team knows this as well. Then let’s build those into our validation processes.

So that we can recruit when we actually go out to find customers, against these targets. If they’re current and well-researched they should continue to prove themselves out. If they’re not, then at least you can get a more current view of who your audience is, your customer base is and how they’re dealing in the vertical that you work in.

Jared: I’m interested when you say that a lot of companies are well-researched. In my experience, research comes in lots of different flavors. You’ve got market research, where people are focused on who they’re going to sell to.

It turns out that market research and they type of research we need to build products often doesn’t break down the same way. So the marketing segments that folks come up with, to figure out how they’re going to position the product and what the messaging they’re going to use is, doesn’t necessarily translate well, into the design decisions that we have to make.

So we need behavioral understandings of our folks. For example, Susan and Timothy, I’m curious, are there behavioral differences between what they imagine that twenty-something woman to be, versus the thirty-something guy? Maybe this is not what you’re trying to do, but how do you make sure that you’re testing the behavioral understanding of who the user is, in addition to this demographic psychographic approach to it?

Jeff: There were a lot of questions in there.

Jared: Sorry about that.

Jeff: I’ll try to go through them, back to front. I’m not convinced that many companies are well-researched. I do run across that company that says, “We have personas. We know who our customers are.” So what we ask them to do is, we ask them to bring that data into the conversation, into the inception conversations, into the hypothesis writing sessions, into the assumptions, declarations.

The amazing thing is, again, they may be well-researched, they may be documented, but no one has ever thought to question them before. So all of a sudden, the persona conversation is open for debate, which it never has been before. That’s an interesting one. Yes, I completely agree that who marketers want to sell to, versus who actually uses the product are often two different people. So for that reason, if there is a marketing person or a marketing representation that can be included on the project, at least in some capacity, I think it’s extremely valuable.

Because one of the techniques that we promote in the book, we call it collaborative discovery. Essentially, all it is is letting the entire project team do the research together. So engineers, designers, product managers, marketers, researchers, content strategists, QA, whoever’s on the team, goes out into the field, in pairs, and talks to customers. And meets them. Either on-site or in the company, bringing them into your lab or in the context of where the work.

But the idea is to expose everyone on the team to the customer and the abrupt dose of reality that gives to people who have never been out there. I’d be surprised if most of the marketers in your organization have talked to customers on a regular basis. In many organizations, engineers never get to talk to customers. Frankly, in some organizations, designers never get to talk to customers. So the opportunity to get out there and start having those conversations starts to bring a bit of reality and ultimately humility into the persona conversation.

That’s something that’s been very helpful for the teams that we’ve been working with, to get them out into the field, talking to customers on a regular basis. And again, tying back to what I said earlier, this is really where your user researchers play a critical role. “Here’s how you talk to customers. Here’s how you structure an interview. Here’s how you ask a question.” You see what I’m saying? You apply all the things that you know so well, as a researcher and start to train the team up on those skills, so that the insight they bring back is useful and usable.

Regarding the fundamental product changes that you make, as you go out and meet these people, is there a fundamental change in the way that a woman in her late twenties would use a particular application, versus a man in his thirties? The answer is, we don’t know. That’s an assumption that we’re making. To your point, the things that we care about in those target personas are the psychographic and demographic components that affect the way they would use our product or service.

If they have four kids and that has no bearing on my application or feature or whatever it is, I don’t care about that. If they’re male or female and that doesn’t change the way they would use this particular service, ultimately that doesn’t matter. We’re looking for the psychographic and the demographic attributes that would affect the way they shop. For example, for this locavore app that we mentioned earlier, if they are into fitness and don’t eat fast food, that’s relevant.

If they drive a Volvo, I don’t think that’s relevant. We want to focus the personas on the characteristics that we believe will actually affect behavior in the application. And then go validate that these components exist in people.

Jared: Though, when I work with teams, the rule of thumb that I like to use is, every time you write down something about your persona, you need to tell me what that affects in the design, what decision that has a bearing on. I used to call this the dog and hummer rule. Because inevitably, in the persona, it tells you what pets they own and what car they drive. Like you said, most of the time, that has no bearing on it.

But then I was working with HGTV, the folks who do Home and Garden Television. They were working on a search engine for projects, home improvement projects. They had dogs and hummers in their persona descriptions. I thought, “Guys, cut this out.” But it turned out it made a difference. Where it had a bearing was having a capability to specify that you needed a project that was pet-friendly.

So that if the dog ran through the construction of the bathroom refurb, that it wasn’t going to somehow get into something it shouldn’t be into that could ultimately hurt the pet. Or the car they drove made a difference if they’re going to go to the lumber yard and bring home their own supplies. Suddenly, those things had bearing. But you have to really be able to push and say, “OK. Are we going to have a feature that says, ‘You tell me what car you have and we’ll tell you how you get the supplies home’.”

Jeff: That’s the thing. We always push back, as well. When they say, “They’re married and they have two children.” It’s like, “Let’s talk about the things that… If they’re a professional person and we’re dealing with a professional capacity, was aspects of their professional life affects this?” It’s an interesting conversation. To your point, we try to lead with personas. Because everything else flows from that.

It’s the measures of success flow from that, the outcomes that we push teams to work towards. And then also the feature sets, to your point. The design, what are the things we’re actually going to build for this persona that will be valuable to them and help us achieve our goals, as a business?

Jared: I’ve been seeing a lot of this noise lately, about, “We’ve tried personas and they don’t work. We’ve decided they’re not useful. They’re a waste of time.” I’m with you. I think personas and scenarios are the way to drive everything in the project. Have you run into this attitude that personas don’t work out?

Jeff: I’ve seen it a few times. I’ve had a few teams ask me, “Why don’t we just start with tasks? Why don’t we just start with the outcomes?” The real power, for me, is getting these teams to think about who they’re building products for. Because I don’t believe they’ve actually done it.

At the very least, even if they throw them away when I walk out of the room, they work well as an alignment tool. You can take the team and say, “If we’re all just talking about feature sets, we’re just shooting in every direction in the dark. Let’s at least align around a particular direction and a set of people whose behavior we’d like to affect.”

And try to get the team to align around that. But yes, I’ve seen that. I’ve had questions come up about, “Why don’t you just start with a task? What is the task we want the user to complete?” The question I always ask back is, “Who is the user? What is their motivation? Why are they even using this service?” Again, I’m not advocating for six months and $50,000 worth of persona research that ends up in a PowerPoint deck that everybody reads once and then files away.

Jared: That’s the problem. When people think personas, they think that project, the persona project. We got ourselves into trouble by saying personas were a project in and of themselves.

Jeff: Research, in general, any kind of research, should be integrated into the project. Tomer Sharon, who wrote It’s Our Research, I love what he says. He says, “If people are talking about research as a project, you’re doing it wrong.” The research process needs to be integrated into the product design and development process and should be an ongoing activity. It’s not a one-time thing we did for six months before we launched and then for a month after we launched.

It should be just a part of the conversation, from the beginning. Personas are no different. This is saying, “Let’s not spend six months waiting for research to come back on whether or not these people exist. Let’s declare our assumptions based on what we know. We won’t get it 100 percent right. We won’t get it 100 percent wrong.” Then as we go out and build these continuous cycles of feedback from the market, grounding our ideas in the realities of the market by going out there and talking to people weekly, we start to figure out a lot of things.

Not the least of which is, do these people exist and do they have the needs that we are building features for?

Jared: That makes perfect sense to me. We should tell everybody about Lean Day West.

Jeff: I would love to tell them about it. Lean Day West is coming up in September. September 15th through the 17th, this year, in Portland, Oregon. We had such a huge success with Lean Day UX, on March 1st in New York that we decided to do it again. This time on the west coast. We got a lot of requests from folks on the west coast that said, “When are you bringing this to the west coast?” The answer is Lean Day West, September 15th through the 17th, in Portland, Oregon.

This time it’s actually a total of three days, although there’s only one activity on the Sunday, on the 15th. There’s a pre-conference workshop, which is terrific, gets you into the mood, understanding the concepts that the folks will be talking about. Then we’ve got a day of workshops from people like Bill Scott, whom is, in my opinion, a legend and a pretty amazing designer, technologist. He runs the front-end development team at PayPal these days.

We’ve got Farah Bostick talking about how to do research in a lean way. We’ve got Andrew Crow and Dan Harrelson, from GE’s design center, talking about design systems. We’ve got Lionel Morry, from Intuit, talking to applying design thinking to your processes. Intuit’s a real pioneer in these.

Then all those guys, plus a few more folks, are giving talks on the second day. So one day of workshops, one day of talks, and the Sunday before, if you get in early, we’ve got a pre-conference workshop with Jess Stearn about using improvisation as part of your product definition process.

It’s really interesting. So LeanDayWest.com is the website where you can get your tickets and read all about the lineups and the activities that we’ve got planned. We’ve got tickets on sale right now, at the early registration price. That price is good until the 11th of July. After the 11th of July, prices jump up a couple of hundred bucks. If you want to get in, get in now at the early registration rates. Again, those are good until July 11th.

Jared: And you’re going to be speaking at the User Interface 18 Conference. We have you doing a full day workshop called Escaping Product Requirement Hell Using Lean UX. It’s going to be a lot of fun. You’ve made this really interactive, right?

Jeff: It’s been a really terrific couple of years. I’ve been teaching workshops all around the world to a variety of different audiences. I’ve learned what makes them fun and interesting. It’s a workshop so we do work. It’s not me talking for eight hours, at you. It’s a little bit of lecture. It’s a lot of hands-on, team-based activities. We have a lot of fun. We do some things that maybe you’ve never done before. Maybe you have done them before.

We get to learn from each other in a highly collaborative way. I sincerely hope all of you join me. There.

Jared: It’s going to be great. Love to have you there. And your book, Lean UX, that you co-wrote with Josh Sidon, that’s doing really well. People can get that off Amazon or wherever great books are found. I guess is how the saying goes, right?

Jeff: And O’Reilly.com has it. LeanUX.com has links to everything too as well, but it’s been doing really well. A lot of really great reviews. I will ask that if you have read the book or if you get the book, it would be really great if you could write a review on Amazon. We’ve got about 30 reviews up there now and we’d love to get your opinion. It’s how we get better is to get feedback from the people who’ve read the book. We’d love to hear from you.

Jared: There you go. Jeff, thanks for taking the time to talk with me today. This is really awesome.

Jeff: My pleasure, Jared. It’s always fun chatting with you.

Jared: I want to thank our audience for listening and once again for encouraging our behavior. We’ll talk to you again next time. Take care.

Here’s an excerpt from the article:

When bringing our craft to software in the 1980s and 1990s, designers approached software in the same way we approached the earlier materials we worked with. In industrial design, print design, fashion design, and any field involving physical outputs, the manufacturing step is a critical constraint. When designing for physical materials, designers need to figure out what we’re making before we start production, because production is expensive. It’s expensive to set up a factory floor to produce hard goods or garments. It’s expensive to set up a printing press for a print run.

Working in software, designers faced new challenges. We had to figure out the grammar of this new medium, and as we did, we saw new specialties such as interaction design and information architecture emerge. But the process by which designers practiced remained largely unchanged. We still designed products in great detail in advance, because we still had to deal with a “manufacturing” process: our work had to be duplicated onto floppy disks and CDs, which were then distributed to market in exactly the same way that physical goods were distributed. The cost of getting it wrong remained high.

Read the article: Why Lean UX?

How have you implemented Lean UX? Tell us about it below.

While we focus on relevant topics and leading experts, other valuable aspects for you include the ability to register once, pay once, and easily gather your team for these incredible events! To that end, we offer a 6-month program for the virtual seminars.

You get:

• 2 connections, or feeds, to all 9 live virtual seminars, July through December, 2013
• Access to the recordings of those 9 seminars we’re producing in the last half of 2013.
• Bonus access to recordings (the current program members have received 5 additional recordings,
  a value of $745)
• (You’re hearing this first!) Free access to UX Immersion OnDemand

All this, for just $1149. Save your team’s spot for all 9 seminars before this offer disappears.

Purchase these recordings for just $189 until June 21.

Luke Wroblewski – Create designs without compromising optimization

Kelly Goto – Design with your customers’ behavior in mind

Chris Risdon – Tell a visual story of what pains and delights your customers

Cyd Harrell – Make better personas with tools to interpret user data faster

Karen McGrane – Chunk your content to adapt to different contexts

Jason Grigsby – Look into the future of designing for TV

Dana Chisnell – Consider the flow instead of the UI of your design

Jared Spool – Ensure delightful content regardless of the device

Explore the Recording Details

Rub elbows with your local colleagues and hear cool case studies from fellow UX Detroit designers.

We teamed up with Vitamin T to bring you a local conference designed especially for UX pros (and their budgets).

It’s a one-day event with six great presentations from local superstars and keynotes from two leading UX experts. You can check out the lineup or go ahead and register now (it’s only $99).

Wondering how you can bring this one day conference to your home town? Just vote on the home page where you want to see UX Thursday next. Atlanta? Denver? Tampa? You tell us!

Here’s an excerpt from the article:

Here’s a counter-intuitive fact: Chances are all those features you’ve been adding to your design are hurting your user experience. Every feature that’s squeezed in, in the name of giving your design a competitive edge, has been making your design less competitive.

Welcome to the effects of Experience Rot. As you add features, you’re adding complexity to the design, and decreasing the quality of the experience.

Pick up any modern TV remote and you’ll immediately see the problem of experience rot. On/Off, volume and channel selectors are no longer enough. We need to switch devices, control captions, have a text capability for on-screen editing, a thumbs-up and thumbs-down for ratings, pause, record, slow motion, rewind, 30-second rewind, and, well, you see the effects. The complexity never ends, it never gets simpler, and it’s never delightful.

Read the article: Experience Rot

What have you done to prevent experience rot? Tell us about it below.

Typography wears many hats in the user experience world. It’s part of the overall look of the visual design. It can convey tone and meaning of the content. Well set type can improve the user experience through readability and be an important piece of the accessibility puzzle for users with low vision. As with most things involving the web these days, typography isn’t immune to the disruption caused by mobile and multi-device design.

As an organizer of the Ampersand Conference and founder of FontDeck, Richard Rutter is passionate about typography. In his virtual seminar Typography in Responsive Web Design, Richard discussed best practices for typography when having to adapt your designs for multiple devices and browsers. During the live seminar, we ran short of time to answer all of the questions from the audience. Adam Churchill catches up with Richard to tackle some of the questions in this podcast.

• Is it better to measure type in terms ems, pixels, or percentages?
• What is the best approach for scaling fonts for different screen sizes?
• When determining fonts to pair, is it more of a gut feeling than a specific process?
• What are some of the best resources on typography?

Recorded: May, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome everyone to another edition of the SpoolCast. Earlier this year, Richard Rutter presented a virtual seminar called, “Typography in Responsive Web Design.” Richard’s seminar, along with 112 others, that teach the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library.

In the seminar, Richard explains why typography is like a visual hierarchy. He shows what to watch out for with the OpenType, and how features on the edge of CSS can make or possibly even break user experiences. Our attendees left with tools and practical techniques that they could immediately apply to their own designs.

Hey Richard, thanks for coming back.

Richard Rutter: Hi, thanks for having me back.

Adam: For those that weren’t with us that day, can you give us an overview of what you covered in the virtual seminar?

Richard: I talked about why good typography is a necessary component of a good user experience. I opened up by quoting some scientific research that was done fairly recently. It had a few crucial things that are really good for us to know.

One is that it proved that good quality typography is responsible for greater engagement during reading. What that really means is that participants in the research significantly underestimated the time taking to read type which was set well.

The overall conclusion of this research is that good typography induces a good mood. In other words, good typography is inherent to a good user experience. It then became necessary, I felt, to try and talk about some of the things that I think make for good typography. What is good typography.

I spent some time talking about responsive design with typography as its basis, about paying attention to microtypography, the tiny little things to get right in your designs. Choosing and pairing fonts carefully. I also went into some technical detail about your options for loading Web fonts, particularly with a view to loading fonts over slow connections on phones, for example.

Throughout the whole talk, I built up an example page. I started this off by picking on a simple paragraph of text, and setting that for comfortable reading. Then using a few media queries, end-based media queries, so they’re based on the text size, to adjust things like line lengths and so on for different screen dimensions. That paragraph is comfortable to read, regardless of the screen that you’re trying to read it on.

I looked at a few other things along those lines, such as type scale, for example. When you’ve got a very small screen, you haven’t got the scope to have really big headings, for example. That’s obvious, but you look at many responsive designs at the moment, and you’ll see some have got huge headings which take up the entire screen, and you have to scroll straight away to even get to the first paragraph.

I talked about a few other things along those lines. When it came to microtypography, I was trying to concentrate a fair bit on the OpenType features, which are features of fonts, which were available to us with CSS3.

Those are things like different types of numerals, so you can have lining numerals and old-style numerals, which are like capital numbers and lower-case numbers, if you like. The different scenarios in which you would use those.

Picking out one of typography’s old favorites, which is using real small caps, as opposed to tiny little capital letters. Tried to convey why those are different, and why it’s important to remember they’re different.

Choosing fonts and pairing fonts, in particular. With choosing fonts, let’s have a look at that to start off with. I was thinking about the requirements that you would have before you go and choose a font. You can get yourself a reasonable short list of practical things that font’s got to do for you.

Does it have the characters in there that the reflect the languages that are being used on the site, for example? Does it render well at the sizes that you think you’re going to use it on, on different screens and different operating systems?

All of these things that you can try out to decide, from a purely practical point of view, whether the font is right for you, before you even go down the lines of more subjective views. Does the font say what the text is saying?

Pairing fonts, I gave a few hints about how to try and make that easier. Picking a superfamily which includes a sans and a serif, for example, that have been designed by the same designer to work together. That’s a really easy way of knowing if they’re going to work. Picking fonts by the same designer which are different fonts but may still work together, this kind of thing. Using type foundry websites to help along the way about which typefaces individual foundries are saying go together.

There’s lots of information there to help you make these choices beyond “Does it just look right?” or “Does it look wrong?” I showed a few little things about the internal shapes of the letters, to try and explain a bit why some fonts look right together, and some clash.

All along, building up an example page, to try and put all of these into context.

Adam: There were a lot of great questions from our audience, Richard, and there were some that we wanted to revisit. Both through the virtual seminar folks, and people that were following us on Twitter.

There were a bunch of questions or inquiries about the size of the typography. What’s your recommendation for a unit to measure type? Em, pixels, percentage, what do you find is the most effective? Are there problems you run into with any of those?

Richard: Nowadays, all the cool kids are using Rems, which is relative ems, and they’re backing those up with pixels. My design agency, Clearleft, that’s certainly the approach we take now.

It used to be, and I’ve written quite a lot about this, that pixels, although really easy to use in terms of setting type size in CSS, tended to be frowned up, mostly because of our old friend, Internet Explorer. In Internet Explorer 6 and older, if you set text in pixels, then the native controls within the browser wouldn’t let people resize the text.

If someone reading the page needed bigger text, maybe they had a really high resolution screen, or more likely they were short sighted, they want the text bigger. IE 6 wouldn’t allow them to change the text size, if you set text in pixels.

IE 6 has somewhat gone out of the equation now, but at the time, the alternative was using ems. Em is a typographic unit. One em is equivalent, roughly, to the width of a capital “M,” that’s why it’s called an “em.”

They were used, and they work really well, but they become quite hard to manage because they’re all about multiplications and they’re inherited. If you have a paragraph, in a list, in a div, inside your body, it all becomes a bit complicated. Text becomes much smaller, and it’s harder to work out, basically, the mathematics that you need to start applying in your CSS.

If you’re on a big production-scale website with lots and lots of front-end developers, it can be incredibly difficult to manage, which is one reason why pixels never went away.

The rem is a new unit which was introduced, I think, in CSS3. That works like ems, but it’s all relative to the root pixel size. That’s basically the text size of the HTML element. Typically your HTML element will be 16 pixels. If you have an eight one, and you set that to be two rems, then it will be 32 pixels.

In terms of Internet Explorers, only IE10 I think, possibly IE9, supports rems. So currently in style sheets, one tends to put pixels first and then rems afterward, just as a fallback until those pixel rules can be made to go away.

All versions of Firefox, and WebKit-based browsers worth speaking about, all support rems. They give a best of both worlds, is the idea with those.

Adam: Lots of talk about, in designs, doing the right things for the many varying screen sizes that designers are forced to think about. What do you recommend? Do you recommend scaling text sizes for different screens? What’s the best approach for that challenge?

Richard: The fundamental approach, with all responsive design, which is really what you’re talking about there, is making your designs respond, adapt, to their different environments. Which would normally be a different-sized screen. Sometimes a different-size resolution as well. The fundamental thing is not thinking about screen sizes, because there are far too many of them. It’s about thinking, “When does my design break?”

There’s this key thing within media queries, which are these rules within CSS in which you can apply properties and CSS rules specifically to certain screen sizes, for example. Those are called break points. They’re called break points, as far as I’m concerned, because they’re introduced when the design breaks. When a paragraph gets too long to read, you introduce a break point to say, “The design has broken at this point when the paragraph has got to a certain length, so I’m going to write a CSS rule to shorten that paragraph, to make it easier to read again.” That’s your fundamental way of thinking.

The same applies with text size. I think about it a little bit earlier on. When you have a small screen, you don’t have the scope to have the variation in font size. Often, the most useful thing to do is look at what the browser defaults are for that device. Particularly, small screen smartphones.

The browser default text sizes for h1s, for paragraphs, for h2s, tend to be about right. There’s a pretty good reason for that. When you start thinking about bigger screens, where you’ve got much more space, particularly vertical space to deal with, you’ll find that you want to exaggerate the differences between headings and body text.

Not only is there more room for bigger headings, the balance feels better, as well, if you’re making your headings. The only way you can do that, again, is with media queries. Looking at it, saying, “When the amount of vertical space in the screen hits this point, the design starts to break. It feels like the headings need to be bigger.” So you make the headings bigger. That’s the general approach.

You take that for every part of your design, as far as I’m concerned. It can mean that you end up with quite a lot of break points, and lots of break points doing not many things. Whereas, perhaps when you first started doing responsive design, we thought, “OK. I’ll do CSS for a phone. I’ll do CSS for a tablet, and I’ll do CSS for a big screen.” You have basically two break points there, in between the three sizes, but I don’t think that’s the way to do it.

I think it’s all about looking at a design. When does it break? Which bits break when? Applying rules at that point. Probably takes longer. Perhaps, arguably, but you get the better result, I would say. Certainly a longer-lasting result.

Adam: Richard, towards the end of the virtual seminar there were a lot of examples you were sharing. You got into some discussions of fonts sitting well together, pairing up fonts. How are you making that judgment? Is it based upon feel and your experience, or are there specific features that you’re watching for there?

Richard: To be honest, it’s really down to feel. It’s down to feel to a point. If you are picking a sans and a serif from a superfamily like, say, Centro or Carmina or Museo or any number of huge families that are available now, where there are sans and serifs designed together, then you know they’re going to work together. Then when you’re designing with them, you can see that they’re working together, and that’s the thing.

When you’re picking fonts to pair together, it tends to be you have a gut feel as to whether they work together or not. It’s like hearing two notes on a piano. You know whether they’re in harmony or not. Sometimes, when you press two white keys right next to each other, they clash because they’re too close. If you press two keys which are three or four apart, you get a nice sounding harmony.

There’s an analogy with type faces, as well. If they’re far enough apart, they’ll probably sound OK. If they’re too close, then they start working against each other. That’s trying to examine a reasoning as to why two fonts might not be working, but ultimately, it’s what are your eyes telling you?

Like I said, if you don’t trust your eyes to do that, then there are ways of getting around it. In the same way that you can come up with color schemes by using all manner of color scheme generators online, which will look at opposite colors, and harmonious colors, and things like that. Mathematically generated, based on algorithms, that we know the colors will go together.

You can pick rules like that with type faces as well. Like said earlier on, from the same font family is a really good start. Looking at individual designers, individual foundries as well, often have a certain feel. They will often, in order to sell more fonts, helpfully tell you, “This type face goes with this type face, so we recommend you buy them both.” There’s a vested interest with the foundries to do that for you. Of course, it does give you some useful information along those lines as well.

Adam: Richard, before we let you go, one of the reasons why we asked you to do this virtual seminar for us is, you create a wealth of resources for the design audience on typography.

You run a website called webtypography.net. You organize a wonderful conference called Ampersand. I hear there are rumors of a book coming out from you, from the Five Simple Steps folks. Can you share with our audience a little bit about each of those?

Richard: Sure. Webtypography.net is a site I started putting together in 2005, and I’m trying to keep it up to date. It’s taking Robert Bringhurst’s books, which some people call the “Typographer’s Bible.” It’s called “Elements of Typographic Style,” and it’s picking up on the guidelines that he writes about there, and explaining how to do them in CSS and HTML, if they’re relevant to screen and the Web, which in some cases they aren’t, but most of the time they are.

It’s not so much a case with that of saying, “This is how you should do it,” but it’s more a case of trying to show that good typography can be achieved, and here’s lots of little techniques that you could achieve it with. That’s webtypography.net. Ampersand is in its third year. It’s a web typography conference, specifically web typography, that we run in Brighton, that’s in the UK. That’s on June 28 in Brighton.

For the first time, we’re also doing one in New York. That will be on November 2 in New York. We’ll be having great people like Jonathan Hoefler talking there. We’ve got Christian Schwartz who’s coming along. Lucas de Groot from Holland is coming over as well, he’s a fantastic speaker. It’s going to be a really good day, and that’s going to be smack bang in the middle of New York.

Then the book, that’s quite exciting. I’m writing that with Mark Boulton and John Tan for “Five Simple Steps.” We’ve just started, really, but we’ve got some great plans for it. Also hoping to do, as best we can, a really nice online accompaniment to it, as well. No date as to when that’s going to come out, but sometime in the not-too-distant future, I hope.

Adam: That’s all very exciting. Thanks for circling back with us, Richard. We really appreciate the time.

Richard: You’re welcome.

Adam: For those listening in, thanks for joining us, and for your support of the UIE Virtual Seminar Program.

Unfortunately, this rarely works out well. True, the tasks in the testing do focus on the changes, as they should. And the team may find a problem or two that could use refinement.

However, the team is likely to miss bigger problems in the design because they’ve focused the research too narrowly. Or worse, they’ll uncover those bigger problems, but not have enough time and budget left to tackle them, having spent it on the design changes.

We recommend that teams skip the “validation test” to identify and clean up these small elements. We tell our clients to hold off spending that usability testing budget until after the design has shipped, then do research on how it’s being used by the users.

Doing the testing after it ships gives the team richer insights into what the next set of design changes should be. This does imply that the decisions they made for the first set of changes weren’t as informed as they could’ve been.

That’s why the best course of action is to conduct the research before deciding what changes you’ll make in the design. This research doesn’t have to be expensive. It can cost the same (or possibly less) than you were planning for the validation usability test.

Your research should be open ended. You should not assume the team understands how users are really using the design today. Instead, your research should explore what’s happening in the real world. Ideally, you’ll look at both new and existing users. (Inherent Value Tests are a great way to do this.)

By researching early, your team learns what to change. You’ll learn what to keep (because users love it). And you’ll learn how to structure the work.

It makes it easier to build the requirements, define the use cases, and even create QA test scripts, because you can drive all those things right off what you saw in the research. It will likely reduce your development costs because you’ll have data to make decisions, instead of driving everything off some strong-willed individual’s opinions of what users need.

Pushing your user research as early as possible in the schedule is the best way to get value from your efforts.

In this latest installment of the UIE Book Corner, we catch up with Russ Unger to chat about the book he co-wrote with Dan Willis and Brad Nunnally, Designing the Conversation: Techniques for Successful Facilitation. Russ is a Senior UX Leader at GE Capital along with being a well regarded author and speaker.

In an increasingly distributed workforce world, collaborating with design teams becomes much trickier. It’s not without it’s benefits. It opens your team to talent that may not otherwise have been available. Simply hopping on a Skype chat or GotoMeeting can be a solution, but often facilitation is the missing piece to the puzzle.

Facilitation is an important skill, whether with collocated or remote teams. It drives conversation and collaboration. The ability to facilitate well is integral when conducting participatory design activities, giving a presentation, or even giving a virtual seminar. Russ joins Adam Churchill to discuss the book and the various types of facilitation in this podcast.

Recorded: May, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: We’re continuing what we’re calling the UIE Book Corner series, with a look at “Designing the Conversation,” co-authored by Russ Unger, Brad Nunnally, and Dan Willis. The book was published earlier this year, and one of the things we like to do is take a look at the Amazon reviews and see what folks are saying. Among some of the things that we saw, “It’s a great book for anyone presenting, moderating, or facilitating.”, “The book offers lots of great insights into improving the conversation surrounding design with your teams and within our organization.”, “If you ever have to run a meeting, make a presentation, or even just ask your boss for a raise.”

We’re thrilled to have Russ Unger join us to discuss the book and its important concept. Russ also co-authored “A Project Guide to UX Design.” We’re recording this so you can listen in to what he has to say.

Hey, Russ.

Russ Unger: Hey, Adam. Thanks for having me.

Adam: Yourself, Brad, and Dan, that’s quite a lineup. Tell us a little bit about how the idea for this book came about.

Russ: You mentioned my first book that I wrote with Carolyn Chandler, called “A Project Guide to UX Design”. When the first edition came out, we got a one-star review on Amazon, and we got criticized for having a chapter that was called “Facilitating.” Now, the funny thing about that is there was no chapter in there, but it really kind of got me thinking about it. When it came time to write our second edition, I had earmarked facilitation as a chapter. I’d been pretty fortunate to take part in Cranky Talk Workshops that Dan Willis had put together, and facilitation was really on my mind. Especially since I’d been working with Todd Zaki Warfel on a book called “Guerilla Design and Research Methods” that’s still somewhere in the ether, and seems to remain almost finished.

Well, to make a long story short, I couldn’t find a way to fit worthwhile content about facilitation into about 10 or so pages of the second edition of “Project Guide.” Fortunately, we could put those pages to better use, and my wheels were really in motion. While we were doing this “Tweak Your Talk” session at South by Southwest last year, I started talking to Dan and Brad about the idea. Before long, we pulled together a proposal, and we found that there was a whole lot to talk about. In fact, I think about 240 pages of it, all on facilitation.

Adam: Alright, cool. Let’s jump into the book, taking a look at the way the book is structured. Section two is on group facilitation, section three is on one-on-one facilitation, and section four is called “One-on-Many Facilitation.” I’m just wondering if you can help folks understand, what’s the difference between group facilitation and one-on-many facilitation? What do folks need to understand there?

Russ: That’s a really great question. The biggest difference is that group facilitation is focused on working with groups of people who are essentially activity-based. By that, I mean that they’re engaged in workshops or brainstorming activities, focus groups, participatory design activities, and things like that. The group is essentially working toward a goal and an outcome, and they’re really setting out to achieve something. When you get into one-on-many, it’s more about a person, or a group of persons. People who are being the point of focus for a group of people, who are interested in their content. Kind of like your own virtual seminars or a presentation.

It’s those scenarios where there’s a lot of sharing, storytelling of information to a group of people, who are fairly limited in the way that they are responding or reacting, and even in how they contribute. In that section on one on many or one to many, its things like conference presentations, virtual seminars, like I just mentioned, lectures, which then all have their own set of challenges. Given the way technology and connectivity are moving along, these are becoming more and more important to know about. Particularly as we start seeing more and more distributed teams in content.

I myself work in an office in Chicago, but I’ve got teammates who are in Michigan, Connecticut and Minneapolis. This, to me, is a really important section to understand.

Adam: The book has lots of voices. That is, experts in our field weighing in on the concept, in that structure. I guess we’ll call them sidebars. You’ve got people like Dana Chisnell, Richard Dalton, and Kevin Hoffman. Super folks that we’re fortunate to work with, voicing their opinions on topics within the book. Besides the fact that it’s an all-star lineup of user experience design, how are those going to add value for anyone who’s going to pick up a copy of this book?

Russ: One of the things that Dan, Brad and I all know is that you don’t know everything about all of these topics. Frankly, there’s always more than one way to do things, too. You can look at just about anything you do, and somebody’s hacked a different version of it. We’re all pretty confident that we could be dropped into just about any scenario in the book, and we could likely pull that off. When it comes to sharing expertise and putting it in someone else’s hands to learn from, we wanted to make sure that our voices were helping to provide a great starting point. A core foundation for the activity, if you will.

And then, provide perspectives of others who are pretty deep into the topic areas. So for example, we have a chapter on practicing that gets input on about 20 different people, including myself, about how they practice before they get into a live scenario. The more I work with other people in facilitation activities, the more that I learn we’ve all got different flavors of approaches. For example, if I practice presenting something, I’ve got this crazy method to my own madness here. I start out with pencil and paper and doing outlines two or three times. Then, I get to something that’s digital. Then I will go back to note cards, and I may sketch on them. I design slides, if I need to. Then I will get into a digital tool, and start pulling that content all in place, making that its own entity. It may seem like that’s all part of the research and information gathering aspect of things.

But for me, it’s also designing and refining the content. Learning how to kill some of my darlings, and get familiar with the points that I want to drive home. After I get slides together, I will find different opportunities to go through that content. Frequently Brad and I will do Skype, and JoinMe sessions where we’re looking at content. Walking through it, and finding out where I’ve missed a beat or something.

I’ll do that with a local guild that we have in Chicago. Fortunately, for my kids, sometimes it’s with them. So they can see, and I can see where I’m tripping up. The thing of it is, that’s just my way of doing it. The more I do things like read Scott Berkun’s book, “Confessions of a Public Speaker”, he’s got his own method for doing these things. Then you look and you’ve got people like Eric Reis, Cennydd Bowles, Margot Bloomstein, Andy Budd in there.

Who all have different approaches. The idea is, we want to give you this core foundation. Here’s a really basic way to get started. But now go, and learn from these other people. It’s not just Russ, Dan and Brad say, “This is the right way.” They say, “This is a great starting point. Now you can learn from some of these other folks and tailor your approach.” I don’t really see that there’s an exact formula for practicing, as an example.

This is a great way to show that and help others. And also get some of our super talented friends into the mix, to help people along.

Adam: I’m going to be selfish for just a moment, but my goal here is to extract some nuggets of wisdom, to pass along to folks that I work with. I, of course, run the UIE virtual seminar program. Chapter 16, in your book, speaks to the challenges of virtual seminars and how to maximize the opportunity. What would you say the key take away is, for someone that’s planning to facilitate one on many, in this case, through that means?

Russ: For starters, chapter 16, Dan wrote that and he did a phenomenal job on that. What I think is, you have to get comfortable with that absence of feedback. You and I are having a conversation here, and so there’s a little bit of back-and-forth. In general, I’m the type of person who, I don’t know, I struggle with silence. I’ve really been working on taking a breath, having strategic pauses and the like. You already know this, I’m a really fast talker. I’m trying to read an audience and be measured. I also play to them and get a sense of what parts of the content are hitting home, and what parts I need to tailor or adjust for depending on my audience.

When you’re in a virtual seminar, there’s a lot of things that can go wrong, too. I do these things in Chicago called ChicagoCamps. They’re day conferences. You guys are always super sponsors. Shay and Brad, who I do these with, we always try to do things a little bit different. We did remote sessions the last time, and they’re pretty similar to a virtual seminar. While we pulled them off and expected some glitches. That’s just it, right? There’s glitches, so much can happen; an Internet connection can go down, the software you’re presenting through can crash, hardware can have its own set of gremlins, so on and so forth.

In fact, I think you guys did a virtual seminar with Todd Zaki Warfel. It was at his old office in Philadelphia, and you could hear the trains going by. [laughs]

Adam: Yeah, that’s right.

Russ: That’s one of those things that’s really hard to do. Even when we do different things, where there’s people presenting to a very large, disparate group. Again, it’s so challenging to gauge that audience and feedback. You’ve got people on mute, and sometimes you’ve got those phones that beep when somebody gets off the line. There’s always that one person who’s driving with their car window down, or your Comcast connection dies — sorry, Comcast — or whatever it is. Something seems to always be a challenge. There’s something that can always go wrong. That’s a strange sort of thing.

Samantha Starmer had a great quote in the book, and she says that once these can get to the point of being more interactive and engaging and not about someone presenting, and about the someones being presented to, that they’ll kind of level up.

I think it feels like we’re almost there. We’re in that phase that we really have to be doing these things and figuring out what’s wrong, and getting them right and how to make them better.

I also want to say that just the fact that we can do them at all is pretty amazing. I keep thinking about the Louis CK bit, when he says, “Everything’s amazing and everybody’s unhappy…”

[laughter]

How truly awesome it is that we can have people all over the planet sitting down in a comfortable office somewhere, trying not to crush their lunch bag with too much noise. Then getting to listen to the brilliance of a Stephen Anderson, or a Karen McGrane, or Adam Connor, and so on. While 100 other people all over the planet are doing it at the same time.

While they’re not without fault, they’re amazing. I really can’t wait until they’re, I guess, amazing-er.

You had asked about a key takeaway, and I know I took a long, winding road to get there. My key takeaway from all of this is, to really practice and know your content, and your timing. I tend to be loose as a presenter, but when it comes to doing a virtual seminar, I think you’ve really got to be that confident presenter. You’ve really got to know your timing and your beats. Once you have all of that down, and you’ve gotten all the hardware and software parts figured out, it frees you up to stress on the important things. Like, “Ooh, did that content land like it should’ve?”, and “Next time I’ll remove all of my jokes”. Because it’s hard to tell a joke to a deadpan audience when you don’t know if they’re laughing in a room in Philadelphia, or if they’re going, “Wow, this guy’s a dork.”

I think that’s one of the key takeaways, is really know your content and understand that the audience is there listening and taking notes, even if you can’t see them.

Adam: I think that’s really important. Because whether you are a new presenter, somebody that’s just at the beginnings of thinking something through, and finding out your way of communicating it to an audience. Or somebody like Jared, who’s spoken in front of thousands of people, that lack of interaction really is the trick. I think you’re right, being comfortable and getting confident in your delivery, regardless of the lack of interaction, is important.

Russ: My virtual seminar, I wouldn’t make that my first speaking gig, ever. [laughs] I would be really nervous about that. Unfortunately, I just said that and probably just made a whole bunch of people nervous. Unfortunately, you come out of college and you work for these locations with very large, spread-out teams. That could be your first speaking opportunity. I think it’s everything we just said, you’ve got to really know your content. Practice is what’s going to make you confident, and make you less afraid of that lack of reaction.

Adam: I’m sure you have lots of folks coming up to you and saying, “Hey. Got the book, loved it.” What are they telling you they love about it?

Russ: What’s been really great to hear is that people are seeing facilitation as one of those parts of design that is being a bit under-served. It’s kind of a core to what we do. I’m continually adding to my own facilitation toolkit, and learning from others.

I get to work with Josie Scott. She was somebody who contributed a chapter on focus groups. It’s really awesome to get to talk to her. In learning from her, one of the things that I got was, that being a good facilitator is kind of like being that really amazing drummer who can also sing. It’s all the limbs are going at once. There’s a lot of moving parts, and there’s a lot of things to consider. It’s really been great to hear that we’ve been able to provide some strong content to help people upgrade those softer skills.

They also tell us, by the way, how fantastic Dan’s illustrations are. I mean, those things are gorgeous, and he was nothing less than brilliant. Brad and I would write notes about the intro to the chapter and say, “This is what we’re trying to convey. In words, this is what I’m trying to get to you.” Then, Dan would show up with this magical pen, and — I’m not kidding you — every single time, he nailed it. There was no, “Go back, this idea isn’t good enough.” It was amazing. I think people are really enjoying that because it’s a great complement to the material. Mostly, it’s also been great to hear that we’ve been providing a starting point for people who are interested in facilitation.

It also helps to erase some of those lonely late nights of writing. I think as you know, I have a couple of kids, and so I tend to write from 10 at night till about 2 in the morning. Every time you’d get one of those nice-starred reviews on Amazon, it makes you kind of go, “OK, good. This wasn’t so bad. Maybe I’ll do another one sometime.”

The other thing is there’s a lot of texts out there that tell you about all of these different activities that you can perform. That’s just one part of it. In many cases, there’s an assumption that you’ve been setting up an event or that you’ve set these events up before that need to be facilitated, and you can more or less just drop in and do the task and activity. The reality is, there’s a lot to consider when it comes to being a facilitator. I mean, Adam, you had to set up the questions here. You had to get Skype set up for us and had to arrange the time.

We have to do small things for a conversation like this. When you get into groups of people, you start looking at things like, “Here’s the agenda. Here’s the supplies. Here’s the technology I have to manage. Here’s all the people I have to get into the right place at the right time, manage their expectations, manage the expectations that you’re putting upon them, including their personalities.” Sometimes you may even have to feed them. Then, you’ve got to get to know all about these things, all about your equipment, your supplies, the timing, and all about the place that you’re doing it in. I’ve been saying it a lot more and more lately, but it feels to me like we’re all event planners now, because of what it takes to plan facilitation activities.

I mentioned Kevin before, Kevin Hoffman’s been doing amazing work solely around meetings. That’s just one aspect of facilitation. There’s so much to consider when stepping up to the plate. We’re hearing that we’ve been helping people with that and that we’ve been doing a good job. That’s really awesome to know that part’s been really paying off.

Adam: You mentioned juggling your crazy life with the kids and finding time to write. I know you speak a ton at design conferences. You also do great design work. I’m curious as to when you’re going in talking to those clients and you’re armed with a copy of “Designing the Conversation,” when they’re talking about their challenges, what chapter do you find yourself turning to most often?

Russ: I hate that the only thing that comes to mind here is, “it depends”.

[laughter]

Russ: Because it does though, right? It depends on what the problems is, what we’re trying to solve. One of the great things about writing with Dan and Brad is that we were all our first-pass editors. I’ve probably read this book three to four times from cover to cover. There’s so much that sticks with me from taking that approach. I’m going to say we applied a lot of tough love when it came to writing the book, so we beat each other up pretty hard. We, at the same time, really respected and cared about each other and the content enough that we read it very meticulously.

It’s kind of funny, I can walk into a situation, and I can instantly think, “Wow, I wrote this,” or, “Dan or Brad wrote something Great,” and I can reference it pretty quickly. When you write it, there’s that quote that says, “When you write, you learn twice,” so I’ve got the benefit of more memory on the stuff. I think what I would say, I personally revisited workshops, participatory design, interviews, and focus groups the most. I say focus groups because my opinion, humbly, is that a lot of people are trying to use them wrong. I don’t think they’re successful when it comes to usability testing, and a lot of people think that focus groups can get you that. There’s some learning, relearning, unlearning that needs to happen around that activity. It really does depend on the kind of problem you’re trying to solve and what kind of access and availability you have from other people.

I did, just so you know, recently check out the “Virtual Seminars” chapter because we’re doing some distributed team training sessions at work. It’s always nice to have that book to look at what Dan, Brad, or I have written, to be able to use that as reference material quite a bit. It’s really nice to have a full paragraph that you can lift and put into an email for somebody, to give them some insight about what you’re trying to get across.

Adam: Very cool. The book is awesome. Thanks for spending some time with us.

Russ: Thank you very much. I appreciate the opportunity.

Adam: To our audience, thanks for listening, and coming to hang out in the UIE Book Corner.

There’s one thing you can learn while prototyping that nobody ever talks about: Who should be involved in this project?

Design is a team sport. Building and supporting a product or service will need the assistance of others.

The traditional approach to involving these other folks is to hand them a requirements document and say, “Here. Build this.” The hardcore traditionalists spend weeks or even months describing every mind-numbing detail in the document, pretending the people they hand it to won’t have anything useful to contribute. Then the tradidtionalists wonder why these folks are pissed for treating them like they are idiot savants.

Using a prototyping alternative, we can show what we’re doing to those folks who will be helping us get it out the door and supporting it once it’s out in the world. We can ask them questions like, “Is this the best way to get these results?”

More importantly, we can ask these folks, “Who else should we be talking to? What might those folks tell us about what we’re trying to do?” Suddenly, we’re building a team of collaborators instead of trying to mimic a poorly-constructed factory assembly line.

If you’re prototyping, are you asking, “who else should be looking at this? Who else should be playing with us as we try out these ideas?”

Here’s an excerpt from the article:

What’s in, and what’s out? “In my experience, it is very easy for brilliant information architects (or UX people who do information architecture) to underestimate the importance of editorial planning, voice and tone, and detailed guidelines for content creation. And conversely, it’s very easy for highly skilled content people to underestimate how much information architecture has to do with things other than content: the finicky details of application behavior and interaction design, in particular. I’m a huge fan of collaborations between information architects who care about editorial concerns and content strategists who love structure and talking about data. But whatever your situation, it’s important to know your way around structural design, if only so that you can provide useful feedback and support.”

Read the article: Incorporating Content Strategy into Your Information Architecture.

How do you incorporate content strategy into your information architecture? Let us know below.

I’ve heard this dozens of times from design team managers. They all embarked on these big persona projects, often with energy and excitement, only to find that energy dissipate and the project lose its momentum. Personas that don’t help make design decisions are a waste.

However, it doesn’t have to be that way. These projects fail because of a perspective problem. The design teams think of making personas as a project in itself. I’ve come to the conclusion that thinking this way will lead to failure.

The alternative to having personas be a project is to make them just a step inside of every project. Instead of making them once and trying to use them everywhere, we come up with a low cost way to insert them into each project as they are needed.

We can divide well-done design projects into a discovery phase (where we explore the boundaries of the problem we’re trying to solve), an exploration phase (where we toy with different possible solutions), and a refinement phase (where we choose a direction and fill out the details). (Not everyone does design projects well, but the folks who do end up following these three phases. The ones who don’t, well, they skip one or more of these stages then regret it later. Or maybe they are unconsciously incompetent.)

Part of the activities in the discovery phase are to gather information about the users of the design and what they’ll need. We can do that with fancy-ass research or we can do it by just collecting all our thoughts about what we already know. The more specific we can get each question, the easier they are to answer.

For example, if we were building the part of a clothing e-commerce site that showed the product previews, we’d want to know how people used previews in their shopping. We can make guesses or ask our peers. Or we can go into the field and study shopping online or in stores.

Now, we can group what we’ve learned about our users into behavioral categories. We might group people who love to match different pieces in one pile, while we group people who prefer to see pre-designed outfits in a different pile. We might group the folks who are matching colors to things they already own in a different pile from people who don’t trust the colors they see and will use the free 90-day return period to ship back products they don’t like.

These different groups become the persona clusters. And the things people did in those groups become our scenarios. If we’ve done a good job of collecting our data and knowledge about the users, it should be quick to create these personas around this specific functionality. Less than a day, in fact.

And there we have it: Detailed personas about using previews. There’s probably a ton of design decisions these personas can now help us answer. (And where they can’t, well, that points out for a little more research.)

At the end of the project, when our preview module is out there and being used, well, the personas aren’t that useful anymore. But because only spent a day on them, we don’t need to “protect our investment.” We just toss them out and create new ones for the next project.

There you have it: cheap and easy disposable personas.

Design reviews can result in conflicting lists of stakeholder feedback and out-of-scope ideas about what the design should be. Bruised egos, longer timelines, and higher budgets are often par for the course.

Adam Connor builds design consensus naturally by running a Studio, which structures team brainstorming early in the process, then uses sketching, presentation, and critique activities to get everyone moving toward a shared vision. Before long, you’ll be running faster among a team of happy people — and you’ll all be building better products, too.

You’ll Learn to:

• Solve problems as a team
• Generate ideas during a Studio
• Build consensus around a shared idea
• Use critique at the “right” times

Special Offer – Register by May 31 and immediately get access to Adam’s first seminar, Discussing Design: The Art of Critique.

How do I know this? Because cheese in bread, cookie dough in ice cream, and Genius Bars inside Apple stores are AMAZING.

These are just a few examples of innovation that create great user experiences. They’re creative ways of putting existing things together in new ways that add real value to users’ lives.

So that’s what our fabulous lineup of presenters will be focusing on at UI18. They’ll tackle innovation in UX design from a variety of angles.

Scott Berkun will talk about what it takes to enable innovation in the first place — from thinking creatively to managing projects, egos, and business risks. You’ll hear how to lay a foundation for developing seriously great ideas and persuading teams and management to get onboard.

Get to know your users with Christine Perfetti. Her 90-day user-research plan is perfect for organizations hungry to find opportunities to innovate. You’ll learn to recruit participants, design tasks for them, organize field studies, present the data in terms stakeholders will love.

With Kevin Hoffman, you’ll find out how to structure meetings so the creative minds on your team can rally behind powerful, innovative ideas. He’ll show you a bunch of frameworks to encourage ideas from everyone and weigh business risks before jumping to design.

Adam Connor and Aaron Irizarry will focus on building consensus around innovative design ideas through sketching, studios, and critiques. If you’ve ever experienced a “swoop and poop” of a stakeholder steamrolling ideas late in the game, then get in this workshop ASAP.

Jeff Gothelf is the leading voice behind Lean UX, a methodology to break ideas into bite-sized chunks that can be prototyped and tested super fast. See how to re-invigorate your design team and get to innovations faster, all by taking a scientific approach to design that minimizes risk.

Kim Goodwin will get your team on the innovation train, too. You’ll see how to map your user’s journey, then sketch with project managers to collaboratively define requirements. She’ll also talk about “minding the gap” in the UX across devices and within your organizational silos.

Dig deep into design details with Dan Saffer. He’ll show tons of examples of micro-interactions that delight users in unexpected, innovative ways. You’ll experiment with different types of triggers and feedback loops, then set realistic rules for your experiences to follow.

If you’re ever needed to design a data visualization or infographic, then Stephen Anderson’s workshop is up your alley. He’ll show you how innovative data interpretation can be; when you help users understand your story in new ways, they repay you in action and engagement.

Each of these fabulous presenters knows how to add real value to their users’ lives. And with their help, you’ll see which tools and processes you can use to make innovation happen.

With so many ways to measure our impact, why spend any more time trying to invent a better mousetrap?

Don’t just invent a better mousetrap. Come to UI18.

Here’s an excerpt from the article:

But with the opportunities of publishing come immense challenges. Don’t just write; write well. Don’t just blog once; maintain a schedule. Don’t just launch an app; ensure your content is appropriate for the many contexts and devices through which it may appear. And goodness, don’t just curate content by choosing keywords and automating aggregation; hone your perspective on the topic and continually revisit your collection to maintain its relevance.

Read the article: How Content Strategy Can Help.

How do you prioritize the content you create for your web site and blog? Let us know below.

That’s the power of good content that guides us, helps us focus, and encourages us to explore: it helps us make better choices and have more positive memories of an experience.

Margot Bloomstein knows which companies use content to control and focus users’ attention. In Controlling the Pace of UX with Content Strategy, she’ll tell you how those brands structure conversations to help their target audiences make decisions. With Margot as your guide, you’ll start identifying the content hurdles that are preventing your users from feeling satisfied.

You’ll learn:

• Determine if “slow content” is right for your company
• Balance your brand voice with your users’ needs
• Map interesting paths that encourage your users to learn
• Help your users make decisions more confidently

If you know your company can do a better job of communicating with and engaging its users, then don’t miss this seminar.

Here at UIE we’ve amassed quite a library, and we’re adding to it all the time. One of the more recent additions is Margot Bloomstein’s book Content Strategy at Work. Margot is a fixture at conferences like Confab and the IA Summit. She’s also a veteran of our Virtual Seminar program having presented Combining Curation with Your Content Strategy and returning May 30 with Controlling the Pace of UX with Content Strategy.

The subtitle of Margot’s book is “Real-World Stories to Strengthen Every Interactive Project” and in keeping with that idea, it is chock full of case studies and practical examples. Adam Churchill catches up with Margot to discuss her book in this podcast.

Recorded: May, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone. At UIE, we’re lucky to work with lots of wonderful topic experts and often get a peek at their books as soon as they hit the bookshelves. One that was published over a year ago, a book that’s still getting a lot of buzz, is Margot Bloomstein’s “Content Strategy at Work.”

If you look it up on Amazon, the reviews are awesome. Just some tidbits I’ll share. “It shows the reader how to create a unique, clear, and distinctive online voice and visual language.” Another person shared that “it’s a resource that helps people build modern business in the modern times.”

The last one that I saw that I thought was interesting just summarized it nicely, which is, “The book is comprised of stories, not theories, and the stories illustrate the importance of content and highlights the need for strategy to govern the creation, management, delivery, and presentation of that content.”

Margot was kind enough, on super-short notice, to agree to speak with me about the book, and we’re recording it, so you can listen in to hear what she has to say. Hi, Margot.

Margot Bloomstein: Hi there. Thanks so much for reaching out to me.

Adam: We love the book. The subtitle of the book is, “Real-World Stories to Strengthen Every Interactive Project.” Talk about these case studies in the book. For folks that pick up a copy, are there how-tos associated with those case studies that they can put into play immediately?

Margot: Definitely. Thank you for calling out the subtitle. That it’s for every interactive project, because that’s definitely my meaning with content strategy. I think that it does apply to every sort of interactive engagement, whether you’re in an agency or in an in-house marketing department or if you’re a consulting or whatever.

Oftentimes, I’ve heard from folks, “Content strategy doesn’t really apply on our project because we only have a small budget and we’re not creating that much content,” or “I’m working on an application, so we don’t have a lot of marketing content in it,” or “This is really dry. It’s for the government. We don’t really have consumers as a retail brand might have, so it doesn’t really apply to us.”

Those are common complaints, and I think that they’re all bogus, [laughs] because content strategy does apply to all of those cases and a lot of others. That’s one of the reasons why I wrote the book, because I was sick of hearing people say, “We don’t have a lot of budget. We can’t afford strategy,” or “We don’t have a lot of copy in an application, so we don’t really need content strategy.”

It’s in those cases, when you’re dealing with a lot of constraints, where you don’t have the time or the luxury to make mistakes with your content. Every word or every image has to be spot-on. It has to work over time. I think that’s why you really need to nail the strategy behind it before you go out and start writing it or shooting it or commissioning it or curating it from other sources.

I guess I was kind of sick of hearing cases of, “Our project is too small,” or “Our brand really isn’t that sexy.” I wanted to say, no, here’s a lot of examples of brands that maybe aren’t consumer-facing or had really small budgets, or aren’t working with a lot of copy, but because every word mattered, every word in the error messaging and the instructional copy and then how they would evolve those concepts over time, because it all matters, they needed to understand the strategy behind it and their hierarchy of communication goals.

Those are the case studies that we collected here.

Adam: You’re obviously getting a lot of feedback on the book, and we know people are telling you that they love it. Are they telling you why? What are the reasons that they’re so excited about the book?

Margot: I think the high-quality paper on which it’s printed means a lot…

[laughter]

Margot: No. Thanks for calling that out. I’ve been hearing a lot of great feedback from people, and I always like to say that relevance is the best compliment. There have been several cases now where maybe I’m doing a book signing at a conference or something like that, and someone comes up to me with their copy of the book and they’ve jammed it full of Post-It notes.

They flip through it and they’ve underlined stuff and there’s a ton of highlighting in it. I love that, because it means they’re really using it. They’re treating it sort of like a consumable textbook.

There are certainly books that I do that with. I actually just tweeted the other day that Sara Wachter-Boettcher’s book, “Content Everywhere,” that’s become such a resource for me. I can tell that it is, because I’m not just reading it — I’m using it — and I’ve got a million and one notes in it because it has been so useful.

I’ve been hearing from folks that “Content Strategy at Work” has that same sort of utility for them. There are a lot of examples in it. A lot of the exercises that I’ve developed over the past decade that I do with my clients. I share them in the book.

I also wanted people to hear, not just from me, because there are a lot of different ways to practice content strategy. I interviewed probably upwards of 20 or so different organizations about how they practice content strategy, both with their clients or as brands themselves and collected a lot of those methods that they shared in here as well.

Frequently, I do hear feedback on the brand attributes exercise that’s in there. It’s a card-sorting exercise that I do with many organizations. A lot of people have adopted it, making their own. I spell out in there the process behind it and some other techniques to get at the same information.

I share a lot about how I conduct the content audit in there that is driven by a message architecture that’s both qualitative and quantitative. There are some examples of it in there and some example templates and all the help guided.

I hear from folks a lot about those two techniques, especially.

Adam: What chapter people tell you that they’re opening up to most often?

Margot: I would say, again, going back to how to conduct that brand attribute exercise, how to conduct a card-sorting exercise to get at a message architecture. I think that that’s in…That’s in chapter two there.

Adam: Yeah, that’s early on. What caught me, lots of great pictures of people doing the exercise. Always helpful.

Margot: I feel like it’s one of those techniques that you can appreciate it or learn how to do it at a few different levels. The more times you do it with your own organization or your own clients, of course, you learn other skills. You have those little epiphanies of like, “Oh, maybe I should phrase a particular question this way or do this with my body language.”

I try to capture that in the book as well because I’ve learned, by doing it over many years, there are some times when you’re working with a client where you should be standing because it presents an idea in a certain way. Other times, like I’m doing this exercise where I try to remain sitting and I don’t touch the cards that they’re sorting because I want them to feel, both literally and figuratively, a very hands-on relationship with their brand attributes.

I try to include some of those techniques and starter questions and type of thing in that chapter.

Adam: Margot, chapter seven is called “Grounding Social Media and Content Strategy.” What kind of things were you seeing that led to the need for that chapter? How are the solutions that you provided…How are they helping people in their project work?

Margot: I’ve heard from clients, here and there over the past several years, that more and more, organizations get content strategy. They’ve heard the term for awhile now. They understand it, hopefully, as more than just a buzz word.

They realize that they need some sort of guidance to help all of their communication, be more cohesive and consistent so that their target audience, whether it’s hopes that are going to governmental website or people looking to buy a product or get information about what time a flight is landing. Whatever that is, whatever channel those users are interacting with, they expect to be consistent with other channels that the brand also produces.

They expect to use similar language, whether they’re interacting with them through their main core website or a mobile app or maybe their Twitter account or Facebook profile or on Pinterest. They expect a certain level of consistency.

But, what I was starting to hear from organizations were questions like, “We get our editorial style guidelines. We understand our goals in there, some of our different communication goals, but do they really apply in Twitter, like when we’re working with 140 characters or less?” I’d always be a little bit surprised when I would hear that. I’d have to push back and say, “Yes, those same guidelines do apply.”

Then it kind of goes back to that core principle of content strategy. That when you’re working with less content, in the case of Twitter when you’re working with very constrained copy, every word and the choices you make around grammar and how you abbreviate those words, and if you structure things with short sentences, maybe leading with a short question or a parenthetical aside, all of those things matter that much more when you’re only dealing with 140 characters or maybe only 120 characters, if you want to be re-tweeted.

I was hearing questions like that. Then also hearing from brands that were saying, “We know that we need to make this investment in Facebook and in Twitter and whatever other platforms are coming up. Should we be developing more of a presence through Foursquare or even a few year ago through Gowalla? Should we be developing trips and that type of thing? What about now, Pinterest?

It raises that issue that so many social media strategists’ and consultants are familiar with, that social media isn’t free, but it is so tempting. It’s just a different kind of expensive in that it demands your investment of time and attention and creativity that many organizations are taxed to apply to other efforts as well.

If you’re going to make that investment of say launching a Facebook campaign or something like that, that you’re also going to have to monitor the comments, engage with the comments and the feedback, continue to feed the beast with new and interesting content that people want to share and help you go viral with it now.

Because of those reasons, social media and those different channels are tempting, but brands have to be able to make good choices around where they make the investment. Maybe they shouldn’t go after everything all at once. Maybe they shouldn’t go after the channels that are most trendy, but how do they choose the channels that will align best with their communication goals and maybe the specific talents they already have in house and their overall editorial style and tone?

In that chapter, I try to help them answer those questions so that again, if you’re a social media strategist reading it, you can bring that sort of sensibility and that content strategy mindset into your work as well.

Adam: The final chapter in the book talks about content getting a seat at the table. How do you think the book helps people accomplish that?

Margot: I’ve heard from a number of people that have read it that have been kind enough to share their feedback. One, that it makes them more confident about the processes that they’ve been developing in their own work.

I think, for many people that come to content strategy, we have that sort of aha moment that maybe, several years ago, or for some people, just several months ago. It was that feeling of, like, wait a second, there are other people that do what I do.

Maybe we don’t all call it content strategy. Maybe we used different terms for our process of auditing content and assessing it, all those types of things. But we’re applying a similar process, and we’re coming to the problems of online and in cases, offline communication. We’re coming to those problems with similar questions and challenges that we bring to our clients and all.

I think for a lot of people, reading this gives them, A, both the confidence that, “Hey, you’re asking the right questions,” and B, the confidence to ask other questions, and bigger questions, and maybe align those questions in a process.

In that chapter, when we talk about content getting a seat at the table, I think it’s because for a long time, for many years, we were hearing about the challenges of content and how, in many projects, we didn’t scope them correctly. We forgot to say, “Content is really the reason why people will be coming to this website.”

Are we allocating enough budget and the right sort of resources and talents to creating it or curating it or aggregating it from other sources? Are we thinking about it early and often enough in the process?

By and large, what I was seeing is that content needs a seat at the table from the get go. In other words, when we’re putting together project plans and proposals, we need to be thinking about, how does content strategy fit into this? Then, it’s more tactical execution of copy writing or content marketing, or maybe we need to commission photography.

Are we always allocating the right time and space in the process to think about those things?

I’m hearing from folks that by going through the different processes in the book with whatever they’re already doing, whether they are content strategists or copywriters looking to up their game or project managers looking to make sure they’re bringing content strategy into the process at the right time and assuring the right touch points.

Or if they’re SEO folks or designers or user experience architects, whoever they are. I’ve been hearing from them that this is giving them kind of the confidence and the bigger sense of the process to really adapt what they are doing and help it continue to grow and mature.

Adam: Very cool. The book is wonderful, nice job. It’s from the fine folks at Morgan Kaufmann and again, it’s called “Content Strategy at Work: Real-World Stories to Strengthen Every Interactive Project,” and it’s written by one of our favorite people, Margot Bloomstein.

Margot: Thank you so much, Adam.

Adam: Thanks everyone for listening in. Goodbye for now.

As I’ve mentioned before, I’m a big fan of Lou Adler’s Hire with Your Head recruiting strategy. A big component of how Lou approaches hiring is the interview conversation. While Lou isn’t thinking of hiring designers specifically, it turns out his approach is perfect for the folks who will thrive in your environment and produce great work.

The question is a simple one: “What’s the project you worked on that you’re most proud of?” Now, this isn’t the only question you ask during the interview, just the first one.

Once the candidate tells you their project, you ask them to explain what it was they were trying to do. Then you ask them how the project started.

You can then ask them who else was involved. Design is a team sport and I love having candidates draw org charts of their projects. Then I ask them to tell me who else was involved and what everyone’s contribution was. It helps identify how much of a team player the candidate is and how they dealt with whatever people issues arose.

Anything you want to know about their skills, talents, and contributions can come from that first initial question. Because it’s starting with something they are proud of, I’ve found candidates are more open and honest about what they did.

It also becomes easy to see where a candidate has depth and where they are only skimming on the important qualities. A great candidate can dive into details of their best accomplishment and show what it was all about. Someone who wants to say “I was involved” when they really weren’t starts to stumble and pause when you get to the followup questions.

This one question gets to the core of behavioral interviews, where you look at the past behavior of the candidate to best predict how they’ll work out on your team. Because designers repeat the work habits they learn throughout their career, understanding the details how they’ve worked in the past can tell you a ton about how they’ll work with you.

This year’s speaker line-up will make you look at UX like you’ve never had before.

Kevin Hoffman – Leading Super Productive Productive Meetings

Stephen Anderson – Helping Users Understand Your Data

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Scott Berkun – Innovating on a Deadline

Adam Connor and Aaron Irizarry – Building Consensus in Critiques and Design Studios

Dan Saffer – Designing Micro-Interactions

Jeff Gothelf – Escaping Product Requirement Hell Using Lean UX

Christine Perfetti – Jumpstart Your UX Research Program

Get a Jump on Registration

We only have 125 spots at the $1,389 price. Last year those discounted seats went fast and the conference did sell out.

When you sign-up for the UI18 list, you’ll get first crack at registering for the conference. On Wednesday morning, May 15 you’ll receive a special email with a link that allows you to register. Everyone else will have to wait until Thursday afternoon, May 16.

Get your approvals now and get ready to register.

Explore the Conference at UICONF.com

Here’s an excerpt from the article:

Good interaction design is about attending to every moment that passes between a person and the device (or system, or service) with which he or she is interacting. These moments can be explicit, as with gestures, taps, a button-click, or the completion of a form field. Or, these moments may be more elusive, such as a pause while you try and understand what is being asked of you or how to answer. It’s these internal conversations that users have at any given moment that often get overlooked.

Read the article: UX Design, Role-playing & Micromoments.

What micro-moments have your experiences that added to — or diminished — your experience with a design? Lets us know below.

Even though you might be tempted to use a new tool to work on a new design, I think that’s a bad idea. Instead, I think you should set aside some time to redo an old project or mimic an existing design using the new tool. Grab a challenging interaction from your existing product, copy a cool design you use every day, or take the last prototype you built and rebuild it in the new tool.

Learning a new tool or technique takes full attention. Yet, coming up with new design ideas and approaches also takes full attention. Why divide the attention? If your goal is to master a new tool, make the investment to do just that.

Give yourself the time to learn and experiment with the new tool. Pick a design you’re very familiar with and practicing rebuilding it. Remove the need to concentrate on what makes the design good and focus on how you emulate it with this new tool.

Make the practice session all about learning the ins-and-outs of the new tool. Play with the different methods for rendering and simulation.

Take time to practice the techniques for prototyping before you need to put them into action on a real project. (And if you haven’t used a tool in a while, practice that too.)

Other thoughts on prototyping:

• Prototyping’s Resurgence: Communicating the Designer’s Intent
• Five Prevalent Pitfalls when Prototyping

Micro-moments are the smallest units of interaction in an online experience. Do you want to find your micro-moments and make frictionless experiences from them? Of course you do!

Consider Stephen Anderson your Sherlock Holmes, because he’s the detective who identifies micro-moments and maps them to bigger customer journeys. He’ll tell you how to design interactions as conversations that you can anticipate and direct. Plus, you’ll learn how to integrate micro-moment design into your existing workflow.

Sign your team up today!

Here’s an excerpt from the article:

Prototypes are a fabulous way to exploring ideas with a team. They shorten the time between “This is what we’re thinking…” and “Oh, I get it.”

In our work with design teams, we see a lot of teams using prototypes today. We’re also seeing many of those same teams fall into traps that reduce the effectiveness of their prototyping efforts. Here’s five of the most common ones we see.

Read the article: Five Prevalent Pitfalls when Prototyping.

Have you run into any of the problems discussed in the article, and how did you resolve them? Let us know below.

This podcast is the recording of Jared’s keynote from UX Thursday Chicago.

The world of web application design is expanding at a rapid rate. We’re now expected to design great experiences across a huge variety of platforms, from small screens to large displays. The flood of iPad applications and successful online businesses are showing our executives that design matters.

Why is all this happening now? Where is it all going? UIE’s own Jared Spool will show you how four driving forces — market maturity, the emergence of experience, the Kano Model, and Sturgeon’s Law — are increasing the visibility and value of design in organizations everywhere. He’ll show you what the next generation of design teams will look like and how you’ll get there.

Recorded: January, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: A few years back, we started noticing a major shift in the world of user experience. Now, a lot of it had to do with mobile, because before, there were only a handful of phones that could bring up a website or do anything interesting, so mobile was not really part of anybody’s landscape. But the iPhone comes out, everything changes.

That shift was fundamental, and we tried to understand why all of a sudden we were getting questions and requests for things that we never got before in a major way. What we realized was that there was something happening, something that was just these sort of natural forces that were coming from all directions and pulling together.

What I thought I would start today with is setting out what these changes are and why all of a sudden we’re in the center of this storm that we didn’t realize we were in until we got there. To do that, I want to start by talking about this.

This is a bottle of Coke. What’s interesting about this bottle of Coke, for my purposes right now, is that red cap, because if you ever get a bottle of Coke with that red cap, underneath it is a 12-letter code that you can then use to go to mycokerewards.com. When you go there and you enter the 12-letter code, you get points.

When you accrue enough points from getting enough red caps, you can get all sorts of prizes, like luggage or video games or, if you want, more Coke. It’s a very cool loyalty program, and a lot of people take advantage of it.

When it first came out, this is the desktop view. If you happen to go on a phone, it would look like this. I don’t know if you can read this, but it says, “Sorry, you don’t have Flash,” and then proceeds to tell you that you need to download Flash to continue. If you’re on an iPhone, you can download Flash all you want, but you ain’t going to continue.

Now, the question I had at the time was, how likely is it that when you open that bottle of Coke, you’d be closer to your desktop system than to your phone? Chances are, most of the time, you’re going to be closer to the phone. This is a failure. This is a failure case.

Maybe Coke’s just not jiggy with the Internet world, so they don’t quite get this. What about other folks? What happens there? About the same time, if you went to Fox News’s weather site, you got a similar screen that said, “Alternate HTML content should be placed here.” I hope you brought some.

[laughter]

Jared: Then it goes on to tell you that you need to download the Flash player, which you can try and do, but it ain’t going to do nothing.

It isn’t just this sort of thing that happened. I was wandering through Washington DC and came upon this sign taped to a telephone pole. It says, “Mike Panetta, shadow representative.” I was very excited to see this because, while I always suspected that we had a shadow government in Washington DC, I didn’t realize they ran for office. Sort of defeats the purpose, doesn’t it?

What was really interesting was in the bottom it had a QR code. I’m like, “OK, let’s check out what the shadow government’s all about.” I click on the QR code to see what I would get, and interestingly enough, I get a website that’s not optimized for a phone. It just gives me a corner of it. The rest of the site is hidden — I guess, like a shadow government.

This, to me, seemed a bit odd. It’s not just here. I was in Lapeer County, Michigan. I don’t know why, but I was there, and I walked into the Lapeer County Bank and Trust Company, one of their branches, and there was this sign that said, “Let your fingers do the banking.” What stunned me was that apparently you can bring up their website on a 1990s Nokia phone.

It renders perfectly on that old phone. Of course I wanted to see what it looked like on my brand-new iPhone, and unfortunately, it doesn’t look like anything you can use on an iPhone. It’s got this desktop website with a big hole for where the Flash thing is supposed to go, and the rest of it is completely unreadable at normal phone sizes.

We were doing an event in one of the Marriotts, and we needed people to be able to connect into the Internet there. The way you’re supposed to do that is you bring up this screen that you barely can read, and you’re supposed to click on that little red thing up there, and then, when you click on that, you get another screen of stuff that you barely can read.

You don’t do anything with this first clump or that second clump, but it’s the third clump where you have to enter the conference code that was supplied to you to get access to the Internet on your phone.

None of these experiences are very good, particularly for people who are just trying out using the Web on their phone. I was trying to figure out, why is it that so many of these experiences were bad? What we came to realize was that this is a force that’s happening to us. It’s something known as Sturgeon’s law.

Now, for those of you who’ve never heard of Sturgeon’s law, Sturgeon’s law is named after a dude, Theodore Sturgeon. He’s a science-fiction author. He was at a conference on a panel, and there was a Q&A. In the Q&A, a reporter gets up, and he goes to the mike and he asks, “Dr. Sturgeon, why is it that so much science-fiction writing is crap? Why is 90 percent of science-fiction writing crap?”

Dr. Sturgeon thinks about this for a moment, and he replies, “90 percent of everything is crap.” This is what’s known as Sturgeon’s law — 90 percent of everything is crap. It turns out that that’s completely true. It’s measurable. You can go out and measure practically anything, and you will find that 90 percent of it is complete crap and only 10 percent of it is any good whatsoever.

Take, for example, this email that came from United one day. Now, this was their first forays into HTML email, so this is the first time that I got this beautifully formatted, gorgeous email from them. I was very excited, because they had this feature in the email that I’d never seen in any of their emails before. It was this thing that said, “My account.”

I could go check on my account. I wanted to do that, so I clicked on it, minutes after the email had come in, and I got this message. It says, “No, you did not make a mistake,” which I found completely reassuring, because almost every other time I deal with United, I always feel like I’ve made a mistake.

In this instance, I apparently did not. It says, “We’ve designed our website. Unfortunately, the URL you requested is no longer valid.” The email just came out! They expire their content really fast. That’s quite a content-management strategy. They really govern their management well, because this is quick.

Now, granted, this is from a company that thinks about things in a way that no one else does. For instance, they were the first airline to provide their airline status boards for both portrait and landscape people.

[laughter]

Jared: Just saying.

Let’s take a moment and go back to our friends at Coke, because it’s unfair that I showed this, because they, within a couple of years, updated from this to something that looked like this which is an improvement — you can actually see the site. But it’s still basically a desktop site in a tiny screen.

The problem is that if I want to enter that code, I have to enter it over here. It’s almost impossible to tell that it’s grayed-out — it’s actually not grayed-out, it’s shaded-of-red-out. In order to unshade-of-red it, I have to either log in here or register here.

Of course, you can’t read this on a normal screen. Of course, you can pinch-zoom, but you have to know where to pinch-zoom to be able to do this, and so it’s a very unfriendly experience.

Maybe the problem is that this is a soda company, not a technology company. If we looked at a company that was, let’s say, in the phone business, like Verizon Wireless, they wouldn’t make that mistake, would they? Oh, yes, they would. This is Verizon Wireless before they had the iPhone, so maybe it’s just they’re not used to iPhones, they’re just used to other things.

Yet, sure enough, AT&T’s iPhone page has the same problem. In fact, Apple’s iPhone page has the same problem.

If you have an iPhone, why would you need to go to the iPhone page? I don’t know. This is the issue. This whole idea of small things.

Let’s say you’ve decided to fly somewhere in Canada — Toronto, maybe. There’s a good conference next week. I’m going to Toronto. Let’s say you decided to fly there. You want to check in. You’re in the cab, you want to check in on your way to the airport. You go to Air Canada’s website, and you get a tiny little screen.

Then you have to go and click on this little button here, which then makes you choose between every country in the world as to where you’re flying from. Even though the phone knows which country it’s in right now, it still requires you to scroll through every one to get to the right one. Then you get this screen that is completely unusable on a phone to be able to check in.

I can go on, just keep showing you bad example after bad example, but there are good examples. Ironically, one of them comes from Boston.com. Boston.com, for us, has been the poster child of bad design since the 1990s. We wrote about it in our first book, “Website Usability — A Designer’s Guide.” It has all these classic usability issues for websites.

They really haven’t updated since they first launched in the ’90s, so it continues to have the same problems.

If you go to their phone, mobile thing, it’s actually awesome. It’s very readable. You can find the top stories. It’s not cluttered with a lot of ads. It’s a very good experience. It is possible to do this. “New York Times” actually followed suit after Boston.com did, and now there’s a handful of folks, like these guys, who have really great mobile experiences. 10 percent.

Now, here’s the thing about Sturgeon’s law. We’re the ones who get to decide which side of the equation we’re on. Do we want to be in the 90 percent group, or do we want to be in the 10 percent group? That’s a choice we get to make.

The deal is that it’s happening at the board-room level. All these executives now walk around with their iPads. They are quite excited to have this technology. They prance into meetings with their iPads and they bring up stuff, and then they bring up the company’s own stuff and they’re like, “How come this doesn’t work?” You can say, “Oh, it’s Sturgeon’s law. We picked the wrong side.”

That pressure to move to the other side, to move into the 10 percent, is now the big deal. That’s what people want. This idea that we want to be in that 10 percent, this is one of these forces that is causing UX to emerge as an important thing amongst the executive team, and it’s causing it to be a high priority.

It turns out that there’s something else. What we call that is market maturity. The way market maturity works is this. This is a Wang 2200 word processor, was first produced in 1977. It’s a device that stands yay tall, yay wide, yay deep, and all it can do is word-process. It costs $14,000 just to word-process.

Just out of curiosity, how many people here weren’t even born in 1977? That’s depressing.

[laughter]

Jared: I worked on this thing. It’s one thing to be the oldest guy in the room. It’s another thing to have projects that are older than half the people in the room. This is on my résumé’.

[laughter]

Jared: The thing about this device, it was completely unusable. There was no way to just walk up and use it. If you wanted to learn how to use it, you had to fly to Lowell, Massachusetts, to a building complex known as the Wang Towers. I can’t make these things up.

You would take a one-week class, the beginner class, and in the beginner class, using a training method known as “drill and practice.” You would repeatedly learn how to load a file, how to save a file, how to print a file, and how to change the ribbon. That was week one. The advanced class, week two, if you stayed for it, you would learn bold and italics.

Italics was tricky because you had to change the little print wheel on the printer to get the italics to work and then change it back when the word was done printing to the next word. Yeah, I worked on this thing.

That was the state of the art in 1977. People paid thousands of dollars to get these devices. Then they paid thousands of dollars for training, and then they paid 20 percent more salary to anybody who was trained, because after you spent all that money, you didn’t want them going to some other company to use this device.

You would actually give all these people who were previously just typists out of the typing pool, you would now make them word-processing specialists and you would give them a 20-percent raise just for taking those classes that you paid for.

Everybody was happy. The word-processing specialists were tickled pink, and the companies were happy because they were getting documents way faster than from the typing pool, and the Wang Corporation loved all this training revenue.

Everybody was really excited about this until cheaper versions came out. PCs allowed you to not spend $14,000 on a word processor, but $700 on a word processor. You could get something called WordPerfect. WordPerfect, at its peak, had 1,770 features, in its prime. It had so many features that in order to use this thing.

You had to have these little cardboard things that went on your keyboard and these little cardboard things that went around your monitor and these little cardboard things that went around your bathroom mirror.

[laughter]

Jared: All of these things were there to help you learn this. There were videos and courses and manuals and all of these different things. The entire purpose of all these things was to train you how to use all these 1,700 features.

Then, this little upstart up in the northwest of the country comes along with a little word processor that on the day it was released had 70 features. It was called Word for DOS. Word for DOS became Word for Windows. The folks at WordPerfect, they thought this would never be a threat — they only have 70 features. The deal was they had the right 70 features.

They had studied how people were using word processors. They figured that all of this training was silly, and they came up with something where, whatever you typed on the screen, that’s exactly how it would print. That changed everything.

What we have here are three stages of maturity. We start by the technology. People will pay big bucks for technology because it does something nothing else can do. Then you start to get competitors, and then it all becomes about features. Then you get so many features that no one can use it, and it becomes about experience. We see this pattern over and over and over again.

Now, it’s a cycle, which means, once you’ve kidnapped the market from experience, you have to do something to continue to get upgrades. What do you do? You add features.

[laughter]

Jared: There’s a pattern here, and it happens over and over. Let’s take cellphones. This was the original, Gordon Gecko, massive cellphone. They cost $2,000 and you had to shout into them. “I said..!” It was this massive thing.

Feature phones came next. They called them feature phones because they were all about features. It was all about which phone had the most features. Then this little upstart, who’d never been in the phone business before, came out with a phone that changed everything, because it offered a better experience — with less features.

When the iPhone first came out, you couldn’t do video, which was as common feature of all the feature phones. You couldn’t send pictures through text messages. It was missing major features that were being promoted and everybody thought you couldn’t have a phone without. Yet, a better experience trumps features. We see this over and over again.

This was AltaVista. A search engine is obviously based on features. So much so that the search box was really hard to find. It was all about this other stuff. Then a little upstart in the Valley comes out with just a single box — two, actually, which was “get on our email list.” I don’t know what happened to that.

[laughter]

Jared: They took that feature out. Now, they just have the single box.

If you go to accuweather.com, these are all the things…Actually, it’s not all the things. I couldn’t fit all the things on one screen. There are two more screens of this. They keep adding this stuff, because they have to give you a reason to come back, so they have to add something new and add something new and add something new. It’s all about the features of the website.

What do you really need from a weather site? Here’s a site called “Umbrella Today?” You type in the city and it says, “Yes.”

[laughter]

Jared: What else do you need, really? That’s it. This is all it does.

This is that Air Canada site. If we look closely, we see that it, too, has a tremendous number of features. It’s got all this stuff. The airline only goes to like seven cities. It’s all they have in Canada. There’s not that much to this airline, but it’s a big, rich thing.

When you bring it up on the phone, they’ve crammed it all in. It turns out there’s another way to do it. If you know the magic code, if you know to type in m.aircanada.com, you get a completely different experience — one that’s circa 2001, but you get a completely different experience.

This experience is far more usable, even though it’s dated, than this modern-looking Web page on the same device, but you have to know the magic code to be able to get access to that.

This one is crammed with features, but the other one has got lots of experience. Or this. If you try and go to San Francisco and get on the BART from the San Francisco Airport, and you just type “BART schedule” into it, this is what you get, this massive chart that was never designed for the phone. I’m not sure it was designed for anything, actually.

This is a completely unusable thing, unless you’re smart enough to type in the magic code, which is bart.gov/wireless. Then you get an absolutely usable experience for this.

You don’t have to have the magic codes. If you go to Amazon, you get something that looks like the Amazon website but not quite. If you were to hold them up side-by-side, desktop, mobile, they are distinctly different. If you’re on the mobile and you’re used to the desktop, you won’t really pay attention to those differences, because it does all the things you need it to do.

It’s got all those features, but it’s been pruned back to the ones you really need, the ones you’re most likely to want. It has just those features.

Now, you can actually go and do all the important stuff, such as search by an author and find a book and look at the summary of the reviews and actually go look at individual reviews. Again, each of these things are very different than the way they appear on the website, but they’re familiar enough that you have no trouble actually using them because they do exactly what the user expects to do.

This isn’t about consistency. It’s about expectation. Consistency is not important in design. Meeting expectations is very important in design. Meeting expectations doesn’t mean making it consistent. It means making it work the way I expect. I expect to be able to get to reviews, but I don’t care how consistent they are.

I don’t actually want the phone reviews on the phone to work exactly like the phone reviews on the desktop. I just want them to be as useful as the ones on the desktop, and that’s a different requirement.

Take bestbuy.com. Best Buy, if you go there, they have this feature to find the TV of your dreams. You can go in and put in a little information about the price range and what stores you might want to shop at, and then it has these really cool sliders that you can use with your fingers to talk about the price range and the type you want, and it goes and recommends a phone.

This is actually way easier to do on your phone than to do on their desktop site. They don’t have this functionality on their desktop site. It doesn’t work nearly as well. This is actually pretty cool, that you can do this on the phone in that regard.

This idea, that we go from technology to features to experience, that progression happens over and over. The deal is that whoever was the leader at that feature thing, most of the time, 90 percent of the time, they do not successfully make the transition to being the leader in the experience thing, because their code base is too big, because they’re too wedded to all those features, because they don’t believe competitors will catch up.

Yet, almost always, somebody new, who doesn’t have the ugly code base to deal with, who knows exactly what users need because they’re watching people actually use these things and get frustrated with it, they actually come out with something that’s a better experience, and they end up kidnapping the market.

That shift, from features to experience, is critical. That turns out to be our second force coming into the storm. We’re feeling it, because a lot of us are in the feature mode and their customers are moving to the experience part of the marketplace.

This doesn’t explain the whole thing. There’s something else coming in, and the words we have for that we call the distinction between activity and experience.

This is a map of Six Flags Magic Mountain. It’s a theme park in Southern California. It’s like almost every Six Flags park, in that they have 48 different attractions, they call them, rides, and a whole bunch of other things you can do there.

They have carefully laid out a checklist of everything you can do. You come in from the bottom, you head up in clockwise formation, and it’s all about having this experience where you get to do everything on the map. That’s what you’ve paid for, that’s what they want you to do. They want you to be able to almost check it off as you do the whole thing. They don’t want you to miss a second of it.

They want you to go stand in line and then get on one of their awesome rides and then throw up and then get back in another line and go on another awesome ride and then throw up. That’s the Six Flags experience, and everybody’s happy with that.

The map represents the way they think about that. Compare this map to Walt Disney’s Magic Kingdom. Walt Disney’s Magic Kingdom doesn’t have all the rides. In fact, it doesn’t have any of the rides. If you are familiar with the architectural elements of the rides, you might pick out things like Space Mountain.

But if you didn’t know what Space Mountain was — it’s not labeled — you wouldn’t know that’s a ride. The park sort of obscures that in the map, because that’s not how Disney thinks about it. Now, granted, Disney has great rides. This park has 78 fabulous, cool rides. It’s not that they’re lacking in this or they’re trying to hide that fact. They just think about it completely differently.

If you were to bring, let’s say, a six-year-old to Disney, there’s a very good chance that one of your days while you were there is going to start with an event known as the Character Breakfast. The Character Breakfast is an opportunity for your six-year-old to get up close and personal to a creepy guy in an animal costume, for which they then go about making breakfast together — what will be, in fact, the most expensive breakfast you will ever pay for.

The kid will love it, and you will love it — and I think the guy in the animal suit likes it, too.

[laughter]

Jared: It’s fabulous. That’s how your day starts, and then you wander into the park and you have an experience. You have an adventure that you just wander from one part to the next. They’re almost seamless, and every step of the way, it’s this wonderful adventure.

Finally, before you know it, the sun has gone down and everybody gathers and the fireworks start, for what is, in fact, the longest fireworks show you will ever sit through. You go to the fireworks and it goes, and it’s everywhere, and the sound is perfect, wherever you’re standing, because they have the sound perfectly wired through the park and the synchronization of the music to the fireworks is exact, and everything is just perfect.

At the end of this incredibly long fireworks show, you take your six-year-old, who is now completely exhausted, and you put them on your shoulder, and you bring them not back to your hotel room but to your resort, because they don’t have hotel rooms, they have resorts. You bring them back to the resort, and you open the door of your room, and you come to discover that while you were gone, someone has replaced your towels with origami animals.

[laughter]

Jared: That’s the adventure that your day is. If your kid left the toys in the room, the toys have all been arranged around the animals such that it looks like, while you were gone, they were all playing with each other, and then as soon as the humans walk in the room, they all collapse, just like in the movie.

That’s the adventure. They have housekeepers they have trained to make origami animals. Imagine the agency pitch for that. “We know how to make you a lot of money. You need to train all your housekeepers to make origami out of towels. By the way, because your average customer stay is 7 to 10 days, they have to know 10 different animals and keep track of which ones they’ve done in which room. Your housekeepers can handle that, right?” “Si.”

[laughter]

Jared: This is the problem.

Six Flags is all about activities — one ride after the other — but Disney is about experiences. Experiences are the gaps between the activities. They’re designing for all those things that happen between the activities.

That’s where the real competitive difference is now, because everybody has the same activities. If you’re in retail or you’re in finance or you’re in medicine or whatever you’re in, all your competitors are designing for the same activities. It’s those gaps between the activities — what happens between the prescription refills, what happens between the deposits and the withdrawals in your bank — those things are the interesting places to design right now.

Trying to get a cab when it’s amazingly wet out is horrific. What if you could just bring up an app and press a button and summon a cab? That’s what Uber did. They revolutionized the taxi business, creating a little app that lets you summon a car. You press the button, figures out who the closest driver is, sends a message to his app, which is slightly different than your app, that says, “Hey, I’ve got a rider for you. Do you want to take it?”

If he says no, goes to the next car. If he says yes, sends you back a message saying, “Hey, I’ve got you a driver, and he can be here in 10 minutes.” Then you get to watch him approach on the map while he’s coming. Then you get in the car, and that whole ritual that happens at the end? That’s completely redone.

Instead of having to figure out what the prices are and what the added prices are and put a tip on top of that, and figure out if the credit-card machine is working, and it’s probably not working, or the guy doesn’t want you to use it because they keep all the money so he’d rather get paid in cash because then he can keep half the money and not give it back.

You go through that whole ritual, and meanwhile it’s pouring rain out and you’re trying to get to where you want to go. It’s a really awkward thing. That’s all gone.

What we have now is a phone. You press a button that says, “Yes, pay.” By the way, you’re going to rate the driver, which is OK because he just rated you, which is how he’ll know whether he’ll pick you up next time. Oh yeah, tip’s included. It’s automatically charged to your pre-entered card, and the receipt’s put in your email, and you’re done. They’ve filled in the gaps.

Groupon. Anybody who participated in Groupon in the early days knew that one of the more annoying features of Groupon is you’d go to someplace that actually you had a Groupon for and you forgot the piece of paper. What’d they do? They make it so that, either from the mobile website or from the app, you can bring up your copy of your Groupon, and they can just scan the phone or enter the number directly from that, and you’re done.

No more carrying around little sheets of paper that have all your coupons on them. Again, thinking about the gaps in the experience.

This whole QR-code thing, this is part of that. I was walking through Melbourne, Australia. There’s a huge black wall on the side of the street, says, “Live here,” with this giant QR code. It was this big. I scanned it, and it was for this little website. Turns out, on the other side of the wall was a hole in the ground, and in the hole in the ground they were planting a building.

When the building grew up, they wanted people to be able to live in it. You could find out all about the building that they were hoping would grow on the other side of the wall. You could even fill out a nice, easy-to-fill-out form that isn’t complicated to get your answer to that question.

That works. The problem with QR codes is that they have way too many dependencies. This is a series of QR codes that’s buried deep in the subway tunnel in the Denver Airport, where there is no cell reception. Some advertiser — First Bank, I guess — paid a ton of money for ads that nobody can take advantage of, because you can’t look it up. People don’t quite understand that those gaps in the experience, you have to actually pay attention to.

This idea of being competitive in the experiences, that is now a key priority. That’s the third force that’s pushing us in this direction.

The last one we call the Kano model. The Kano model was created by a dude named Noriaki Kano. Behavioral economist in the ’60s actually put this thing together, but turns out it’s absolutely explanatory of what’s going on right now. He was trying to explain the relationship between customer satisfaction and the amount of investment that a company should make.

“If you invest more, do you get more satisfied customers?” That was basically the question he was trying to answer.

In his collection of data, he found that there were three trends that predicted this. To measure that, he put them on two scales. The first scale, of course, is user satisfaction, which goes from frustration at the very bottom to extreme delight at the very top. It’s how to think about satisfaction. The second scale has to do with the amount of investment, from almost nothing to a ton.

When he started to plot the data of this, he started to realize that there were three trends that kept showing up. One’s known as the performance payoff. The performance payoff is what happens when you just keep adding features and you keep investing. Over time, you make customers more and more and more satisfied. If you make a big enough investment, you get them very satisfied. We all understand this. We all understand how this works. This is what drives that feature stage of the maturity model.

There were two other curves that he discovered that turned out to be really important. One is basic expectations. Basic expectations says that however much you invest, you’ll never go above neutral satisfaction, because it’s something we basically expect. We have WiFi at this conference. Used to be, if you had WiFi at a conference, that would be an awesome thing. Everybody would be overjoyed. They’d be absolutely delighted about it.

Now, if you go to a lot of conferences, like I do, and someone has WiFi, it’s like, “Oh, great, they have WiFi.” If they don’t have good WiFi, I get frustrated. But if they have great WiFi, I can never get across neutral satisfaction.

Now, it’s interesting that the way we typically measure satisfaction is with something we call satisfaction surveys. They ask questions like, “Are you satisfied?” “Are you satisfied?” is this neutral line in the center of the scale. We’re asking, “Are you in the middle?” When they say yes, we consider it a win.

Then we wonder why people aren’t that excited, because satisfaction, being satisfied with a design, is like considering a meal edible. “Hey, how was your dinner last night?” “Oh, it was expensive, and boy, it was edible.”

[laughter]

Jared: That’s not good. We wouldn’t be happy with an edible meal. We shouldn’t be happy with a satisfied customer. We should only be happy with extremely delighted customers, which is what brings us to our third trend, which are called excitement generators. Excitement generators are things that delight people. Often, they don’t take much in the way of an investment.

Sometimes it’s just having clever copy or really nice aesthetic, and sometimes you have to invest a little more in some technology. It turns out that you can get these delighters.

There’s an app called Shazam. Hear some music, point the phone at the music, press the big button in the middle, and about 15 seconds later, it tells you what the song is. It’s a bloody miracle. I have no idea how the damn thing works. Listen to one of those commercials where you could care less about the product but the song is really catchy? Point the thing. You’ll learn what song they use in the commercial. It’s awesome.

You often have to get it away from other noises, so you have to get it as close to the speaker as you can if it’s a noisy place. Sometimes, like when you’re in a club or something, the only place to get really good sound is in the restroom. I’ll walk into the men’s room, there are all these people with their phones in the air, pointed at the restroom speaker. “Oh, you’re Shazaming. I’ll step away.”

It’s a really simple thing. It just listens for a second and, boom, it tells you what song it is. It’s really quite clever.

The other day I was landing on a flight at Dulles Airport. While the plane was taxiing, I turned my phone on and I tweeted, “Happy to be at IAD.” Immediately, I got a tweet response from a company called LimoRes that said, “Need a ride from IAD?” and it gave me a little offer code. I thought, “Oh, that’s pretty cool.”

I didn’t actually have a ride at the time, so I thought I’d check them out. Sure enough, they had a website. It was a little small, but I could find the phone number really fast, and that gave me the opportunity to call them. It turned out they had a pretty decent deal. That was delightful to me, and it didn’t take a lot on their part to write a little bot that just looks for people tweeting about landing at IAD and sending this out.

Google Docs. I don’t know if you use Google Docs, but one of the things that are amazing about Google Docs that makes it much better than the previous generation of office tools is the sharing capability. You can easily share documents. Turns out it’s a big deal, and it’s what people love.

When the iPhone capabilities first came out, the iPhone app, it had all the great features of Google Docs except for sharing. You couldn’t share from the phone. Now, how often would you need to? Let’s say you’re standing outside a meeting and it’s like, “Did you get the memo that we’re going to talk about?” “No, I didn’t.” “Oh, let me share that with you.” “Oh, I can’t. I have to go back to my office.”

That’s frustrating. The thing about that frustrating thing is that no matter what Google does, they can never make sharing delightful. It was delightful at first, but it’s not delightful anymore. Now we just expect to be able to share everything we have in Google Docs. All they can do is frustrate us.

It turns out that this is where a lot of folks get into trouble, because they focus on delighters and they don’t realize that if you don’t have the basic expectations met, you will frustrate. When I check into a hotel, I expect there, in my hotel room, to be a bathroom. In that bathroom, I expect it to have hot water in the shower and a toilet that flushes and a sink that I can shave at. I don’t ask for much, I don’t think.

Generations ago — it’s maybe two generations — my grandfather could not make that expectation coming to a hotel room. Most of the hotel rooms in the world in his time did not have bathrooms in the room with a hot shower and a working toilet and someplace they could shave. You had to go down to a community bathroom down the hall, if you were lucky, because sometimes you had to go outside. That distinction is new.

The thing is, if the toilet doesn’t work, I’m going to get pissed at the hotel, but if the toilet works perfectly, I will not be delighted with that hotel. I can never get above basic expectations. A lot of the problems we see is that we are constantly missing basic expectations because we’re not studying them. We’re not discovering that we’re missing them. We’re frustrating our customers, and we’re working on this delightful stuff.

Here we are. Time to register for our Coke rewards. I click on the little registration button, and I have to then say, “OK, it’s as easy as one, two, three. OK, that sounds good.” Then I go here and I have to put in my name and address and ZIP code and city, because apparently they need to know where I live to be able to give me my points.

Then I have to put in an email address and type it in a second time, in case I couldn’t get it right the first time, and then put in a password and then type it in a second time. Then I have to decide if I want to get their email news flashes, because, after all, I obviously want to get news flashes from Coca-Cola through email.

Do I want to get their mobile news flashes? Because, obviously, Coke is that important to me. I need to get that information right away. Then I have to prove I’m not a robot.

All of this is a sucky experience that frustrates. The deal is that over time people get more and more frustrated, because other folks, like Groupon, have a very simple process. You put in your full name. You don’t separate your first and last name, because computers know how to do this. You put in your full name, you put in your email address once, you put in your password twice, and then you lie that you’ve read the terms of use and privacy policy.

[laughter]

Jared: That’s all you have to do, and that’s much simpler. That’s much more delightful.

The thing is that over time that will become a basic expectation. We will expect that sign-in will be that easy, if not easier, and we won’t tolerate these incredibly long sign-in processes, because over time all delighters become basic expectations.

The bathroom inside the hotel room of yesteryear is a basic feature today. It’s a basic expectation, so much so that hotels do not mention on the website that every room comes with its own bathroom. If it didn’t mention that, and you showed up and it didn’t have it, you’d be pissed. They didn’t mention it. Why should they deliver on it? That notion of “we didn’t promise it” doesn’t work anymore. Basic expectations are there.

The Kano model basically tells us that we have to focus on basic expectations and delighters. We have to assume that over time all those delighters will become basic expectations — not just ours, but our competitors’. We have to constantly seek out new delighters in order to keep that going.

Those are the four elements of the storm. What they have done is they have caused the board room to be really sensitive to UX. They don’t know the words. They don’t know the language. They don’t understand, but they get the concepts, and they know that something has to change.

We’re seeing, in organization after organization after organization, and particularly because of mobile, that user experience has now bubbled up to this area. Because everybody has a supercomputer in their pocket now, except for those of you who are using it to take pictures of my screens, which you will get slides of. [laughs] Just saying.

This is what I came to talk to you about today. You need to decide which side of Sturgeon’s law you want to be in. Hopefully, you’ll decide to be in the 10 percent, but then you have to figure out what you need to do to be in the 10 percent, because the 90 percent of crap, that’s the easy path. Once you remove quality as a requirement, everything gets a lot simpler. 90 percent is easy. The 10 percent is hard.

That turns out to be key. You want to make sure that you’re focusing on experience over the technology-and-features part and start looking at it. Particularly, if you’re leading the game in features, you need to understand what’s going to happen next, because if you don’t, your competitors will.

You need to understand this difference between designing for activities and filling the gaps of the experience and how you’re going to start being competitive by filling those gaps. Finally, you need to understand about the Kano model and how it tells us that excitement generators are key and we need to focus on delighters.

That’s what I came to talk to you about today. Thank you.

[applause]

Here’s an excerpt from the article:

“Damn, I wish we’d done this a year ago.” That’s what I hear right after I’ve started a team on their first user research project. The process of learning what your users need is so powerful, senior stakeholders wish they could go back in time and create their products and services over again, this time with the insights they’ve just received.

Of course, you can’t go back in time (yet), but you can start with your own user research program right away. Once you decide to go down that road, the first thing you’ll realize is how rich your choices are of research methods. Usability audits, heuristic evaluations, usability testing, field research – which one do you choose first? Which are the most effective?

Read the article: Starting Your User Research.

What techniques did you start your user research with? How did that work for getting people on board and inspired to create change? Let us know below.

Here’s an excerpt from the article:

A team that approaches genius design needs to focus on a specific problem that has a big enough market to provide a decent return on the investment. For example, an agency might decide they’ll become the industry experts in building web sites for small community hospitals. Because there are thousands of these hospitals across the country, many of which have pretty poor web sites, this is a market that could be beneficial. By establishing an expertise in this space, the agency could provide a cost-effective tailored solution that works.

This means the agency would need to learn everything they can about the people who run the web sites, the people who use the web sites, and what the web sites need to meet everyones’ needs. If they succeed, they’ll create an internal knowledge that separates them from every other web design agency out there, because they’ll know how to demonstrate their expertise to potential clients.

Read the article: Genius Design’s Little Secrets.

Have you ever applied the principles of Genius Design with success? Share your thoughts below.

Ever wonder how many “World’s Best Coffee” signs exist in the world? The world is a big place, so that claim may or may not be entirely accurate. These days, with social media being so prevalent, it’s important that your messaging is truthful and that your product or service delivers on those promises. Otherwise you run the risk of losing the trust of your customer base and scaring away potential users.

Steph Hay, co-founder of FastCustomer, is an expert at crafting copy. Through her consulting, she helps companies make sure that their messaging is appropriate and direct. In her virtual seminar, Building Trust with Your Users through Messaging and Copy, she offers techniques around how to gather, analyze, and use data to make content and UX decisions that are real and truthful to your users.

Steph didn’t have time to answer all of the questions from our audience during the live seminar. She joins Adam Churchill to tackle additional questions in this podcast.

• How is marketing different between a start-up and enterprise organizations?
• What if stakeholders ignore data or analytics evidence?
• How do you avoid overloading the user with too much information up front?
• Once a user is in a flow, how do you ask for more sensitive information?
• How can you balance search optimized language with plain language?

Recorded: April, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Recently, Stephanie Hay presented a virtual seminar called “Building Trust with Your Users through Messaging and Copy.” Many products and services promise to be the easiest, smartest and best things ever. The problem is, they’re just not. This disconnect between marketing and reality is building a web of skeptics.

Fortunately, anyone can build trust with users by setting realistic expectations and then meeting them. In this recent virtual seminar, Stephanie Hay shows how to get started by taking cues from online and offline interactions, even before you start writing your candid content. She shows how to craft helpful user experiences and how to maintain users’ confidence, even in cases where you fail. Hey, Steph, welcome back.

Stephanie Hay: Thank you, Adam. How are you?

Adam: I’m doing great. What’s going on?

Stephanie: Not much. Listen, I forgot if I had ever told you about that time that Jared was in town at “An Event Apart” last August.

Adam: No.

Stephanie: Did I tell you this? Sorry, this is a little bit related to the talk today, but I just wanted to tell you because I keep forgetting to tell you. Feel free to, obviously, edit this out. I was having dinner last August, when Jared was in town for “An Event Apart.” We were having dinner at Vermillion in Alexandria, just chatting about web things, food things, whatever awesome things.

I started eating some bruschetta or something. This is so embarrassing. This is little cherry tomato got lodged into my throat, and I’m suddenly finding myself…

Adam: Oh no.

Stephanie: I know. I was totally choking, dude. I was like, “Am I really choking here?” Only yes, I was. I start making the universal sign for choking. That just happens. Jared immediately flies out of his chair, yanks me out of mine, and starts doing the Heimlich.

Adam: You’re kidding me?

Stephanie: No, dude, I’m not kidding. I felt like it was maybe 30 minutes later, but it was probably five seconds. Tomato gets dislodged. Blammo, out it comes. It was sort of a fancy restaurant, too. I actually caught it, because I have reflexes like a cheetah, even while being saved by Jared Spool’s Heimlich abilities.

Adam: He never mentioned that. Oh my gosh!

Stephanie: [laughs] Seriously, I know. I’m just kidding. That never happened. April Fool! I totally got you! [laughs]

Adam: Oh, man. [laughs]

Stephanie: I totally got you.

Adam: For folks listening in, yes, we are recording on April first, April Fool’s Day.

Stephanie: [laughs] That was so terrible, but Jared Spool would completely do something like that anyway. He probably has saved my life.

Adam: He is a super hero.

Stephanie: I’m sorry to bum everybody out who imagined Jared Spool in a Superman shirt. He probably does wear them. Anyway, that was dumb. I’m sorry. Thank you for humoring me. Now I’ve got to get into what I’m actually going to be talking about.

Why I said this actually relates a little bit to my talk is because this is the sort of ridiculous story that illustrates what’s rampant in marketing, which is that people can sort of say whatever they want, however they want, whenever they want. It’s why recently, as an example, I just terminated my contract with Verizon. I was told by a real person, on the phone, that I’d have coverage in the UK. Which I didn’t.

I landed in London. My buddy, Sebly, was going to be picking me up. He’s driving up from Brighton, an hour and a half away. The snow had just fallen. I was stuck in Heathrow. I had no way of contacting him.

Here I had thought, because Verizon told me that I was going to have coverage, that I would have coverage. When I called to inquire why I didn’t when I landed, they said, “No, it wouldn’t have worked. Sorry.” I was like, “What?” This is after the fact, but ahead of time they were all too happy to get my extra money.

Actually, unroll.me is another example. It sounds awesome. It’s this service that I found out from Des Traynor on Twitter one day. He suggested it was a great way to unsubscribe from emails all at once, so I gave it a try, but it totally destroyed my inbox. Let alone that it didn’t actually give me one-click unsubscribe. It was, rather, just another interface to unsubscribe from emails one at a time.

In both of these cases, the untruths in the content, ones that go after the immediate sale rather than just telling me the truth about their product, up front, about what its capabilities are and being realistic about that, translated to, at least me, one person, not willing to pay them or use their product anymore, and talk about it on podcasts, too.

I have to imagine there is a coefficient about what happens because of this. Something viral on the disincentive side; that is, where I tell people about these experiences on podcasts like these or just in person. There is some percentage less likely to try the product now, people who hear about it. I’m assuming people have done some research on this.

Adam: Can you help me understand this? You’re saying that content marketing isn’t just about the one-to-one relationship that companies are trying to create with their customers? Is that what I’m hearing?

Stephanie: Exactly. Content marketing is the one-to-one-to-many relationship that companies build with their customer and that customer’s network. Organizations fail when they prioritize getting the sale right now. Think classic, stereotypical bait and switch techniques we’d expect from, say, a super crappy mattress sales person. These sorts of techniques work against a company’s ability to gain credibility if they can’t deliver 100 percent.

That’s what I mean when I’m talking about the Verizon or the unroll.me examples. They couldn’t deliver what they told me they were going to deliver, 100 percent. Even a version of that is still, to some degree, an untruth that you could totally prevent.

Then two people tweeted back to him, one saying something like, “United is the worst,” another one saying, “I’m dreading getting on this United flight because of Jared’s tweets.” He’s influencing how people feel about United just by talking about what’s actually happening in his experience with their service.

That’s why I worked so hard, in that recent virtual seminar that you opened with, to describe different ways you can build trust with people by (a) being honest about where you’re at, what you can actually do, and then (b) delivering on those expectations.

Adam: Let’s talk about the seminar. It was fantastic, by the way.

Stephanie: Thank you.

Adam: In it, you gave our audience eight techniques, four content related and four user experience techniques that organizations can use to make marketing and business decisions. One of the attendees later asked how enterprise companies can build trust with customers using landing pages or email campaigns.

Stephanie: The techniques I discuss in my seminar, namely, how to gather, analyze, and use data to make content and UX decisions that are real and truthful to customers. These techniques that I described in the seminar can be applied to any tool or channel and should.

I specifically cite microcopy in forms or email transactions in the seminar, but for general marketing, the takeaway is the same. Effective landing pages or email campaigns speak to people in the language they need to be spoken to in order to understand, because you have to understand something in order to be able to choose it confidently and to not get bitter when it’s not right. Somebody says, “You didn’t understand correctly.” It’s like, “Screw you! You didn’t describe it correctly.” That’s the way life works.

It comes back to content being findable. Technically, for example, from search engines or navigation labels. It’s got to be findable and then understandable so that a user can make that choice — yes, no — confidently.

Adam: You’ve worked with a lot of startups, including your own. How is startup marketing similar to or different from this example of enterprise organizations?

Stephanie: That’s a great question. More than I think it’s the industry — is it an enterprise or is it a startup — I think it depends on culture. Companies big or small that are committed internally and consistently to “data driven decision making,” which is looking at their analytics on a regular basis, conducting concerted experiments, and then choosing how to grow and change their business based on that data, are inherently strategic.

These are organizations that are inherently strategic. They’re not just throwing shit against the wall and going, “Did that work or not work?” Not that there’s anything wrong with that, necessarily. But organizations that really look at their data have a content strategy, even if they don’t know they do. Their internal and external communications are responsive to and driven by this real commitment to analysis, this concerted analysis.

On the other hand, though, I’ve worked with startups and content-heavy organizations alike that invent their marketing in conference rooms filled with people that have strong opinions and arguments. That’s what I mean about throwing it against the wall. Great ideas can come from anywhere.

Genius design is a thing. It’s not just analyzing trends and data, though I tend to prefer this approach, personally. What I believe, politics and personalities exist in startups or big companies. The content strategy, in these kinds of environments, relies on who wins the room of decision makers.

That’s a long way of saying that startups and enterprise organizations don’t differ much in their goals. They want to grow or sustain their growth. They see marketing as a process for achieving that. Where they differ entirely is how they get there. Do they pay attention to the data and strategically decide how to move based on those interpretations, or do they take into account trends and throw ideas against the wall in hopes they stick?

Obviously, the world isn’t so black and white, but in the content strategy work I’ve done for the past 10 years, most experiences do fall into one of these two buckets. In fact, honestly, the majority are driven by politics and personalities rather than data. I just happen to think that the user rarely wins in those situations.

Adam: Can you say a bit more about that? Why is that?

Stephanie: Because often this is where the product, service or language becomes overly complicated. This is where the confusion happens. When you’re trying to win arguments in a boardroom that end up trying to translate to a user as the end result, it’s like trying to balance someone’s opinion of how things should be rather than being exactly what the user wants.

In an example, it’s Microsoft Word versus Google Doc. I use this all the time. Microsoft Word has everything every user or decision maker has asked for, or so it seems. I don’t use 90 percent of the features in Microsoft Word. The ones I do somehow create my formatting bugs. It just drives me bananas.

For example, I recently connected a UX audit. Fantastic product, been around for about a year, is changing the way conference calls are happening. You can do it by a link. You don’t have a PIN. It’s very cool. Anyway, they’ve just launched an iPhone app. It didn’t really tie into their web-based app. Their web-based app was their original product. They were working on creating this DropBox integration and updating their UI so people could do a bunch of new things.

When I started working with them last year, I kept hammering them to give me data on a variety of their features. Which of these features are people actually using? Are people using the DropBox integration? That sort of thing. It turned out that the majority of the work or the things that even they were planning to do, it wasn’t merited. People weren’t using those features already.

66 percent of people were doing only the thing that they were doing since the company launched. They were having these conference calls. They were really psyched about it and doing a great job. 33 percent of the people were trying to use one of the features that came shortly after launch but hadn’t really gotten much love.

It really wasn’t working that well. Effectively, a third of the people were having a poor user experience. Two-thirds of the people were ignoring all the work that the company had done over the course of six months or something. Just the people that sit down and say, “Let’s pay attention to this.” It was really an enlightening experience for everybody who was involved. It completely re-prioritized the way that they needed to make design, business, and marketing decisions.

That’s where the Google Docs side of things comes into play. It also manages to give me what I need. It’s not perfect, but it seems to have found a place in being exactly what I need it to be, and millions of other users. That’s also because Google has self-proclaimed — the people I know who work there also validate it — that it’s a big data company. They pay attention to the data.

Adam: That also speaks to a question that came in during the virtual seminar. Vanessa asked, “What if CEOs or stake holders ignore that data evidence?” Say, from Google Analytics.

Stephanie: It’s always going to happen because it’s not so black and white. You can interpret the data however you see fit. That goes for you, the person analyzing it, just as much as the stakeholder listening. If I lose these arguments, if I say, “This is the data. You cannot ignore the data,” and they ignore the data, I have to imagine it’s probably because of the way I presented the data.

Maybe it was flawed. Maybe the way I gathered the data is flawed. Maybe I just failed to make a good argument as to why this thing I wanted to do is actually being supported by the evidence. This has all happened to me and continues to happen to me in life. What astounds me is how often the growth in subscriptions or payments or purchases just isn’t there.

Somebody says to me, “We want more ‘engagement.’” Then I say, “What’s engagement mean to you?” They can’t give me an answer. I can’t go find any data to support this, because this is just some ambiguous term that they’re using to make somebody else who’s working with them happy.

If you can boil it down to, what is the actual metric? Is it subscriptions, payments, purchases or whatever? Then you can actually go find that data and track it back to that. Typically, those are the metrics that are really going to make stakeholders pay attention.

I would also say, on the other side of this, why people ignore it is because they think they need to think of what hasn’t been done yet. “What haven’t we done yet? What are we missing here?” [laughs] I don’t know how many conversations I’ve been in. Too many. They’re sort of fun, in a way. It’s like, “Cool, we’re all going to sit around and brainstorm something cool and innovative.”

Honestly, this comes back down to content, too. I am such a big believer in simplification. It’s not so much, “What haven’t we thought of?” But, “What have we done now that we over-complicated? What are we telling people that just isn’t true, that isn’t meeting their expectations?” If your numbers are showing that you don’t have growth somewhere, it may very well be a symptom of what you’re confusing, not what you’re missing.

This is such a core element of why so many awesome startups fail, too. This worked for Armslist as much as it’s worked for Google Docs. Actually, Jared just wrote a post on this recently about an e-commerce company that spent millions of dollars redoing its purchasing process. You should link to that in the description here. After they spent millions to redo their purchase process, their transactions dropped by 40 percent or something, which translates to millions of dollars for some of these big companies.

I’m sorry, but CEOs and stakeholders cannot ignore that unless they want to lose their jobs. So I’d say UXers and content strategists, people who are core to planning these experiences, need to think about that end result. What is the bottom line to the CEO or the stakeholder, really?

This is not going for everybody, but they don’t feel that empathy that we as practitioners might feel about the users in the same way. They’re thinking about, “What is that metric?” It’s our job, our responsibility to think like a business person when we’re analyzing and presenting the data. Users’ feelings are often inherently part of that data if we’re just willing to own up to it. It’s our responsibility to pay attention to that.

Adam: Cool. Couple more questions. You have time for us?

Stephanie: Sure.

Adam: Rebecca wanted to know if you could speak a bit more to determining how to balance the amount of detail you provide up front. In other words, how do we avoid overloading the user right up front with too much information?

Stephanie: This is great. This is another reason to pay attention to the data. In a really concerted content strategy, where you’re working arm-in-arm with user testing, you can and should test what at this level are the core questions that a user has that we need to answer.

What are the keywords that the user needs to see in order to feel like he or she can keep scrolling, can click here, can keep reading, or whatever the next step is? The goal here is to know your business so well that you can set up a conversation with users in the same way that you might have a conversation in real life.

I was working with a client recently where we did this workshop. I said, “I want you to do some role reversal. The person sitting across from you is you. You are your user. Start asking questions about your product as if you were the user.” They elicited all these questions that they had had as users, that they didn’t know how to answer because they weren’t thinking about the conversation. They were only thinking about what they could say.

You know your business so well, but if you can get out of your own mind a little bit, get into the user’s shoes, and think about what the conversation is like on the other side, you can filter very quickly what’s the core content you need to have up front, and what is the way that that conversation continues to flow, where the person continues to give more detail as those core questions continue to be answered.

To be able to have an offline conversation with somebody that’s realistic…What are the sorts of questions that somebody asks in the first 10, 20, 30 seconds of a conversation about your product or service?

Structure your content. Content hierarchy, the navigation, the interactions, everything follows that conversation. Then what you’ve done is created a flow that gives the user exactly the kind of information he or she needs up front, without anything else, because it’s just mimicking a natural conversation. It leads into the detail as it would naturally if you were having that conversation in real life.

That’s the core of it. To find that balance, you have to have conversations offline. I think you have to have conversations offline that are realistic. The best way that I tend to help people do this is to have them reverse roles. Suddenly, you as a subject matter expert? Nope. You’re not the subject matter expert anymore. You’re the user. Start asking the person sitting across the table from you. That helps people to think about what that conversation might actually be.

Adam: Can you talk a bit about building trust once you’ve got a user in a flow already? Then it’s time to get them to give you some sensitive information, say, a social security number?

Stephanie: Yeah, absolutely. If you’re going to have these Mint.com or PayPal experiences where you have to have the person give you some sensitive data, this requires transparency and trust more than just a marketing website where you’re clicking around and there isn’t this sort of ask.

We were doing this with Fast Customer. We had to get people’s phone numbers in order to work. In order for our application to actually work, we had to get a phone number. So we would say, over and over again, to the point where we felt like it was redundant, “We’re not going to use your phone number for anything. We would never, ever sell your data.” Still, we would get emails from people on a regular basis asking us, “Why are you asking for my phone number? What are you going to do with my data?”

I is a concern. The best way to continually build trust with people…The Netflix signup process, for example, is that when you’re asking for something sensitive from someone, tell them why you’re asking for it exactly, and then reassure them that you’ll never do anything with it except use it in order to do whatever you need it for in the first place. To be able to be transparent about that and up front about it is the best way to reassure the person who’s giving you that information that it’s OK to do it.

Beyond that, it’s all just delivering on that process. The first time that something gets hacked or the first time that you get an email that you didn’t agree to and it’s got some sensitive data is probably going to be the last. People are not cool with that, nor should they be. Being transparent about it and then protecting it fiercely is the best way to account for building trust over time.

Adam: Do you have any recommendations for how design teams can balance search engine optimized language versus natural language, plain language?

Stephanie: Yeah, absolutely. I love this. So often, natural language is already what is the keyword in the search engine. People don’t use words like “convert, increase, decrease.” These are sales and marketing words that we think we have to have on our home pages. We don’t. They certainly don’t need to exist in title tags and meta-description content on the page, as well.

I would say to find the natural language just takes going to Google AdWords keyword tool. Just go to the Google keywords tool. Start looking for what are the words that people are using in your space.

Let’s say you’re trying to sell a board game. You go to Google AdWords keyword tool. You’re looking for board games. You start searching for some titles of specific board games, chess or something like that. You’re just in there exploring what kinds of searches and how many monthly searches, globally even, that people are using as part of their regular language. Which of those things can you translate to your home page?

Maybe you’ve got some meta-copy that’s already got that information in it, keyword-rich copy. But a lot of it is just getting comfortable as a culture to use the kind of language that people use in real life, moving away from the marketing words that we’ve come to expect from a lot of these sites that are not SEO optimized and are not person-optimized either. They’re doing nobody good except the person who writes it and feels pretty good about him or herself.

Adam: Steph, thanks so much for joining us again and talking a bit more about some of the questions that folks had. To our audience, thanks for listening in, for your support of the UIE virtual seminar program.

Here’s an excerpt from the article:

Designing web sites is a strange and wonderful thing. The web is often described as a medium, but it is no more a medium than ink. To be a medium, ink must be combined with paper and a means of forming letters; otherwise ink is merely a means of transporting pigment. Similarly, the web is merely means of transporting data and structuring ideas. It is only when these meet a combination of software and hardware that we have a medium for design. But unlike all written material before it, that medium is under the control of the reader.

Read the article: Embracing the Medium.

How do you take the users’ environment into consideration when designing your web site? Share your thoughts below.

Shared understanding is important to any team working towards a common goal. Ensuring every member of the team is on the same page can be difficult. Sketching is a quick, lightweight method for communicating design ideas or interactions. Starting with sketching early in the design process lets everyone share the same vision.

Nathan Curtis employs sketching throughout his work at EightShapes. Whether they’re sharing sketches while sitting next to each other or remotely using an IPEVO camera, the EightShapes team makes sketching a large part of their process. Nathan offered up some great insights in his virtual seminar, Sketching for Understanding. Nathan joins Adam Churchill to tackle some of the questions there wasn’t time for in this podcast.

• How do you get people who are uncomfortable with sketching involved in the process?
• Can you use sketching to solve problems other than design problems?
• How do you compile and track sketches?
• Can you go straight from sketches to comp, skipping the prototyping phase?
• What scenarios should you start with?
• Where does visual design fit into the design process?
• How can you adapt a design studio to a smaller group of designers?
• Is the iPad an effective sketching tool?

Recorded: March, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone. Welcome to another edition of the SpoolCast.

Earlier this year, Nathan Curtis of EightShapes presented a virtual seminar called “Sketching for Understanding.” We create these special EightShapes virtual seminars in cooperation with the folks from EightShapes.

This seminar, along with over 100 others that teach the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library.

Now in this seminar, Nathan explains where sketching fits and explores some tools and techniques of the trade. He shows us how to incorporate sketching in the design processes with both large teams and remote teams.

Hey, Nathan. Thanks for joining us again.

Nathan Curtis: It’s great to be here. Thanks, Adam.

Adam: For those that weren’t with us that day for your seminar, can you give us an overview of what you covered?

Nathan: We talked for about 90 minutes, including some questions and answers. We really covered three big topics. The first thing I tried to do was talk a lot about the basics of sketching, really.

You pick up a Sharpie. You’ve got some tools and you draw things, whether they’re squares and triangles and arrows and text or, as we really got through in most of that seminar, really drawing screens to visualize our ideas in software design.

In the second section, we really dug into not just the process of where sketching fits, which is really anywhere within your process, but also how do you share them and how do you get feedback? Really getting together to understand the problem collectively, which you can use sketching for, but then drawing the solution, presenting your ideas, getting critical feedback so that you can make your ideas better.

Then the latter part of the seminar, we talked a lot about how we share our sketches with others, whether they’re remotely using a camera so they can see us sketching in real time or actually bringing together large groups of folks.

What’s the process when you bring a team to sketch for a half hour or an hour or half a day or a full day? How do you create scenarios and create good teams and organize the sketches when you’re done.

We covered a lot of ground but it was all about how you pick up a Sharpie and draw your ideas and get feedback on them.

Adam: Say a bit more about that. I know a big trick for a lot of design teams is you usually get some people in there that aren’t comfortable with this craft. How do they get better at it and how do they get that feedback? How does that happen?

Nathan: Like any kind of skill, you get better with repetition and practice. There’s a lot of different formats that sketching can come into play. A lot of different points in the process.

Sometimes, you’re sketching alone and then you share those ideas by walking over to your neighbor’s cube or you fire up a GoToMeeting and show a picture of the sketch that you drew and you get feedback on the ideas.

And then, there’s other formats. When you’re working with a large group and everybody’s sketching at the same time and you really take turns to get the feedback on your ideas.

But, I recently got asked a question by a colleague of mine that I work with which wasn’t how can I get feedback on whether my ideas are good, which is the most important part of sketching, but also how I’m sketching in general.

Oftentimes, the feedback I give them comes down into two different things. The first thing is, “Are you really breaking the boundaries and understanding the breadth and the scope that you’re allowed to be creative?”

Because a lot of times we’re sketching because we don’t have a good idea of what the solution is so we don’t want to just draw a basic set of links and maybe a header on top of it and a button on the bottom of it and call it a day. Rethink, perhaps, how the experience works to improve it.

And so, that’s really trying to get up and be more creative, get outside their box. And oftentimes sketches don’t do that. You can tell that someone’s too constrained into how the problem was defined or how the experience used to work to think differently about it.

The other thing I often encourage folks to do is to sketch a little bit more conscientiously. People get so excited about sketching but also might be a little bit nervous about sketching that they try to draw really fast and get their ideas out really quickly.

Instead, it’s helpful for them to sketch a little bit more deliberately. And then, as they form that sketch be a little bit more meticulous. Use real words from the experience. Draw some more details around what direction an arrow might be pointing for a drawer that expands and collapses and whether it goes on the left hand side of the header or the right hand side.

Think a little bit more deliberately and perhaps meticulously to produce something that’s more refined if you have the time, as opposed to just scribbling a bunch of stuff.

But it depends on your context and what your goals are. Those are the two pieces of feedback I usually get.

Adam: Nathan, do you folks ever use sketching as a method to solve other problems?

Nathan: Oh my goodness, yes. We talked a lot about sketching to solve user interface design problems and how an experience might work as someone interacts with the screen. By and large, that’s the lion’s share of the sketching we do. But it’s no mistake that a big wall of 15 feet by 10 feet in our office space is a big whiteboard wall.

When we start a project, you’ve got to lead, facilitating the conversation of the group of people, and drawing things like lists of tasks that we want to do, or flowcharts of how the experience works, or concept models of how a team is organized or how an experience is organized, and site maps and other kinds of things.

All those different things are really different ways to graphically represent ideas. The whiteboard wall that we have, drawing with a Sharpie on a piece of paper, all those things are really quick ways to visualize ideas and get feedback on them.

While a lot of our craft comes down to sketching screens, it’s certainly not limited to that.

Adam: Do you have a recommendation or tricks maybe to offer up, how to compile and track sketches as a project progresses?

Nathan: Yeah, we’ve ended up refining how we do that over the last few years as sketching has become such an important part of our process. The artifacts we produce, whether it’s wireframes or comps or prototypes or all those different pieces of the design. All those are disposable things on the path to getting the final, perfect production site implemented.

Sketches are no different, and in fact they’re looked at as the most disposable thing. They’re supposed to be the most transitory — you sketch something, you share the idea, you throw it away. That’s one of the great lightweight things about sketches.

But as sketching becomes a deeper part of our process and oftentimes replaces things like wire framing or comps on the way to a prototype — sometimes we’ll sketch and then we’ll go directly to code to render what something looks like — they become an artifact in and of themselves, both because we need to record the idea so that we can share it with other folks, and sometimes that’s taking a picture of it with our phone, using the IPEVO camera to take a picture of it as it sits on a desktop.

More often than that, as we have big teams that come together, we want to take pictures of all those sketches, because you get, say, 20 people together for half a day, that’s 10 person-days of work, of ideas that you want to keep. A couple weeks, maybe a couple months later, you want to go back as you’re thinking about the scope for a next round or a next sprint, and say, “What were some of those ideas that we sketched before?” You have to have those pictures.

We found that taking the sketches and putting them in a stack on a side table and it just becomes a big pile of trash, that’s not really how we do it. Almost always we’ll capture those sketches with images, be it our phone camera or IPEVO, like I said. We’ll try to label them, put them in folders, and organize them enough so we can retrieve them later. That process literally takes, what, five minutes or so for even a big pile of sketches.

Adam: Have you ever gone sketches straight to design comp, actually skipping the prototyping phase?

Nathan: I almost question the way this question is phrased, because you said go from sketch to comp and skip the prototype, when often, in our process, we’re going from sketch to comp and then prototype, because it’s a different topic, but part of the impact of sketching and part of the impact of prototyping on our process is making all those different design disciplines more parallel in their work, rather than sequenced.

You have visual designers working on comps at the same time that a UI designer is working on wire frames or even is working on a prototype, and all those things happen together. The nice thing about sketching is that it feeds all of them. Sketching can feed clarifying what a comp needs to depict at a certain responsive size. Sketching can work as a predecessor to a more formal wire frame that you draw in vector format.

Sketching all the time, for us, clarifies what needs to be prototyped, such that we may skip wire frames and skip comps, and if we have an established design language already available to us and perhaps even codified in the baseline CSS we’ve got, then we’ll do a sketch and then we’ll prototype it in code. Guess what? That’s the only thing you need. What’s really in terms of sketching is that input to any of those pieces, depending on the level of fidelity and formality that you need.

Adam: Nathan, what kind of scenarios do you usually start with?

Nathan: It depends. Most often it’s designers working together on a project, and so we have a good sense of all the different cases that we need to solve. We don’t really use formal use cases in our work. Every once in a while, we’ll use stories, but both of those are really inputs to think about how to formulate how the experience works.

Really sketching happens more fluidly in an ad hoc way between two designers collaborating over time, and if we’re sitting next to each other you just start talking, you grab the pen, you grab the paper, and you sketch.

The more important time when you need to think about scenarios is when you’re facilitating a large group sketching together. We call that a design studio when, say, over a half a day you convene a group of 12 to 20 people. You create teams out of them, and then you’ve got to sketch across round after round after round where everybody sketches, and then you have these rounds of feedback or presenting your sketches and getting feedback. Everybody gets a turn to present.

You absolutely have to have scenarios for that case. You have to be set up. You have to be prepared. You can’t just wing it and say, “Hey, what do you guys think about sketching the home page?”

No, you have to come in and say, “We’re going to work on search today. The rest of the home page is pretty much fixed, but we need to work on how the auto complete works, and we’re going to work on some best bets and highlighting some specific content,” and you really create the different aspects of the design that people need to focus on.

And so, in those rounds of sketching people are still trying to solve the same problem even though the range of sketches you’ll get is very divergent. As we prepare for those, that’s a week, maybe two weeks, of iterating two times maybe with our clients to validate what the scenarios are.

We pick those to be the most important, most consequential, perhaps part of the core happy path to the experience, and then we’ll later perhaps later in the day an exceptional case or something that’s more interesting and off the beaten path as people have already been warmed up.

Adam: There were a few questions in from our audience about dealing with the schedules of groups, whether you’re working with a client and they’re not willing to commit a full day or whatever time you’re setting aside for this or whatever number of personnel are involved with this project. You can’t just pull them together to do this the right way.

Are there tricks or some experiences that you can share that help here?

Nathan: Yeah, once you get beyond one or two hours you have to be cognizant of the fact that many people aren’t going to be able to give you their whole day or even a half day. What we found is we think about a session like that as oftentimes we’ve got those rounds of sketching that are based on scenarios like I was explaining before, but you really have the bookends of the day as well.

At the beginning of the day, you’re setting the tone for what the projects about, oftentimes, how sketching works, how the day’s going to work, and you really get everybody on the same page for the process of how we conduct those design studios. That’s a nice piece for everybody to be at.

Just as much as at the end, the end of the day, or the end of the half-day or what have you, you have a summation period where everybody gets together. You’ve talked about the last round of sketches, but then you sort of bubble it up, and you say, “What thing really stood out to each of you?”

You can go around the entire group and give everybody a chance to talk, to articulate what was most important to them, what they noticed the most, what the major theme is that they sensed about the day.

It’s interesting the things you’ll hear, both at the beginning of the day as you’re trying to gain a consensus idea of how things work, and at the end of the day when you’re trying to gauge the individual reactions of different people, what you get out of that, because actually you can extract from those comments what matters to people, both about the project at the beginning of the day and about the ideas that they saw at the end of the day.

It might not be that you nailed it with any sketch that you did – any sketch might not be perfect but you might realize that everybody’s saying the same thing in a slightly different way and when you as a design team take that input, go back to the drawing board after the studio’s done, then you can really refine your idea to encapsulate those principles or ideas that they had.

It’s important to get the folks, I would say, in the bookends of the day, and that if you already know, also, that there are key participants — some of the key stakeholders, maybe the lead developer, maybe that teammate developer that you know you’re going to work with a lot — you maybe orient the scenarios based on when you think they’re going to be there or not and have them there for the most consequential stuff.

Adam: Nathan, this might be a little bit off topic but anytime we have you or Dan Brown in the studio our folks are anxious to get inside the walls at EightShapes and no more about how you’re doing things. There’s a question that came in, “How does visual design fit into the design process for your teams?”

Nathan: EightShapes, in particular, we started with Dan and I, and we’re both user-experience designers, interested in user interface design, information architecture, interaction design, et cetera, commonly the discipline people distinguish from visual design. But when it comes to how we approach a project and how we’ve since grown, we really consider visual design as a core part of the experience as well.

It’s really a peer of how the UI design works, and often, we’ll create the plan of how our activities will be conducted for a design process to make those parallel. At the beginning of the process, we’ll try to involve all of the disciplines and activities like the design studio that I’m talking about, and requirements gathering, and brainstorming even as an internal group. We’re all involved. We all have a voice.

It might be that the most important consequential thing we do after that is establish the visual design direction based on how sketches are looking. Maybe we throw together quick wireframes. But as the UI design team, as the interaction designers, whatever you want to call them, as those folks are doing things like more detailed wireframes, or maybe starting to build out the prototype and so on, in parallel the visual design team is establishing the visual direction and we’re actually working side by side.

We try to communicate as much as we can such that pretty soon thereafter if we can get the design direction established, we’ll start blending both of those inputs together into something like a prototype. The prototype really isn’t owned by the UI designer. It’s owned by the whole team, and we sit together and Chromes and Spector later in a process.

The prototype might be more fluent in the code, but the visual designer’s sitting right next to them, shoulder to shoulder, saying, “Can you nudge this thing that way? Can you make the space between those two elements less? Can we darken that opacity for that gradient?” or what have you. We’re exploring all those things together.

It can be uncomfortable for folks at times because you don’t have the, “I’m going to put on the headphones. I’m going to sit there, and I’m going to do my own work for like a day, and then I’m going to get feedback on it.” Sometimes, it provokes more collaboration that can be unsettling for people that don’t do it as much, but once you start to develop those relationships you move a lot quicker, and it helps build trust between the two teams as well.

Adam: Can you say more about the design studio idea? There were some questions about how it could be adapted for smaller groups of designers or stakeholders. Isn’t the design studio geared towards bringing those people together?

Nathan: The concept of a design studio is a formal way to set up a two or more hour session to involve many participants. That’s why you focus a lot on teams. That’s why you focus a lot on getting the scenarios right before people show up. That’s why you have rounds where people sketch as a team, and then they aggregate their ideas and share them with other teams.

And so, that whole structure, that whole framework for doing sketching, yes, it’s intended for larger audiences. When we learned about sketching studios and sketching in general, a couple people that we learned a lot from were Will Evans, and, in particular, Todd Zaki Warfel. He was kind enough to sit with us and talk us through how it all worked so we could incorporate it into our practice.

What we didn’t expect was whenever you have two people sketching together — two or more people — the core principles of how the interactions work apply, because whether you’ve got a team of five people sketching in a design studio setting as a team, or you have two people sketching together, or four people sketching together just for a half an hour, we still formulate the problem. It takes maybe 5 or 10 minutes.

Then as a design team of four people, let’s say we’re on a GoToMeeting and we’ve all got our IPEVO cameras ready to show what we’re sketching.

We formulate the problem for five minutes. We’ll sketch for about 12 minutes, and then we each have four minutes. For a couple minutes we present our ideas and then everybody else reacts to those ideas and gives us feedback.

While it’s not a full day session with lots of preparation beforehand and lots of people getting their calendar invites all set up, nothing that formal. It’s just the way that we share ideas now. It could be a half hour or it could be even 10 minutes. “Hey, can I grab you for 10 minutes?” and do that same define the problem, sketch the ideas, present the ideas, and then get the critical feedback from other people.

That is just now a part of the way we interact with each other.

Adam: How about in an agile environment? When would you typically conduct a design studio?

Nathan: The agile environments that we’ve worked in need to define a set of scoped items to work on for each of their sprints. And so, it naturally seems to indicate that a good time to sketch together, to work through what those ideas are are at the beginning of sprints, but maybe even more consequentially in that “sprint zero,” really the design period that precedes the sprints, if that’s how your agile process is set up.

When you talk about design studio, that’s when to do it. It’s really when you want to explore a lot of different ideas and be able to, if that’s the intent, then reconcile all those ideas into something agreed upon that you’re going to work forward with.

And, depending on the maturity of the design language, the maturity of the team, and lots of other factors, maybe that’s what you need to go into sprints. Maybe that’s the input. But I would also say sketching as a technique can happen at any point. And so, if you’ve got a sprint, the last designated period of time, let’s say a week or two weeks or what have you. It doesn’t mean on day 8 of 10 if the developer has a question and they walk over to the designer or they contact him and they say, “Hey, what’s going on here?”

You throw together a sketch. It takes three minutes and suddenly they have all the clarity they need. That’s saves them a half day’s worth of work that might have been a mistake otherwise.

Sketching, as a technique, really fits in anywhere.

Adam: What are your thoughts on using an iPad as a sketching tool?

Nathan: That’s an interesting question because, at least at EightShapes, we spend a lot of money on software and certainly the Adobe Creative Suite, everybody has it. It’s almost as if the big purchase I have to do otherwise is go to the websites where we buy all our sketching markers and pens and so on. Sharpies and Copic markers for wide grey and all sorts of stuff. I’m buying those materials all the time.

And so, to me, that at least indicates that people continue to use pen and paper to create the sketches most of the time. We each even have another member of our team, Veronica Erb, who does a lot of sketch noting, too. I know that she and many of the other members of the team — I haven’t personally — have experimented with a lot of the different styluses that you can get for an iPad and even lots of the different apps that you can sketch.

But I haven’t sensed it become a part of their workflow as a practicing UI designer. As something that they have replaced paper with using the iPad.

Some of those apps have great ways for you to create a sketch and then share it with other team members or even, I think, create a common place where you save them and then they’re just all available to everybody. But we haven’t used them a lot in our process. We have generally relied on the IPEVO camera to take pictures of them live and share them as the sketches are happening and then just use pen and paper.

Adam: Very cool. Thanks for taking some time out of your busy schedule to come back to this topic of sketching in your design process. It was great to hear from you again.

Nathan: I love talking about it. Thanks for having me.

Adam: For those listening in, thanks for your time and listening and for your support of the virtual seminar program. Goodbye for now.

Here’s an excerpt from the article:

APIs give designers a much richer toolbox than they’ve ever had before. We can now take advantage of capabilities on our devices, the wealth of knowledge stored in databases, and pull together resources to provide a richer experience for our users.

APIs provide us LEGO-like building blocks, each with unique capabilities, that we can plug together to extend our abilities. Just a few years ago, if you wanted to integrate SMS into your app, your development team would have to learn the ins-and-outs of connecting to the carrier’s interfaces (which weren’t standardized) and constantly deal with a shifting landscape of technology. The costs were unacceptably high for most organizations, so only the richest could afford to develop and maintain it, with low returns on that investment.

Now, rigorously built APIs, like those provided by Twilio and its ilk, bring those development and maintenance costs down significantly. The lower bar of entry means more competition, which lowers costs even more. This makes incorporating these capabilities easier than ever.

Read the article: APIs: The Future Is Now.

How are you using APIs to bring more value to your users? Share your stories below.

When you’re dealing with different screen sizes and devices, you need to consider how web typography works fit in. In Typography in Responsive Web Design, Richard will explain why typography is like a visual hierarchy. He’ll show you what to watch out for with OpenType and how features on the edge of CSS can make (or break) user experiences. Whether you’re a designer or UX specialist, you’ll leave with tools and practical techniques that you can start applying today.

And for a few more days, you can still take advantage of a special offer. Register by Friday, April 5 and you’ll receive a free bonus virtual seminar, The How and Why of Responsive Web Design with Ethan Marcotte.

Here’s an excerpt from the article:

Words are powerful, but sometimes they don’t cut it. We can try to describe what we’re imagining, but a diagram often gets us to a common ground quicker.

As our team has been studying the skills of great designers, we’ve seen sketching emerge as a theme. All of the best designers we’ve met sketch. They are comfortable picking up a pen or pencil and putting it to paper (or, in many cases, whiteboard).

Read the article: Why We Sketch.

Do you have a success story about how sketching helped you or your team achieve a goal? Share your success story below.

Fast Forward One Year:

We want to thank you for crafting and executing a marketing strategy for User Interface Engineering. Here’s what happened under your leadership:

1. You increased our revenues beyond our wildest dreams because of your ingenious unified approach that clearly tied all of our products and services together.
2. Your laser-like focus on the marketing messages and launch phases for our new webinar library made it successful right out of the gate.
3. You crafted a brand new corporate event service that’s got half the Fortune 500 begging for priority access.
4. Your work with our social media, email marketing, conference sponsorships, speaking opportunities, and web site has quadrupled our reach and brought awareness to a much larger audience.
5. You’ve successfully convinced us to stop using alliteration in our headlines.

Everyone at UIE thanks you for your dedication. We can’t wait until next year.

Now Back to Today:

If you’d like this to be your story, send us your resume with a half-page write-up of your most significant marketing strategy accomplishment. While we’re less concerned with your education and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web sites — www.uie.com, www.uxim.co, and www.uiconf.com — for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the resources you need to bring out the best in your talents and skills.

Send your resume and write-up to: MarketingDirectorJob@uie.com

Or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

Here’s an excerpt from the article

It’s your most loyal customers who will hate your flip-the-switch redesign the most. Designers are quick to declare, “Users hate change.” But that’s not it at all.

Your loyal users have invested a lot over the years mastering your current design, to the point where they are fast and efficient with everything they need to do. When you change it, even with something you want to label “new and improved,” all of that investment is flushed down the drain.

Read the article: Extraordinarily Radical Redesign Strategies.

What strategy have you put in place when planning a redesign? Tell us about it below.

A beautiful design means little if it’s not useful. Content is the key to making it useful. From the outset of the design process, you must consider the content for the site. Members of the design and development teams should work alongside the content strategist to ensure the right content is delivered with the right message.

Kristina Halvorson, founder and president of Brain Traffic, is the author of Content Strategy for the Web. In her virtual seminar, A Content Strategy Roadmap, she laid out necessary tools and processes so that your audience is met with timely, appropriate content. During the live seminar, the audience asked a lot of questions of Kristina. She joins Adam Churchill to answer some of those in this podcast.

• For a content audit of a large site, is it ok to audit just a sample of pages?
• How can you convince stakeholders which content is truly valuable?
• Are there ways to deal with highly resistant stakeholders?
• When making a sample set of a content audit, how do you make sure you don’t lose long term maintenance of the pages?
• What tools are available for creating editorial calendars?

Recorded: February, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Recently, Kristina Halvorson presented a wonderful virtual seminar called “A Content Strategy Roadmap.” In it, she walked us through a typical website project to demonstrate how, why, where, and when a content strategy happens. Best of all, she showed us how you can do it in your organization, too.

Hey, Kristina. Thanks for joining us again.

Kristina Halvorson: Hi, Adam. It’s my pleasure.

Adam: For those that weren’t with us for your seminar, can you give us an overview of what you talked about?

Kristina: I sure can. When people talk about content strategy, they tend to blow it up into this huge — it is. It’s a huge, complex process that has a lot of moving pieces. What I really tried to do in this seminar was focus on the basics of how to introduce content strategy and the content planning process into a relatively standard, waterfall web design process.

What we did in this seminar was, essentially, really lay out the core processes and tools that are required to make sure that your content ends up being the right content, in the right place, at the right time, to your audience, with everything from messaging to content prioritization on the page to voice and tone.

We learned how to do a content audit and what that spreadsheet should look like and how to make it as useful and usable as possible to all the people that are going to be referring to that throughout the design and development process. It really does break it down step-by-step.

I also worked to show very carefully how the different roles on a website design and development team will work with and interface with your content strategist. Really, what we called it in the presentation is more of the content wrangler, the person with whom the buck stops when it comes to the content, from the very beginning of the process all the way through launch and maintenance.

Adam: In the section where we were talking about auditing, we had a bunch of folks in the audience that were cringing because they’ve got really big sites with lots of pages and lots of information. Jonah sums it up in his question. In the case of larger sites — and he quantifies that as 100 pages or more — is a sampling of the pages OK rather than actually auditing every existing page?

Kristina: That is a great question, although I will say that my definition of a large site really is going to be anything beyond, I don’t know, 1,200, 1,500 pages. In the instance of, let’s take this 100-page site, depending on the kind of content that is in there, I do strongly recommend auditing — at least having an inventory of each page of that website.

Let me just clarify real quickly. When I talk about a content inventory, essentially what I’m talking about is a spreadsheet that just lists out all of the different pieces of content that we’re responsible for in our project teams or within the areas of our organization, where it is really just listing out the URL, the page title, potentially the page topic, and other kind of quantitative information, like when was this published, when was the last time it was touched, et cetera. When I’m talking about inventorying the content, that’s what I’m talking about.

When we’re discussing auditing the content, that is typically where we get into some more qualitative attributes, like readability, relevance to audience, things that are going to require human or editorial input.

Having said that, a site of 100 pages is really something that I think we can tackle, not just from a quantitative perspective but also from that qualitative. Now, when you get up into the 1,000, 2,000, 10,000, hundreds of thousands of pages, that sample audit is something that really will come in to be very, very useful.

I almost never recommend tackling, “We’ve got 100,000 pages. Let’s figure out how we’re going to audit this thing.” You’ve got to really prioritize top areas of content to look at, which can be based on audience interest or relevance, the content that you really need to be presenting in order to help meet your business objectives.

A really good example is if you’ve got a support section and you’re trying to drive down call quantity to customer service or to your support team, how can we take a look at that section and identify which areas we need to look at or we need to audit for best results.

So, all that said — I’m coming back around to the question, I swear. [laughs] All that said, in order to identify which parts of your content to audit, you need to identify the attributes you’re looking to get at. If you look at your business objectives — and again, let’s take the case of “We want to drive down call volume.” Well, obviously, to our support team, there are a couple of different areas that you’ll want to audit.

Probably the home page and the key landing pages throughout the product sections that people may be going to looking for that information, figuring out how you’re greeting them on the support and so on.

Those are your key landing or your way-finding pages. And then, in terms of pulling out a sample set, in this instance, identify what those templates are and then maybe pull 10 to 15 different content samples from each of those templates to really take a look at.

To summarize, we want to have what are your business objectives, who are the audiences that you need to impact or have an effect on that will help to achieve those business objectives from an activity standpoint, and then what core areas of content are they interacting with that are making or breaking the success of those objectives.

I wish it were like, “B. Always go with B.” But it’s not. It’s a complicated question, and a great question.

Adam: Somebody that owns the content, right? They’re working with lots of other folks that want their little pieces added. How do you help your sponsors understand exactly which contents are important and what’s truly necessary for the people that are using those pages? How do you get them to understand that what they’re asking for is trivial content and something they just want to have there rather than something that’s truly useful? How do you get over that hurdle?

Kristina: Another great question. Interestingly, a lot of the clients that we’re working with, this is one of the key problems that they have and why their websites are the way they are now, is that they’ve just been saying yes to everyone because there haven’t been any guidelines or benchmarks or rules when it comes to publishing content on the site or sites or elsewhere.

Really, there are a couple of core tools that we try to introduce or develop, the first of which is really trying to create, whether you want to focus on user personas or user stories, anything that would really help your internal audiences or your sponsors or your content stakeholders, owners, et cetera, understand, “Look, here’s what we know our audiences want.”

“Here’s what we know they need. Here’s what we know they are reacting to.” So that you have that hard data and user research to really be able to give it to them to provide some context to the content, the outcomes they’re really asking for or looking for.

I think that so much of our content is created and published based on assumptions of what it is we think we know about our audiences or what we think our audiences want. Any sort of tool that can be easily referenced or rolled out or made available to the content creators and requesters is really important.

Another way to do it, I think, having some sort of messaging hierarchy that exists throughout a website or an area of the website where we can begin to map back the content that people are requesting to our priority messages, whether it is throughout a section or per page, and helping them to see whether or not that content is going to actually expand upon or ladder back up to that message.

Or if it’s just something off in left field that’s nice to have, that’s, “Just in case somebody wants it, we’ll throw it out there.”

Adam: Related, Kristina, what about tips for people that are working with highly resistant stakeholders?

Kristina: Oh, yes. [laughs] This is one of the things when the content strategy conversation really started to take shape that quickly became apparent and that I think, as a web writer, I was always frustrated by, which is that so much of what we end up with for content has so little to do with anything other than personalities of our internal stakeholders or preferences or agendas or the politics.

It’s just incredible how our website is like a hotbed for political and personal strife. When you are dealing with highly resistant stakeholders, it becomes a sales process. That’s where every single person involved in the design at that process becomes a consultant, because you have to be able to identify, why is this person resistant?

What is this person afraid of? What is this person upset about? Why are they upset about it? What has happened in the past that has caused this person to push back so much on any level of change? Are they seeing guidelines as restrictions? Why are they seeing that? It becomes a lot more, at that point. Corey Vilhauer of Blend Interactive has done a really terrific job of writing about empathy in the design process.

I think maybe his work is geared more towards audience, having empathy for your audience. But in my mind, so much of the content process is learning how to empathize with resistant stakeholders in particular so that you can reach some sort of an agreement with them about, “I understand that these are what your needs are.

Now, we understand where those needs are coming from. Let’s talk about how we can align those with what we know are our user expectations and their needs so that we can get the work done and make sure that everybody is successful in this.”

It’s incredible. That can boil down to a short little paragraph on a home page, or what the subhead says on a landing page, for example. But, again, it’s making sure that people feel heard and making sure that you’re communicating clearly the context from which you are approaching the problem that will help move you forward in that conversation. Just sticking them with, “This is what the rule is,” that’s just going to put you backwards.

Adam: Laura asks a question back to the audit process and what that leaves you with. When you’re making that sample set of content audit, how do you make sure that you don’t lose long term maintenance of the pages? By maintenance, she’s talking about making sure that everything on the site is necessary, updated, and, probably most important, owned.

Kristina: In that instance, I probably would introduce… Well, let’s back up. Why is the sample audit being conducted in the first place? That is the core question there. What is it that we’re hoping to accomplish with that? Typically, in that instance, we’re looking at qualitative attributes. We’re looking at readability. We’re looking at audience relevance.

We’re looking at timeliness, to see whether or not it’s still on-brand. We’re looking at page structure. We’re looking at inconsistencies across different types of content. That’s typically, when we’re doing a sample audit, what we’re trying to get at and demonstrate in terms of the current state of the site as a whole.

When we’re talking about making sure that we have an eye on and are capturing and wrangling all of the content on the site, that becomes more of a management or, to her point, a maintenance issue. And then, in that instance, I would probably introduce more of a rolling inventory, which Lou Rosenfeld wrote about on a blog post quite some time ago.

That has been successful for many clients that I know in terms of really understanding the landscape of the site or the larger ecosystem of the website or websites that they are responsible for. And then, on a calendar, whether it’s a 6, 12, 18-month basis, really divvying up — “We are constantly going to be auditing the content on this site, checking for these specific attributes.”

Mark McCormick, who’s with Wells Fargo out in San Francisco, likened it to painting the Golden Gate Bridge, where you start at one end and you paint it section by section, and then as soon as you’re done with it, you start all over again. In that instance, if you are worrying about keeping track of all the content on your site, I would really recommend setting up some kind of an ongoing, rolling inventory like that.

Adam: One of the things that our audience is always after is the resources that our experts use. What type of editorial calendar tools do you use or recommend?

Kristina: I have yet to see anything more powerful than a simple Excel spreadsheet or Microsoft Project. I think that you can use tools like Basecamp and just set up alerts and tasks for people to manage. I will say that trying to get any kind of an automated editorial calendar, where people just seed the guidelines and deliver their stuff and it goes up and it goes live, you do have to have a person attached to it.

Think about how magazines have run for centuries at this point. There is an editorial calendar. Whether it exists in a spreadsheet or a Word doc or anything else, you’ve got to have somebody who is overseeing that and mapping the content development and ensuring that everybody’s upholding their end of the bargain.

Adam: Very cool. Thanks for circling back with us. Really appreciate it.

Kristina: Yeah, absolutely. I hope that this has been useful.

Adam: Time with you always is, so thank you.

Kristina: Oh, go on.

Adam: [laughs] To our audience, thanks for listening and for your support of the virtual seminar program.

Here’s an excerpt from the article

Having everybody reading the requirements document before a project starts isn’t just bureaucratic nonsense; it also ensures there are no surprises at the end. The problem is that requirements documents use words like “community,” “leverage,” “user-generated content,” or other buzzwords du jour that seem meaningful but are rife with ambiguities.

Each person develops his or her own interpretation of what these words and phrases mean and thinks everyone else’s interpretation is the same as his or her own. “These requirements look good,” thinks the marketer. “Yep, looks about right to me,” agrees the product manager. “Alright, I’ll go build it according to this document then,” says the engineer.

If instead, a comic illustrating the story of how someone may potentially use the product were shared among the team, it would be much easier to determine if everyone were on the same page.

Read the article: Applying Comics.

Have you used comics or drawing to communicate your design ideas? Tell us about it below.

The proliferation of mobile devices has made it necessary to rethink your web experiences. The mobile phone and tablet, along with retina displays, have substantially changed how a user experiences your design. Responsive web design has emerged as a solution in some cases, but even though connection speeds on mobile networks are increasing, performance remains an issue.

Luke Wroblewski has a wealth of experience with the mobile web. He suggests that the definition of “mobile” itself is blurring as devices continue to evolve. Rather than designing for device specifications, Luke says it’s more important to think about the context in which these devices are being used.

During his virtual seminar, Organizing Mobile Web Experiences, the audience asked some great questions. Luke joins Adam Churchill to cover some of those questions in this podcast.

• When you talk about “mobile”, does that include both phone and tablet?
• Is it better to use responsive web design than a separate mobile site?
• What are the benefits of native mobile applications vs. responsive UIs?
• How do account for different use cases when employing responsive web design?
• Does quality become an issue with the code base increasing to make sites adaptive?
• Should you make decisions on breakpoints based on content or device?
• Should you design differently for small screens and small windows?

Recorded: February, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Recently, Luke Wroblewski presented a virtual seminar called “Organizing Mobile Web Experiences.” Luke’s seminar, along with over 100 others that teach the tools and techniques you need to create a great design, is now part of the UIE User Experience Training Library.

In this particular seminar, Luke detailed the latest in mobile-design thinking and offered up solutions that will help you organize your websites and applications. He also showed what’s coming next and, best of all, how to help your designs remain future-friendly.

Hey, Luke. Thanks for joining us again.

Luke Wroblewski: My pleasure. Happy to be here.

Adam: Hey, for those that weren’t with us that day, can you give us an overview of what you talked about?

Luke: Sure. We focused on the art of organizing all your content and activities and structure of websites and applications in an ever-increasing, multi-device Web. We talked about a number of things, but we started out by outlining what are some of the things that mobile devices and the proliferation and heavy use of mobile that’s going on today, what are the sorts of things that that influences when we start to think about traditional website navigation, menu systems, organizational structures.

Once we nailed down where mobile takes us, we then built up from that mobile foundation to really create adaptive navigation and organizational experiences that support a whole range of devices.

It’s a pretty exciting space, I think, because, while we focused on organization and navigation, the techniques that we outlined can really apply to just about any component on the Web, We talked about nav and menus, but forms, content layout, any kind of interactive components, all these things can have the mobile-optimized perspective, and then use that mobile foundation to extend out to a wide range of devices.

Adam: One of the things that came up early on in the seminar is, there was a lot of talk about devices. Some folks were asking, “Does that mean specifically mobile? Does mobile equal phone? Does it include tablets?” Can you speak to that a bit? One of the questions that we didn’t get answered during the seminar asked about interpreting the device-usage graph based upon the answer there.

Luke: Yep, and boy, is it getting blurrier and hairier as we go here. In that short little overview, I think this sort of outlines where we’re going. It’s very difficult now to clearly outline exactly what’s a mobile device. It was a lot easier back when we had feature phones. And then out came the iPhone. It was really the first mobile computer on which you could browse the full Web. That was easy to grok. It was this 3.5 inch screen. It was pretty much the only thing out there.

Since then, what we’ve seen is mobile devices spanning the range from 2 inch screens all the way up to almost 7 inch screens. When you start getting towards the 7 inch screens, there’s 6.8 inch “phoblets” or “phabtops” or whatever. I don’t even know what you want to call them these days. They’re combination smartphones and tablets.

From that 6 inch range, they come down to 5.5 inch screens, things like the Galaxy Note. It’s not uncommon to have 4.5 inch screens. In fact, 30 percent of new Android devices sold in the past, I think, four to five months were 4.5 inches or higher.

Our traditional definition of what a smartphone is — this 3.5 inch screen — is really blurring. As tablets continue to blur as well, into smartphones and into laptops, it’s this really muddled space.

Which is why I think we need to think about adaptive, multi-device designs. It’s very hard now to quadrant things off. We have to make sure that we work on a full range of screens, regardless of what people may label them. As I alluded to some of these terms, like “phonblet” or “tabtop” or whatever people are calling them, it’s becoming silly to a certain extent.

To go back to the question with that context in mind, when people say, “Does phone equal phone or tablet, or both?” the way I like to think about mobile is, what enables mobility? That is, what size screen and computer can you conveniently carry with you, can you interact with with the palm of your hand anywhere and everywhere? For different people, that cutoff is a different size, depending on your sort of human ergonomics, but it definitely isn’t a single point in the spectrum. It’s a wider point in the spectrum.

When we look at studies of how people use traditional iPad-sized tablets — which is about a 9.7-inch screen, about a 10-inch screen — for those, only six percent of iPad sessions are actually on cellular networks, whereas for an Android or iPhone smartphone, it’s in the high 40 percents. 45, 42 percent of all network connections are on cellular networks. Which means that smartphones are definitely getting out there on mobile networks a lot more than the 10 inch tablets are.

Also, I believe 30 percent of time spent on the iPad is on the couch, and 20 percent is spent in the bedroom. It’s really, by those factors, more of a “mobile in the home” device. As you start to get to smaller and smaller tablet sizes — that is, you start getting down to more of the 7 inch range — all of a sudden these things start to become a lot more portable and thereby mobile.

I don’t think you can say “mobile equals tablet” because there’s this wide range of tablets. And I don’t think you can necessarily “mobile equals smartphone” because there’s a wide range of smartphones. I think you have to look a lot more at the modes of use and are they really mobility-driven. Are these things that people are taking with them anywhere and everywhere using them as a mobile device as opposed to the industry term for these devices.

Adam: Luke, what are your thoughts on the responsive-design experience versus the m-dot experience?

Luke: This is a very good follow-on question to what we were just talking about. Because of this continuous range of screen sizes, and variants and differences between mobile devices bleeding into tablets bleeding into laptops, it’s really, really hard, as I was saying earlier, to draw lines between things.

What responsive design allows you to do is build an adaptive layout that if a 5.5 inch screen or a 6 inch screen hits my website, it really doesn’t matter to me. The layout’s going to work well in both. If a 10 inch tablet or an 8 inch tablet hits it, it doesn’t really matter. It’s going to lay out really nicely.

When people talk about that sort of adaptive interface versus an m-dot experience, with the m-dot experience, unless you’re building your m-dot experience responsively, you’re missing out on a lot of that fluidity, that adaptiveness, and that possibility for your web service to work on a wide range of devices that’s ever increasing.

I personally think the benefits of that fluidity and flexibility outweigh some of the benefits of a separate m-dot experience today. It used to be a little bit different. All you had to contend with, as I was saying earlier, was the 3.5 up to 4 inch smartphone size as mobile. Now that mobile’s definition is totally blurring because of what we’ve [laughs] been talking about, I don’t think you can really get away with isolating things that concretely.

Adam: Say a bit about the pros and cons of mobile applications versus responsive UIs.

Luke: Yup. Here where I’m going to interpret mobile application, I’m going to interpret it in two ways. I’ll answer this question twice, depending on how people view mobile app. The first one, I’ll just say, an m-dot experience as we were talking about previously. That is, a website or application on the web designed specifically just for this assumed definition of mobile, which is probably just the smartphone thing, versus a more adaptive responsive UI.

When you compare and contrast those two things, I like to use a travel analogy, which is if you’re going on a trip. Frankly, you don’t know what the weather’s going to be like. You don’t know if it’s going to be really sunny. You don’t know if it’s going to be really cold. You really don’t know. When you pack, you bring stuff that you can be warm in. You bring stuff that is comfortable if it’s hot out.

That’s how responsive designs work. They come with a bunch of stuff that prepares them for any situation. In today’s device ecosystem, that’s usually a very, very good thing.

But if you know specifically where you’re going when you’re traveling — you’re going to the beach; it’s going to be 72 and sunny for a week — you can optimize how you pack and just bring the stuff you need, which is what a mobile-specific website allows you to do.

In particular, the thing that that is a benefit to for website and web application producers and development and design teams is really around optimization. That is, if I’m only packing the images, the markup, and the JavaScript that I’m going to use for mobile, I don’t have to bring all the other stuff for the other devices. I can optimize stuff.

I think that’s where these separate mobile web experiences still have a bit of an edge over responsive designs. They, by their nature, are just simpler and smaller because they’re only targeting a certain class of device, whereas the responsive designs are by their nature more robust because they’re targeting every single kind of device.

There’s definitely a lot that you can do to make responsive sites more performant and get some of that optimization, but it doesn’t come “for free” like it does with a separate set of templates in-site. That’s going to answer one if we interpret mobile app as something on the web.

If we interpret mobile app as something that’s native to an operating system — that is, a native mobile application not running on the web but running on a particular platform like iOS or Android — then the pros and cons list is a little bit different. The way you then think about the benefits of these native applications is you look at it as richness.

What can I use to create a richer, better experience that comes from that native platform? You’ll be able to get closer to the metal. You’ll be able to use hardware more. Different aspects of the software will be more performant because they’re compiled and running natively.

The benefits of a responsive design, then, instead of richness are really around reach, which means every modern device platform these days comes with a really good browser, a way better browser than we’ve ever had before. So when you build something for the web, you’re building something for every single platform, which gives you way more reach than an application you build only for a single platform.

I think that’s the simplest way I can classify the native-versus-web argument for mobile devices and beyond. It’s about richness, and responsive web designs are all about reach. There are good reasons for doing both. It’s not really a this-versus-that. It’s really understanding your goals and determining what makes the most sense for what you’re trying to accomplish.

Adam: Luke, in a responsive web design, aren’t we giving everyone the same site? How do you account for different use cases on different devices?

Luke: That’s a very good question. The assumption is, since I’m serving the same HTML markups, CSS, and images everywhere, every single device, whether it’s a smartphone, tablet, desktop, or laptop is going to get the exact same website and content.

The counterargument to this often is, “Well, don’t people use desktops and laptops differently? Aren’t smartphones and tablets used in different ways?” The answer is yeah, absolutely. They are used in different ways, but the fundamentals of what makes your site or application valuable to people doesn’t change because the screen size changes.

Let me give an example for this. I was on a panel a while back at this mobile conference. There were a couple folks representing the airline industry. They were making the argument that, “Our mobile experiences are really different. What people do on airline sites on mobile is, they spend a lot of time booking last-minute travel. That is, they book flights that are within 48 hours of departure. We really don’t see that much of that on the desktop.”

My counterargument to this was, “That’s awesome. You have that data and you understand this difference, but what are they doing on the desktop?”

“Well, they’re booking flights.” Fundamentally, they’re booking flights in both places. In mobile, they may be more in a rush, so they may want a more streamlined, more focused, faster flow. You may want to limit options and things like this.

But underneath the surface, the value you’re providing people across all those screens is around booking flights. This is where an adaptive design can actually help, because what you can do in the smaller screen experience is reprioritize and rearrange some of the elements to take into account these different use cases. When you shift up to larger screen size, you can reshuffle that priority and move things around a little bit more.

It doesn’t necessarily mean you have a totally different website. All you’re doing is taking this core use case of booking flights and adjusting it a bit to what makes the most sense on each device, essentially optimizing it through adaptive design for different use cases. I actually think a responsive and an adaptive interface is a benefit in these kinds of differing use cases, as opposed to a con.

One other example, just to drive this home. I know this gets discussed a lot, so it’s worth drilling into a bit.

Another common example of where people cite mobile behavior as different from desktop and laptop behavior is if somebody has a physical location, like a museum. It’s not uncommon for them to see in their logs that people on mobile tend to go to the visiting hours, driving directions, and parking information type pages. There’s a higher mode of use of those sorts of pages and information on mobile then there is on, say, desktop or laptop.

But that doesn’t mean that somebody on a laptop or a tablet doesn’t want to see driving directions or hours. That doesn’t mean that somebody on a smartphone doesn’t want to see pictures of the exhibit or the calendar of events. It just means that the relative priority of content is a little bit different.

What you could do with an adaptive layout is make the “Driving Directions” and “Hours” button big on a small screen view, and then make it a little bit smaller as you adapt your layout to a big screen view. Again, you account for these different priorities of content, but at the same time you’re not excluding any content from anybody just because of their screen size or device type.

Adam: Luke, as the requirements for making sites more adaptive and doing so for more devices and differing devices, will we reach a point where the code and infrastructure needed to support this decreases the site responsiveness to undesirable levels, and quality becomes an issue and usability becomes an issue?

Luke: This goes right back to the analogy I made at the beginning, of packing everything you need because you don’t know what you’ll find on the other end. When you do that, naturally you’re bringing more stuff. The suitcase is heavier. It takes a little bit more effort to lug it through the airport and those kinds of things.

If you pack way too excessively, then you might not even be able to get your suitcase into the airport. Or to really stretch the metaphor, they might not even put it on the plane because it’s too heavy.

When these adaptive and responsive methodologies first came out — I hate to say this almost — it was really around the cool factor of being able to adjust the layout and have a different layout on a different screen size, which is very useful. You can use that to optimize the interaction and visual design of things, but oftentimes it was a net negative for performance.

Over and over again we see, the faster you can make websites and web applications, the better your metrics skew. Reducing 100 milliseconds of load time can lead to more conversion, more revenue, more engagement, more page views, all that good stuff. The very strong concern here is, if I start to do responsive stuff, am I negating all those performance values because I’m bringing on all this additional stuff?

While these responsive methodologies started with these layout examples, the conversation these days and increasingly over the past year is all about performance. How can we make sure that we are in fact delivering the right level of file size, not bringing over unused assets, being judicious about how we load assets, and those sorts of things?

There’s a lot of patterns of things like Ajax-include, which picks which content to load on which screen, defers loading on content, or just more smartly loads content, that are bringing the conversation to making site responsiveness more and more desirable, to use the language of the question.

When you do this sort of methodology, you’ve got to keep your eye on the performance prize. You can’t ignore optimization, speed, download, and all those things that we’ve been focused on a lot on the Web. That doesn’t go away just because you have a responsive design. You may, in fact, have to learn new techniques for getting there. It may be a little daunting, but got to be done.

Adam: Luke, my recollection is that there were a bunch of people who were looking for some advice on media query breakpoints. One in particular, I thought, was a really good one. Do you make those decisions based on content or the devices?

Luke: Just to bring everybody to speed up on what we mean by media query breakpoints. In an adaptive design or responsive design, when do you decide to change your layout? You hit some threshold of screen size.

The way a lot of people used to do this was, they would say, “At 320 pixels, because that’s an iPhone, I’ll have a different layout. At 1024 pixels, because that’s an iPad, I’ll have a different layout.” They made these adjustments based on the current dimensions of popular devices. That’s why I used the iPhone and the iPad as an example there.

But if you go back to the very beginning, when we were talking about how all these different form factors and size of devices are coming out and more and more of them are emerging every single day, that doesn’t really become a long-term sustainable model.

Let’s say the next iPhone is 360 pixels, or the Galaxy Note takes off and it’s 720 pixels. You find yourself in this rat race with the device market of what’s popular and what’s not, trying to tie what your design is doing to a series of manufacturer specifications.

What you can do instead of trying to look at these breakpoints at where the popular device screen sizes are, you can look at them as, “Where does my design actually break?” It doesn’t really matter what screen size it’s on. It’s just, as I’m gradually looking at it on different viewports, when it hits a point where something becomes unreadable, something becomes, how shall I say, overly ugly…

[laughter]

Luke: …I guess, looks wrong. That’s a place where your layout is broken. You can take this term “breakpoint” literally and say, “Look, people can’t read this. It’s broken. This is just ugly. It’s broken.” That’s where I need to insert a breakpoint.

You use those breakpoints as content-driven. Where my layout or my content fails to work, it’s a breakpoint, and I need to make an adjustment to my layout so it works better. I think that’s a lot more future-friendly than sticking to the current landscape of device sizes when you think about this.

Adam: One of our attendees made the point that small windows are different than small screens, and wondered if you make different design choices for those different experiences.

Luke: I think this is actually a real nice question to wrap everything up that we’ve been talking about so far. As we’ve been talking about, small screens and different kinds of screens can actually have different use cases. Adapting our layouts based on those use cases and re-prioritizing and reorganizing information can help address the small-screen problem, if you will.

The adaptive designs and adaptive layouts of responsive web design, as we were just talking about a second ago around basing these off of content, can address the small-windows principle. That is, whatever size window you happen to encounter, you can adapt your layout to it.

I don’t think these two things are mutually exclusive. In fact, I think, together they form a really great methodology for dealing with multiple-device design.

You’re not just looking at screen size. You’re also looking at how people actually use these devices. At the same time, you’re making sure that it works on every single screen size. It’s a win-win on both sides. For that reason, I’m really excited about where this stuff is going and how it can reshape what we’ve been doing on the Web over all these years.

Adam: Very cool. Awesome stuff, Luke. Thanks for coming back to join us for a bit to talk a little bit more about this.

Luke: My pleasure. Hope it has been useful for everyone.

Adam: To our audience, if there’s a need for mobile design resources and information, you would be doing yourselves a great favor by going to Luke’s site, LukeW.com. It’s loaded with Luke’s thinking, lots of great statistics, and all kinds of stuff in this fast-moving, fast-changing environment, so go check that out.

Thanks for listening, and thanks for your support of the UIE Virtual Seminar Program. Goodbye for now.

Here’s an excerpt from the article

Which is more expensive: a responsive design web site or creating a separate mobile version? This is a constant debate among many organizations. We can answer it with some simple design accounting.

For the most part, you don’t hear anyone saying that responsive web design is the wrong way to go. It’s motherhood-and-apple-pie to have a single design that works everywhere. Everyone seems to agree this, in the long run when all the planets align, is the best alternative.

The argument I keep hearing against responsive web design has to do with cost. Creating a site that dynamically adjusts to size, resolution, and bandwidth is an expensive proposition. It often demands a rethinking and retooling of the entire process.

Read the article: Conducting Usability Research for Mobile.

Have you proposed or defended the value of a mobile content strategy? Tell us about it below.

Storyboards capture an experience in a visual way. They communicate complex ideas in succinct, understandable ways—whether for planning a feature film or the user experience of an application.

Kevin Cheng uses comics to make storyboards more understandable. In this seminar, he talks about how organizations like Google, eBay, and the U.S. Postal Service have opted for comics (instead of lengthy reports or requirements docs) to tell the stories of their users and their products.

Oh, so you can’t draw? He’ll show you you can. You don’t need illustrator skills to do it, either. Kevin will show you how.

Register before March 25 and you’ll receive a free PDF chapter from Kevin’s book, See What I Mean. It’ll be in your confirmation email. No need to wait!

With the emergence of techniques like responsive web design, many of the traditional prototyping methods become difficult to employ. Sketches and wireframes have in some cases given way to HTML and CSS prototyping so that users and clients can experience a richer, more complete interaction.

In his virtual seminar, Prototyping a Responsive Design, Jason Cranford Teague dove into some of his real-world experiences with prototyping. He shared insights and challenges he’s encountered through his agency and client work. His seminar prompted some great questions from our audience. Jason joins Adam Churchill to tackle some of those questions in this podcast.

• Should you use your production CMS in prototyping?
• Is it better to design mobile first or to use responsive web design?
• What tools are available for making interactive wireframes?
• How can you simulate gestures in prototypes?
• How does the use of images in responsive web design affect performance?
• Is it better to have multiple CSS files or just one?
• How do you design for the context of devices, rather than just constraints?
• How does responsive design fit in a Lean UX process?
• Where do you fit testing into developing a responsive design?

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this fall, Jason Cranford Teague joined us for his virtual seminar, Prototyping a Responsive Design.

In the seminar, Jason got attendees to think about expanding their design skills beyond sketches, wireframes and visual comps and exploring the rich interactions possible in today’s real world web.

Hello, Jason, welcome back.

Jason Cranford Teague: Hey, Adam, thanks for having me.

Adam: Sure. You’ve had some changes. What’s going on with you these days?

Jason: Well, recently, I left the agency I was working with and I’ve started doing my own freelance thing, trying to broaden my horizons and helping people with Internet strategies and working on this responsive design stuff and reaching out and doing a lot more educational type stuff. As well as just working to get a little bit more high level with the people, helping them understand what they need to do in order to really communicate effectively on the web.

I’ve been working with Lou Rosenfeld over at Rosenfeld Media — I’m one of his experts now, he’s got me on the website — teaching some classes, doing some daylong seminars for different groups and just having a great time doing that.

Also, just had a new book come out, “CSS3 Visual Quick Start Guide,” Sixth Edition. It’s the sixth time I’ve tackled this. Actually, the funny thing is, the book started out, the original title was “DHTML for the World Wide Web.” But after a few editions of that we kind of realized no one was really talking about DHTML anymore.

[laughter]

Jason: I know, right? I wonder if anybody even remembers what the D in DHTML stands for anymore.

Adam: I don’t.

Jason: [laughs] Dynamic, for you trivia buffs out there. And so in the last edition, we just focused the book on CSS3 and this is an update. We went all color with this one. It had been a black and white or one color, it had red in it.

Adam: Nice, nice.

Jason: Because full color, yeah. I was real excited. It did mean I had to go back and redo every example in the book so that it was more colorful.

Adam: Oh.

Jason: You have fun doing stuff like that.

Adam: Sure.

Jason: That’s what I’ve been up to, and then doing a lot of writing. I’m trying to work on some magazine articles for different places and just working hard.

Adam: Excellent. Well, listen, you gave a great virtual seminar back several weeks ago. Maybe for some folks that weren’t listening in that weren’t with us, can you give us an overview?

Jason: Yeah. The idea originally behind the seminar was to present some of the real-world experiences I’ve had with prototyping over the years and the evolution of thought of where I’ve gotten to with prototyping, especially with the emergence of responsive design.

One of the things I’ve found in the last couple of years was that when responsive design came along, some of our older techniques, sketching out wireframes, using programs to draw what the website was going to look like before we made it, were going to become really difficult to maintain.

It’s one thing to do a wireframe in Visio or OmniGraffle of a single Web page and then replicate that for all these other Web pages. Then when you’ve got to actually do that for a medium version, for a small version, you’ve at least tripled your work, if really not more.

I realized there had to be a better way. What I did in the seminar is I went back to my days when I was working at Marriott and showed how I used some early prototyping techniques I was developing.

I actually took the final design and then tried to show how it would be developed in the real world to show some of the inherent problems that we were going to face. I was able to show my group that the way it was designed just wasn’t going to be sustainable on the web. The file sizes were going to be too large.

But I was then able to take that and modify the design slightly. In my prototype, I showed how much more smoothly that was going to work. I could show my team exactly what the differences were and exactly how it would act and interact. That was kind of the beginning of my journey towards a more full development of prototyping as a way to document your design.

I then went from there to my last agency, Forum One, where we ran into similar problems where we wanted to show the client how, especially responsive designs were going to work. We were just getting into the responsive design world about two years ago.

Our clients were having a really hard time understanding what this stuff looked like. I mean, we could show them sketches all day long, but they didn’t really get how it went from one to the other to the other in terms of size.

I had a client say, “I really want to see this, can you wireframe it out?” I went home and I started working on paper wireframes, and I thought, why don’t I just do it out? I know how to code this. I just coded the CSS and made it so that when you shrank the browser window, it would flip to the next size for responsive design.

I took that into the client and they could literally see where the break points were, what would happen to the design when it went from large to medium to small. It was a really effective way of explaining it to the client. It didn’t touch any of the core information architecture software that we’ve come to rely on. Instead, I was just using HTML and CSS.

But I realize a lot of designers and information architects, they’re not as comfortable with the coding side of things. I don’t want to say, well, you’ve got to learn coding. I’ve started working with my team to figure out a way we could come up with some sort of program or something, some sort of design studio, if you will, that would allow anybody with only just a very minimal amount of coding knowledge to quickly throw together these responsive design prototypes.

That’s where I came up with the idea for what would eventually become Proty. Proty is a prototyping, it’s hard to say. It’s a plugin to Firefox right now, is what it is. Due to some realities of the skillset we had in house and how applications get made, we found it was easiest just to create this thing as a plugin for Firefox.

You load it and what you do is, you pull up a template page and then you can start placing your components, you can start placing your modules on the page and start laying out your page from kind of these pre-built components.

You can work with a developer and have them, or front end developer and have them develop more components for you if you want. If you’ve got even a little bit of knowledge, though, you can get in there and start adjusting them the way you want them or even build your own.

We found it was a quick way to kind of throw together these responsive design prototypes, because it had the responsive design basics built in from scratch. You could click a button and you could see what the design would look like on a tablet. You could click a button and you could see what the design would look like on a smart phone.

You could even show and hide different elements depending on the view that was being shown. If you didn’t want a particular module to show up on the smart phone, you simply hid it from the smart phone view.

We started using this with clients and really found it to be a great way to get the point across. The thing about doing this type of web design is that clients really have a hard time imagining how something static becomes something dynamic.

Now, we’ve all trained for years to imagine when you hover over this button, what does it mean when the color changes? What does it mean when it’s something fades up or fades down? But clients, they’re not generally educated in that type of thinking, and so it’s much harder for them to get that. I found that a lot of our meetings were spent trying to explain to them very visual, very conceptual ideas and Proty allowed us to more quickly just simply show them rather than tell them how things work.

Now, Proty is open source and free to anybody who wants it at protytype.com. That’s Protytype.com. Just sign up for the mailing list and you’ll get a link.

Part of Proty came out of my own study of other tools. One of the things, one of the last things I did when I left Marriott was do an evaluation of prototyping tools for the company. They were looking at trying to find some way to head off some of the problems they’d had.

They looked at Axure, and they looked at Balsamiq, and they looked at using Flash. The problem with these was that none of them actually presented the reality of what could be done on the web.

One of the things that I thought was key to making a successful prototyping tool is that, not just making it look right, but making it act right. Making sure that you can’t do things in it that would be impossible or at least difficult in the real world of the web.

On the flip side, being able to do everything that you can do on the web that you couldn’t do in a lot of these other products. For example, one that I point to a lot is box shadows. Box shadows, on the web now, you can have multiple box shadows. You can put multiple shadows beneath any box in your design, allowing you to create a variety of really cool effects.

Now, Photoshop or Balsamiq or Axure, any of those other programs with very limited design controls, either it would be extremely difficult to do that, to the point where a designer just wouldn’t want to mess with it, or completely impossible. Yet, in Proty, those types of techniques are easily done just as easily as if you were creating it on the web.

It also uses HTML5 and CSS3, so it’s up to date on those coding standards.

That’s what I’d looked at, I wasn’t trying to sell anything there, because as I said, it’s free. But I did want to explain how I got to that need to create a tool like Proty.

Adam: Awesome. Well, there were a bunch of great questions and I think, based upon the questions we got, our audience of designers and UX professionals was pretty broad. Let’s start with some foundational stuff.

There were a couple of folks that were wondering what the best way for designers to get a good basic understanding of HTML and CSS is. They were looking for your recommendations on that.

Jason: Yeah. That’s funny, I get that question a lot. It’s always a good question. It seems like it would be, oh, go to this source, go to that source.

The advice I always give people who want to learn design is to pick a project, a project that maybe slightly, you’re a little bit uncomfortable with, not too uncomfortable, but a little bit uncomfortable with. Get a book like mine, “CSS3 Visual Quick Start Guide,” or others. There’s obviously lots of good books out there. Something that gives you the basics and foundations of HTML5 and CSS3. Then, take your project and start working on it.

The best way to learn how to do this is not just by reading a book or following steps. It’s to actually problem solve yourself. It’s to, “OK, I’ve got this problem. I need to figure out how to get this text to do a particular thing. How do I do that?” You’ve got your reference book there to help you, but you’ve got to figure it out yourself.

As you work through these problems, that’s how you really internalize these skills and build up these skills. And I say that because that’s how I learned how to do web design. When I started, there were no books on web design. There were literally no books on web design, and I was given a magazine, the “Computer Mediated Communications,” magazine and was told, “Hey, we need a design for this.”

I just went in there and started to experiment and play around and came up with a design. I wouldn’t show it to anybody today. It was pretty ugly, but I got it done, and that’s where I started learning.

Adam: Getting into the tools, Jason, if you’re working with a content management system — and the example one of our attendees asked is Drupal — for your production versions, why wouldn’t you start with that?

Jason: Well, I’ll let you in on a little secret. I work in WordPress primarily for my own work, and I actually do start prototyping oftentimes in WordPress. I’ll just start working away in WordPress. I do that because I have a lot of CSS and HTML and JavaScript skills, though, and I know how to do that so I can get in there and start pushing modules around and building pages and coding stuff.

Drupal is a little bit more complex. It’s gotten better over the years, but it’s still not as easy to start throwing modules together, especially if you’re not a developer yourself. So the answer is, if you can, sure, go ahead and start working in the actual final technology that you’re going to be deploying in if you can do it just as quickly.

We developed Proty because a lot of our IAs and lot of our designers really couldn’t get there very quickly. They couldn’t start just working in Drupal. So we needed that kind of intermediate step, something that they could work in that would as accurately as possible represent that without having to have that huge steep learning curve of learning how to do PHP, for example, in order to code the stuff.

So it really depends on your own skill level and level of comfortableness with the content management system that you’re working in. I would also say, though, that I find that works fine for simple sites starting in the CMS. I will say more complex sites where you’re maybe building very complicated interactions or community sites, those aren’t always going to be as forgiving if you need to make large scale changes later.

So working in a simpler system where you’re prototyping may save you time in the long run because you won’t be rewriting a lot of this very complex code. You’ll just be testing out kind of this more minimalistic, higher level version of the code where you can simulate what’s going one rather than getting into the time and depth it would take to create the full realized version of the site.

Adam: So our attendees are asking you to pick sides here. There’s a comment that the mobile first proponents say media queries aren’t supported by all mobile browsers and further is flawed. So media queries for responsive designs or this thinking of mobile first?

Jason: I don’t think they’re mutually exclusive. Mobile first, really, uses media queries. The idea is that whatever the experience, a style sheet gets delivered that then renders the design as well as possible to the device being used.

There are two ways of looking at mobile first. The first way is that you start with your design in mobile. So you start designing the mobile experience first, and then you scale up to the tablet, and then you scale up to the website version. And the thinking here is that more and more people are going to be accessing web work through mobile devices, especially smartphones and tablets.

The second way of thinking about it is that you deliver as a base experience to the end user the mobile experience. So regardless of whatever device they’re using if they don’t support media queries they get this basic level of CSS support, and that could be called the mobile version. I usually call it the small version.

And that’s actually how I prefer to think of mobile first is that you’re delivering this base level experience first and then building on that as media queries allow or not allow.

Now, this can get a little tricky because then you’ve got IE 8-7 on back ad infinitum that may get a more limited experience as a result, but I’m also a huge proponent of the idea of progressive enhancement where every experience on every browser doesn’t have to look the same. It just has to work. So that’s where I come down on that. I think media queries actually play an important part in the mobile first experience.

Adam: Our audience is always looking for our experts’ thoughts on different tools and resources so a question here is what are your thoughts on using Fireworks or programs like that to make wireframes interactive?

Jason: Those work, and Fireworks is one that it’s kind of a shame I don’t use Fireworks. Fireworks is a much better program for doing comps for the web, but unfortunately I’ve been stuck in Photoshop so long it’s hard to escape, because it also allows for that more interactive…you can kind of program in how the different interactions work and simulate them that way.

You can also use Visio to do the same thing or actually more OmniGraffle. OmniGraffle is really good at creating interactive clickable prototypes. The problem with both of those, though, is they are not the reality of the Web, and as good as Fireworks is, it still doesn’t work exactly the way CSS works. You still can’t do everything that you can do in CSS.

It’s a different mentality when you’re working in Fireworks than when you’re working in CSS. And really what I’m encouraging web designers to do is to learn CSS, not so you can code necessarily — that would be great if you could — but so that you can understand the thought behind CSS so that you can design better for that medium.

It’s kind of like if you were designing for print and you didn’t understand how ink dried to how ink worked, or how colors combined to create your finished product. You couldn’t design as effectively that way because you don’t understand how the final process is going to render what you’re going to design. So I always encourage designers to learn as much CSS as possible and start working in it when they can.

Adam: When you’re thinking about the theme for the content management system you might be working with what features should you look for to insure you can take full advantage of the techniques of responsive and adoptive designs?

Jason: Mostly the responsive designs I’ve been working with have been in Drupal or in WordPress. Drupal, my team and I studied it and we came up with the Omega theme as the one that met the criteria we wanted. It had the best collapsible grid structure allowing us the most versatility. It had several columns rather than jut a few, and the more columns you have in your design the more layout possibilities you have.

It had kind of a bottom up approach — bottom up is more mobile first type of strategy — where you start with the base theme, the base styles, and then build on that as media queries allow for larger and larger devices.

It also allowed us to change it enough so that we could put in kind of our own special sauce, including built in menus for the smart phone version. It would automatically take the menus we put into our HTML and turn them into kind of that iPhone-like menu bar at the top that you would tap and then you’d get a drop down menu from there. It’d automatically do all of that type of stuff.

The one thing I’ve found in working with responsive design, though, is that once you do establish your base theme, once you do find the theme you want to use, whether you’re working in Drupal or WordPress, there’s very little you have to do on the back end once you get going. In fact, really, you shouldn’t hardly ever have to touch the back end.

Instead, all your thinking is going in the front end. How different things collapse. Do they stay? Do you use the exact same functionality between the smart phone version, the small version, and the larger desktop version? Do you present the same search field? Things like that are going to be more critical and more a part of your responsive design thinking than the base theme you end up with.

Adam: How are you simulating gestures in your prototypes? What tools are you using to do that?

Jason: That one is something that also is built into the base theme. I leave that a lot for my UI developers. It’s something that you use JavaScript and HTML5 to do.

I just created a site using the impress.js framework, which I adapted to use in WordPress. I’m not sure if you’re familiar with it. It’s a really cool framework that was originally created as a HTML5 alternative to Prezi, if you’re familiar with Prezi. They wanted to do the same thing Prezi does, but Prezi uses Flash and they wanted to do it all in HTML5.

Well, I’ve done several presentations that way, and I was like, this would be really cool to do a website in.

One of my friends, he actually used it to do a magazine, and he very graciously gave me his modifications, his modified version of it to use on yurisnight.net. If you go to yurisnight.net. Yuri’s Night is an event every April 12th to celebrate the first manned space flight by Yuri Gagarin. I’ve been their Internet strategist for the last several years. I get to experiment with the design there. It’s pro bono, so they give me a pretty wide berth when it comes to what I do with it.

I used it there and one of their concerns was, well, how is this going to work on tablet and smartphone. For the tablet, what we ended up doing, rather than using gestures was we provided two large buttons on the left and the right that you can push to go forward and backwards in the site. You can also use the main site navigation if you want.

I think anytime that you’re dealing with a site where people are used to interacting with websites using scrolling, and you’re going to do something different, it’s important to give them clear call to actions, rather than expecting them to know to swipe.

Now, that’s likely to change over the years as people get more and more comfortable with websites that allow swiping and pinching and so forth and so on. But for right now, I would stick with clearer button controls to help people navigate sites on tablet devices.

Adam: Let’s talk about images for a bit. Are you using the same image or multiple images via the CSS? Regardless, how’s that all affecting performance and download time?

Jason: Could we not talk about images? Because that’s the bane of existence of all…I’m joking.

It’s a huge thorny issue. I actually spent an entire day once trying to come up with a pure CSS solution to the problem. And I did, I came up with some solutions, but none of them were good solutions.

One solution involved putting all the images as background images so that the CSS could then present whichever one was needed. But then, all the images are background images, and it interferes with findability of the site and people can’t copy the images anymore, which admittedly, might be a benefit for some organizations. But it didn’t really work well.

The other alternatives involve, the basic issue comes down to, let me back up and present the basic issue, if you’re not familiar with it. If I am on a desktop machine, I have a larger screen, so I’m going to see larger images. If I’m on a tablet, I’m on a smaller screen, so I need smaller images. If I’m on a smart phone, I’m on a still smaller screen, so I want to see still smaller images.

Now, you can resize the same image between those to fit the screen. The problem is, if you’re resizing the same image, you’ve got to make sure that it looks as good as possible on the large screen, and thus, you’re presenting a large image size, file size, and then downloading that same file size to the smart phone, to the small device, even though it doesn’t need that big a size.

The issue really comes down to speed, because we’re used to smart phones. If I’m out wandering around on my smart phone and I’m on my 3G network, it’s not going to be as fast as my cable modem setup at home. We don’t want to force smart phone users to wait for the same image that I would be waiting for at home.

How do you deliver different image sizes depending on the device? There are a lot of different solutions, but there isn’t a magic bullet yet. There is not a perfect solution yet. Some involve back end coding, which I won’t go into here. It is part of responsive design, but it’s far more than the design. It’s really down to doing server side coding.

Some people use JavaScript solutions, but I’ve yet to see one that works perfectly yet. I think people are still kind of searching for that.

My theory right now is to use the same-size image and shrink it for the device. That’s the simplest method, and to be honest, it does remind me of the problems we used to have in the early days of the Web, when people were worried about things like color.

We had 256 colors that we could choose from. You remember those days, Adam?

Adam: I don’t.

Jason: Oh. OK. Well, back in the day. [laughs] Back in my day, we only had 200…

Adam: [laughs]

Jason: No, seriously. That is true. In the 90s, most monitors could only display up to 256 colors. And so designers were told not to use anything but those core 256 colors. Many writers got their start writing books about how to get the most out of those 256 colors. We went mad doing entire designs using nothing but 256 colors.

That included for gradients, too. So, lest you think that I’m being hyperbolic, it really was a huge limitation. And then gradually, people’s monitors went to thousands and then millions of colors, and that problem completely disappeared.

It’s not even something you have to even vaguely think about anymore. And I see the same kind of happening with these devices. Every time I turn around, a new standard has been announced making WiFi faster and faster and faster, and making the mobile devices faster and faster and faster. So, we’re struggling with this issue. Why are we worried about image size again? So, it’s kind of a wait and see. And that’s why I always go with the easiest solution in those cases.

Adam: So, we get to talking about all kinds of solutions that CSS files can provide us. There was a question that asks, what’s better — multiple CSS files or just one?

Jason: One, to be honest. If you can get everything in one file, that is your best bet. And there are ways to do that. There are ways to code it so that you can do that. Practically speaking, though, that’s not going to be the optimal way to do it for responsive design.

Again, let me back up and explain what the issue is here. The more CSS files that you are linking to or importing, the slower your site is to load. Because every one of those files gets a separate server call. The parts are greater than the whole. Every time you make a server call, it delays your page load even just a fraction of a second. But those add up. So, the more you call, the slower it goes. If you put all that same code in one file, that’s one call, so it’s relatively fast.

My rule of thumb is to try to keep it below four. Five is the max. If you can get away with three, then go for it. Then you’re great.

Another option, as again, it’s a server side option. What I see some companies doing is they kind of develop using as many style sheets as they need, but then their server will bundle all of those into a single style sheet for delivery to the end user.

Adam: You said in the virtual seminar, you used the phrase context is queen. And the question came in, how do you understand the context of use for specific devices, a phone or tablet device, to make sure that the design best supports those contexts and not just the constraints of the given device?

Jason: That’s a great question. That content is king, always bugged me a little bit. Because I was like, there’s more to it than content. And so, I was thinking one day, I was actually giving a talk. And context is queen, just kind of came out of my mouth. I was like, I need to write this down.

Adam: [laughs]

Jason: So, yeah. So how do you know the context, and you’re not just designing to the device, because to a certain extent we’re going to be designing to the device. But what you as a designer have to do is think about more than just the device. Think about the person who is holding that device, and what they are, and what you can assume about what they are and are not doing while they’re holding that device.

So, let me give you an example. We know that if someone is using a smart phone, they have a small screen size. And you’re going to scale your design to that. But as designers, we need to go beyond just thinking about OK, so they’re looking at it on a small screen. If they’re looking at it on a small screen, then what does that mean? Well, they could be sitting at their computer looking at it while they also have their desktop. But they also could be walking around. They could be sitting on a sofa. They could be in their doctor’s office waiting for an appointment.

There’s a broader context, to which they could be looking at your site. If they’re on a desktop machine, or even a laptop, they are almost guaranteed to be sitting down. There is a different context there.

So, you want to think about how to deliver an experience based on your professional knowledge of where you think your audience is likely to be using your website. So that gets down to fundamental questions. What is your website for? If it’s a banking website, and they are using it on a smart phone, probably they are running around. It may be that they need to check their balance very quickly to make sure that they can do this transaction.

When I was working on the Marriott app, unfortunately this didn’t make it into the final version. I put myself into the context of somebody using the app. I thought OK, I just got off my plane, I need to know where my hotel is. I pull up the Marriott iPhone app, the first thing I want to see is where is my hotel. What’s its address, I want a button to be able to call it. I want a button to be able to see a map on how to get there.

So, think about that context when presenting the content and functionality for the site.

Now, if I’m sitting at my desktop and I come to the Marriott website, the first thing I probably want to do is book a hotel room or learn about vacation packages. It’s a very different context than if I’m on the phone device, where I’m probably on the go.

Adam: Jason, the next question probably is a virtual seminar in and to itself. But how does responsive design fit into Lean UX design?

Jason: Oh, yeah, that’s a great one. I think they’re really natural fits in a lot of ways.

Lean UX is the idea that you need to try and cut out as much of the paperwork as possible. That gets back to another reason I had my team and I worked on Proty. We were trying to reduce the amount of paperwork we were doing. We were trying to reduce the number of cycles that we were going through trying to get to this paper-based prototype.

I sometimes refer to the fidelity cliff. What the fidelity cliff is, it’s that point in every project where you start spending more time refining your documentation to try and get it to a higher level of fidelity that is closer to reality, closer to the product you’re trying to create, and you see diminishing returns. You spend more time with less fidelity added to the product. That is the antithesis of lean UX.

With a prototyping tool, you can keep increasing that fidelity even though you’re spending more time on it. That, to me, is the heart of lean UX is trying to increase fidelity of whatever you’re doing, whether it’s a prototype or the final product, with as minimal amount of work documenting that and trying to explain it as possible.

I think, early on in the web, we were looking to architects as kind of a model for how we build websites. We call them information architects, after all. We developed wireframes as kind of a replacement for an architect’s blueprints.

In fact, I remember, in my early wireframes back in the late ’90s, I actually really tried to make them look as much like blueprints as possible. I used light blue lines, I did the little thing at the bottom, the little pill at the bottom with all the information and stuff like that. Over the years, I’ve realized that that’s not a good metaphor for web design anymore.

Back then, putting together a website was a lengthy and laborious and expensive process, because we were starting from scratch every time back then. Every time you started a new website, you were starting from scratch. We didn’t have CMSs, we didn’t have frameworks to start from. We were starting from scratch.

Now that we have all these frameworks and CMSs in place, I wouldn’t say it’s a waste of time, but it’s not as necessary to create these thorough documentations of the product like we used to. Because the difference between a website and a building is that if the website has problems, it doesn’t fall down and people generally don’t die.

With a building, you really have to make sure everything is perfect before you start building. With a website, you don’t have to make sure everything is perfect, and you don’t have to know where everything is going before you start building.

Adam: There was a question about testing. Obviously, something we do a lot of here at UIE. The question speaks to how you often test designs before working out a lot of the details of coding and creating the visual design treatment. But how does it fit into the process when you’re thinking about responsive design? How’s that time table of testing the design fit in there?

Jason: That’s a great question, because I think testing is vital to getting the best possible solution. But when you test, it’s difficult sometimes, again, just like clients have a hard time imagining how something is going to work. The people you’re testing will often times have a hard time imagining when you say, “Oh, this is just a wireframe.” Most people don’t know what a wireframe is.

If you’re testing with a wireframe, it is going to affect how people interact. It is going to affect where people look and what they see and how they interact with it — which is why I try to get as close to something that looks like what they’re going to be interacting with as possible.

I think that might put me at odds with some who want to kind of keep that base level when you’re testing. You want to just kind of test the ideas and not the whole fully realized design. But the more I get into it, the more I find that if I can give something to somebody that looks very much like what they’re going to be working in, I get a more honest reaction from them.

What I’ve been striving to do recently is to develop those tools that allow people to do the same tasks, do that same testing, do that same AB testing, but with something that’s going to be easily changed. If you don’t like the design, change it. But it allows them to test in a more realistic atmosphere.

Adam: Jason, some of our audience members were looking for just your experience. They want to know what responsive frameworks you’ve used and what you recommend.

Jason: Other than rolling my own, which I’ve done from time to time, I’ve used the Omega theme for Drupal, which works really well. That was the primary one I used in my agency work, and we deployed that on numerous different sites, including the Aspen Ideas Festival. That was the first place we did that.

Another one I worked with for Drupal was the Mojo theme. The Mojo theme is a really interesting one. It was actually developed by one of the front end developers who I worked with at Forum One. He actually came to us and started working for us and he had this theme that he was developing.

We used that on several different sites, I mean, pretty successfully. It had a slightly different take on responsive design. It was a little less mobile first, and so we did have some issues trying to get it to work on older browsers. But I think he’s licked those issues.

Those are two that I recommend. There are a lot of other ones out there, so if I haven’t mentioned them, it’s just because I haven’t worked directly with them.

You tend to want to kind of pick one and stick with it. Because if you keep hopping around between different base themes, then you’re relearning it every time, you’re relearning its limitations and its benefits, and you end up increasing your project time, as a result.

For WordPress, I’ve not worked with a lot of different WordPress responsive themes. I did, though, take the impress.js theme I mentioned earlier and it’s got an interesting responsive nature to it.

I’m still tweaking, for Yuri’s Night, I’m still tweaking the small and medium versions. If you look at them now, they’re not quite as perfect as I plan them to be in the next few weeks. That was a lot of fun, because I took kind of this framework and put it into WordPress and then played around with that.

As I said, it gets back to how I said it’s best to learn this stuff. That’s how I still learn. I kind of took something a little bit outside of my comfort zone. I’m not as much of a back end coder or PHP coder as I used to be. I took something a little bit outside of my comfort zone and made myself learn enough to be able to do it and work with it. I learned a lot on the project by pushing myself to do that type of stuff.

Adam: Awesome. Wow. Lots of stuff we covered today. Good stuff, Jason. Thanks very much.

Jason: Thanks a lot, Adam.

Adam: For folks listening in, thanks for your support of the UIE Virtual Seminar Program and goodbye for now.

Here’s an excerpt from the article

Jared: Does mobile usability testing require a lot of hardware?

Cyd: It can. I think there’s a bit of a perception that it requires more than it actually does. If we’re going with the traditional lab model, and we want to take perfect videos and to get every single mobile device that our audience might use all lined up in the lab. Pretty soon, we’re indeed talking about 20 pieces of hardware in addition to what we’d normally have for a test.

But there are ways minimize it a bit, and there are ways to do it without adding on too much hardware. Think a little bit more about how you might do a guerrilla research study or how you might do a study in a home or even how you might do a remote study, which is just starting to become possible with some of the new developments. It’s pretty exciting what’s going on these days.

Read the article: Conducting Usability Research for Mobile.

How do you conduct mobile usability testing? Tell us about it below.

Accessibility is important, but somewhere along the way it got an undeserved reputation for being ugly, costly, and driven only by technical-compliance requirements. Making it an integral part of your design early creates something that is beautiful, inexpensive, and user-experience-driven. When someone with a disability comes across usability issues in your design, they’re likely to be amplified. Something of minor inconvenience for a user could be a significant roadblock to another using assistive technology.

Derek Featherstone of Simply Accessible believes that implementing accessibility into your designs will flatout make for better design. In his virtual seminar, Accessibility as a Design Tool, Derek shares examples of ways to improve the overall design process by ensuring accessibility is taken into account at a variety of phases.

During the live seminar, the audience asked a lot of great questions. Derek joins Adam Churchill to discuss some of those questions in this podcast.

• How can you implement this idea into an existing process?
• How do accessibility and responsive web design fit together?
• What are examples of functional needs to incorporate into personas?
• What is a good way to find people with disabilities to work with early in the process?
• How do you get QA involved in this process?
• How should you address the issue of low vision?
• How can you get buy-in to bring accessibility into the process earlier?

Recorded: February, 2013
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone, welcome to another edition of the SpoolCast.

Recently, Derek Featherstone presented a virtual seminar called Accessibility as a Design Tool. Now, this seminar, along with 100 others that teach the tools and techniques you need to create great design is part of the UIE user experience training library.

In the seminar, Derek showed us how beautiful, inexpensive and delightful user experience driven accessibility can be when it’s actually addressed early.

Hey, Derek, thanks for coming back to talk more about accessibility.

Derek Featherstone: Hey, Adam, thanks for having me.

Adam: For those that weren’t with us today at the seminar, can you tell us a bit about what you talked about?

Derek: Sure. The whole premise behind the virtual seminar is that we want to use accessibility as a design tool. It’s not just something that we need to comply with. Certainly, there is a level of compliance that’s required for many organizations in terms of accessibility.

But we wanted to take a look at it as an opportunity to make it something more than just that and turn it into something where it’s actually an integral part of the design process.

Part of the reason for this is that we worked on quite a few projects where we’ve been called in to do accessibility work and to do usability work. The two are so very similar. In a lot of ways, when we talk about our accessibility work, we talk about it as straight up user experience work, but with very specific populations of people.

One of the things that we’ve found over time in working on these projects is that we quite often find that the usability problems that people without disabilities encounter are very much the same as the usability problems that people with disabilities encounter. It’s just that people with disabilities, those problems have a much more significant impact on people with disabilities, almost like the disability acts as an amplifier for usability issues.

Something that is a usability problem that might take yourself or myself two seconds to recover from a little problem, that actually might be a show stopper for somebody with a disability, just because of the way the interface is designed or coded.

One of the things that we found through all of that work is that there are a lot of scenarios where we really want to focus on accessibility as creating really wonderful user experiences for people that happen to have disabilities.

What we’ve started to do in a lot of the training that I’ve done is I’m showing examples of fixes and new designs that better take into account accessibility. I’ve had lots of designers say to me, “That’s great that you’ve made that change for accessibility, but it looks to me like that’s just a better design, period.”

When that happened once or twice, it was a coincidence. But when it started to happen on almost every single training workshop that I was doing, when there was somebody saying that almost every time, I knew that there was something more to this. That if we use accessibility as a design tool to help make our designs better, they’re actually going to, in many ways, make the design better for everyone.

In the virtual seminar, we talked about that premise and went through a number of different examples and ways to improve the overall design process by making sure that accessibility was taken into account at a lot of different phases, whether we’re talking right at the initial project conception stage and project definition, right through to user research and design iteration, and then development and implementation.

Even post-launch, how do we integrate people with disabilities into all those different phases of a design process to make sure that their needs are represented, but also to make sure that the design can be improved for everyone?

Adam: The gist of the seminar is, let’s think about accessibility earlier in the process. What thoughts or tips would you offer up to a design team that buys into this idea, but they’ve got this existing process?

Derek: You know, there are a few key areas that we tend to look at. When we’re working on a project with an existing team and they’ve got a specific project plan, or a process that they use, what we try to do is look at projecting specific phases of work that we normally do and project that onto their process.

Usually, a process starts something like, as I mentioned already, the initial project conception or the definition phase. What we try to often do at that point is we make sure that we try to engage people with disabilities right then. Because what we want to do, as much as possible, is make sure that we take into account any of their existing content needs, or things that they need that may be different than people without disabilities.

I love Indi Young’s mental model, her approach to this in terms of finding out how people think about problems. I really find that to be a useful tool. Going through that mental model creation process with people with disabilities actually helps us determine what kind of content they need.

As an example, we find that somebody might be creating a mental model about how people decide what movie they’re going to go and see. There are decision making factors that come into that process for somebody that has a disability that people without disabilities just don’t even take into account.

A person with a disability would need to know if, for example, there was captioning available in that particular movie that they wanted to see. They need to know whether or not they can easily get there through public transit and not just the regular public transit, but somebody in a wheelchair.

They may have, I know certainly here in Ottawa, we’ve got a dedicated service called ParaTrans, which is like the equivalent of public transport but for people with disabilities. The ParaTranspo folks, there’s an entire dependency on that system there for a person with a disability, physical disability, to actually go to the movies in the first place.

There are all these other decision-making factors that come in to it. And those types of things are really important to get out on the table right up front so that we not only know that we are creating an accessible design and an accessible implementation of that design, but that we’ve taken into account their content needs so that it actually takes their goals and objectives into account and that we haven’t created something that’s perfectly accessible but doesn’t do anything to meet their actual needs.

We usually start at that phase, and we try to make sure that we include people with disabilities in any user research that we’re doing, include people in the design iteration phase. We want to test colors and concepts. Particularly in the design phase testing iconography is really useful to do at a design phase. You can test that with paper prototypes and wireframes and things like that. You don’t to need to have a fully coded interface.

And then, of course, one of the things that we always try to encourage is people do actual facilitated user testing with people with disabilities after you’ve gotten to a stage where things have been built to a certain extent. We don’t want to test with people too early because it’s just not necessarily productive. We don’t want to leave it too late so that we can actually catch things during iteration.

So there’s a few key points where we tend to look at things and that’s sort of the project conception phase, during the user research and the design phase, and then during and after the development and implementation phases.

Adam: Now you told me before we started the recording here that you’ve actually been doing lots of research on how accessibility and responsive web design fit together. What can you share there?

Derek: It’s really interesting. You know, there are a lot of people that are talking about the relationship between these two, and that responsive design is accessible design, and that accessibility and responsive are really two peas in a pod. And I think there’s a certain amount of truth to that.

Philosophically they kind of have that same core idea in that we have this digital medium, and we want to insure that what we create is as flexible as it possibly can be to fit the environment in which it’s being used. And that’s one of the kind of fundamental pieces of responsive design is that we’ve got this inherent flexibility in the medium, and that’s been something that accessibility advocates have been talking about for quite some time.

And so this whole idea of creating responsive designs that are more flexible and fit the containers and the devices that they’re being displayed on that’s actually a really powerful concept, and that flexibility is something that we’ve always been striving for in accessibility. So philosophically they’re very much the same.

We’re finding now, though, in actually going through — now that we’re seeing a lot of mainstream sites that are becoming responsive, and we’re seeing clients that are coming to us saying, “We want to engage you in terms of accessibility, but how does that have any impact on what we’re doing from a responsive perspective?” we’re actually getting people that are actually implementing responsive designs.

And we’re seeing some really interesting artifacts of that in that the testing — this literally happened yesterday — where a technique was being used to make this design work was actually causing something to break. And we’re probably going to probably publish a test case on this, but ultimately it meant that one of the changes in display in moving from landscape to portrait mode caused an element’s display to change on the screen.

This is difficult without actually showing you the example, but the display of a particular component on the page displayed differently when it was in portrait versus landscape mode, and that caused a change in interaction to be required, and it meant that when we were testing that particular component — it was a navigational menu — where the interaction for that menu changed, the source order for that menu needed to change in order to accommodate the different interaction and the different visual display, but the source order didn’t change.

And what it meant was that the navigation no longer worked when we were in portrait mode. In landscape mode it was fine, but now when we switched to portrait mode the navigational component just completely stopped working properly simply by changing the orientation of the device.

And that kind of thing was really kind of an eye opener for us. You would think that the source order is the source order, but in that particular case the interaction, because the visual design changed and the interaction design changed, we actually needed to make a change to the source order in order to appropriately accommodate somebody that was working with assistive technology.

Adam: In the early part of the seminar you talked about functional needs in personas and other design artifacts. Can you give our audience some examples of that?

Derek: Yeah. I think we tend to avoid creating personas that are about somebody that’s blind or about somebody that is deaf or that is hard of hearing. We try to focus, for example, on the functional side of it and the functional side of somebody that happens to be blind and is using a screen reader.

One of the most significant functional needs that they have is full keyboard access. So quite often we build those kinds of things into a persona rather than saying this happens to be a person that is blind, or creating the entire persona about this person that happens to be blind.

What we try to do is build the persona the way that we would otherwise, and then add on those functional needs and say — we might not talk about James who is blind. We might talk about James, the admin assistant for such-and-such person. Or we might talk about — I don’t know why this name came to mind — Adam. We might talk about Adam who is producing a podcast for somebody, but he actually is blind and needs to have full keyboard access to the recording software.

So we would do things like that rather than it being about Adam the blind person. It’s about Adam the podcast producer who has a functional need that happens to include full keyboard accessibility.

And one of the reasons that we do that quite often is that we want people to realize that just because somebody happens to be blind or hard of hearing or has difficulty using a mouse and uses voice recognition software, their functional needs are essentially the same, because they’re trying to accomplish the same goals with a piece of software or a website as everybody else is. They just have a different set of tools to do that.

So we want people, when we’re talking about accessibility, to realize and to understand that really what we’re talking about is not somebody having the goal of using their screen reader, but the goal is to accomplish a particular task and they just happen to be using a screen reader to do it or some other piece of assistive technology or something that requires a particular functional need, like full keyboard usage.

Adam: Talk a bit about finding people with disabilities that you can work with early in the process.

Derek: Sure. That’s something that comes up quite often when we’re talking with clients or even when I’m giving talks at conferences. People will ask exactly that question. Where do I find people because I don’t even know where to start?

One of the places that we always suggest people look is at the local college or university that happens to be in the city or town nearby, because almost every single one of them — in fact, I would say every one of them — has some type of an office or center for students with disabilities and there’s an incredible number of people that are already connected there, people that are maybe assistive technology specialists or combination specialists that work at these colleges and universities and they are already working with people with disabilities every day and they can be a great source of folks that have disabilities, partly because they already know them all, but partly because one of their mandates is usually to help provide people with disabilities with employment type opportunities.

So that’s something that I think is really kind of a critical piece is getting people with disabilities from either the local college or local university or even if you’re not comfortable going to those places, local advocacy groups. There are usually chapters for different disability groups.

I know here in Canada we have the CNIB which is our national organization that takes on advocacy issues for people that are blind or have low vision. There are local chapters in major cities around the country and similar organizations exist in all countries around the world for people with disabilities, or certainly in many countries anyway.

So those are two great sources for working with people with disabilities right from the beginning of a project.

Adam: What about quality assurance? How do we get them involved in the process?

Derek: So I think it’s really important to validate all the things that we’ve done when it comes to accessibility remediation and testing. And it’s one thing for accessibility people that are really familiar with accessibility and how people with disabilities use the web. It’s one thing for them to be checking on things, but it’s a whole other level for people that actually use the software and have specific disability needs or specific accessibility needs to use things like they’re actually going to try and complete a task, like they’re really trying to use the site and we’re not just talking about straightforward walkthroughs, can I complete this task in a quality assurance type manner.

So what we want to do is involve certainly QA teams, but also involve people with disabilities in that QA process where they’re actually walking through and doing this in literally just like a usability study that you would do, just doing the same type of things where we’re asking people with disabilities to do walkthroughs and engaging them in testing specific processes and flows within applications or sites.

That’s really the test. We can make sure that everything is technically accessible, but what we really, really want to do is make sure that it’s not just technically accessible, but it’s also really easy to use and those nuances and those little tiny usability nuggets that you’ll pick up in doing real testing with real people that actually have disabilities and are not just doing things from a QA perspective, those nuggets are incredible because they take your interface from being something that allows people to accomplish tasks to being something that is actually more pleasurable to use and actually makes it so that the interface is actually something that’s enjoyable and really easy to use and very efficient and streamlined.

Adam: Let’s talk about one of those specific accessibility needs. Talk a bit about how people with low vision use their computers. That seemed to come up a lot in the questions that folks were asking during the seminar.

Derek: Yeah. It’s interesting, because the beautiful thing about accessibility is that there is no black and white. Everything is a shade of gray to some extent. There’s no accessible or not accessible, and when we’re talking about people with low vision, there’s such a huge variety in terms of what degree of low vision people have, their needs range so much that it’s really kind of difficult to pin down exactly what a person with low vision is going to do with their computer.

Some people that have moderate low vision where it doesn’t affect their visual acuity that much, they might be able to get away with just changing some operating system level settings where they make everything a little bit bigger. So we’ve seen, for example, somebody on a 27-inch monitor that is running at 800×600 resolution on that 27-inch monitor. They don’t need to use magnification software. They’re just changing something within the operating system so that they can see things a little bit better and they don’t need a lot of accommodation other than that.

For other people, it’s not about size. It actually ends up being about color scheme. They need to, quite often, change the color scheme on their computer. They might drop into high contrast mode, because it’s much easier for them to read white text on a black background than it is to read black text on a white background.

On a case where you’ve got low vision, an entire screen of white, when you’re reading black text on an entire screen of white, what your eyes need to detect is the absence of light. Whereas, when you’re looking at it on a black screen with white text, you’re detecting the presence of light, versus the absence. So, your eyes are not drenched with the full screen of white, they’re only being presented with the white letters.

That is a significant difference for some people in that they need that alternative color scheme. It’s not so much about the size, but it’s about the colors that are being used to present information.

Some people will have greater degrees of low vision, where it’s profound low vision, and they need different pieces of software. They might actually use a combination of a magnifier, so that they can see the interface and read some of the text. But then they might also use that in combination with reading software, so that when they find the text that they want to read, maybe they’re looking at a newspaper website and they found an article that they wanted to read.

Well, what they can do, then, is find the text that they want to read by using their vision in a magnifying scenario. Then they can give their eyes a rest, highlight the text that they want to read, like the entire article, and they can tell their software to read it to them. They might use a combination of magnification and reading functionality so that they can use their eyes to find the thing that they’re looking for, orient themselves, and then once they’ve found it, use reading software in order to give their eyes a rest.

There’s a lot of variety in the way that people with low vision use the web and use their computers. I think that’s one of the things that I love about the low vision problem. Many people in the accessibility field are really familiar with, and even web developer that aren’t accessibility specialists have a decent sense of what it might be like to use a screen reader and what it means to develop an accessible application or site for somebody that uses a screen reader.

But low vision is a completely different problem. I find that the low vision issue is actually really kind of exciting and intriguing, because it’s so very different than screen reader usage, in many ways.

Adam: People have bought in, right? Either it’s because there’s this fundamental, I get that accessibility is super important. Or they’ve heard you talk and understand that by focusing on accessibility earlier, you can actually create a better design, a more delightful design. How do they get buy-in with their organization, other stakeholders, a client? How do you pitch that process happening earlier?

Derek: That’s an interesting one and something that we’ve started to see with many of the projects that we work on. One of the things that we’ve found that works reasonably well, and I’m not going to say that this works every time all the time, but one of the things that we do in as many cases as possible is we use accessibility to help solve other people’s problems.

What I mean by that is, one of the things that is required for accessibility is a standard approach to design patterns and to development patterns. One of the things that accessibility can do is it helps bring about standardization and using standard methodologies and standard ways of solving particular problems.

I’m talking about interface widgets. Let’s say we want to use a dialogue box in a web based interface. Well, we can use accessibility to say, here’s an accessible way to do it.

Once that method, that widget has been approved from an accessibility perspective, that is now something that reduces development time because it means that that approved widget is also something that can be put into a repository that anybody can use.

That means that the next time you need to create a dialogue box widget, we don’t go back and reinvent the wheel. We actually go to the, for lack of a better term, accessibility approved widget that has already been vetted, that has already been tested, and we can take that and build it right into the environment.

When we do things like that, we start to help the overall process of web design and development happen in the first place. That’s really the kinds of things that we mean when we’re talking about using accessibility to help solve somebody else’s problem. Because the last thing that any manager wants is to have 30 different variations of a dialogue box scattered throughout the application, because that just makes it a maintenance nightmare for everyone.

If we can bring some of that standardization into things and use that as part of process and development strategy, then that can really help make the case for accessibility, both on a management level, but even higher up and getting people to buy in. Because, not only is the accessibility the right thing to do, but it also helps reduce costs, helps ease maintenance and helps the organization get things done quicker.

That’s one of the examples, anyway, where you can certainly use accessibility and leverage it to get some buy-in from levels higher up.

Adam: Well, that’s awesome. Derek, thanks for joining us again today.

Derek: Oh, absolutely. Thanks for having me, and we’ll definitely talk again.

Adam: To our audience, thanks for joining us, and for your support of the Virtual Seminar program. Goodbye for now.

Here’s an excerpt from the article

Voice and tone. Tone and voice. Though the words “voice” and “tone” are often used interchangeably, they’re not synonyms. Our voice makes us unique, and our tone makes us sound like humans. Establishing a likable voice is critical for brands, but there’s more to it. Companies that acknowledge the distinction—maintaining a consistent voice and paying careful attention to their tone—publish more meaningful web content and build better relationships with their users.

All too often, empathy is absent from web content. That’s why every company needs voice and tone standards—they help us understand our customers and show them respect.

Read the article: Tone and Voice: Showing Your Users That You Care.

Learn more from Kate Kiefer Lee on voice and tone

We’re lucky to have Kate give a UIE Virtual Seminar March 7 on Voice and Tone: Creating Content for Humans. Kate will show you how to establish voice guidelines that inspire your writers’ creativity. She’ll share real-life examples of empathetic writing and talk about the importance of establishing content standards that make corporate writing fun.

How do you decide what tone is appropriate for different content? Tell us about it below.

• Learn how to incorporate Agile methods while still fitting user-focused activities
  into your projects.
• Design for mobile based on how people think and what emergent themes to keep an eye
  on in the future.
• Interweave Agile and scrum methods and tactics with traditional design practices.
• Focus on connectivity, productivity, and moving critical tasks from the desktop to a
  mobile device.
• Hear what today’s UX designers need in a mobile environment to deliver excellent,
  world-changing designs.
• Explore past ideas of best processes and techniques while integrating Agile methods.
• Explore past ideas of best processes and techniques while integrating Agile methods.

These UX experts will amp up your mobile design and Agile skills: Luke Wroblewski, Jeff Gothelf, Rachel Hinman, Dave McFarland, James Robertson, Hugh Beyer, Daniel Burka, Andrei Herasimchuk, and Jared Spool.

You’ll get all 10 hours of video and audio recordings, all the presentation decks, and the conference materials from last year’s conference. All for free with no catches.

How to get the free recordings?

It’s easy. Just submit your email by Friday, February 22, 11:59 PM ET and you’ll get last year’s UX Immersion talks and materials for free. No tricks, no quantity limits. We’ll send you an email with details on how to access this bundle of goodness.

Now hurry and act fast to get last year’s UXIM OnDemand and be sure to spread the word. The clock is ticking.

As more web capable devices hit the market, designers need to consider where and how their designs will be seen. Unfortunately, the same consideration isn’t always made when it comes to content. With design changing so much in a multichannel environment, content must be structured independent of how it will eventually look.

Content touches all aspects of a design. Having presentation independent content allows for it to adapt to different screens and devices. Karen McGrane suggests that having the specifics of how the content will be structured in place first, allows for the freedom and flexibility to make the right design choices.

Karen says that the advent of WYSIWYG editors shifted focus to the wrong things at the wrong time. Content took a backseat to the overall look of the design. Thinking about content first, over how it will appear, helps ensure you’re communicating the right message.

Karen is presenting one of the daylong workshops at the UX Immersion Mobile conference April 22-24 in Seattle. For more information about Karen’s and the other workshops, visit uxim.co.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everyone. Welcome to yet one more episode of the SpoolCast, the little podcast we do to bring up your UX goodness. Today we’re going to bring it up quite a bit, because I’ve got with me here the wonderful, amazing Karen McGrane, one of my favoritest people on the planet.

I don’t know if you know this, but Karen is speaking at our upcoming UX Immersion Conference, which is going to be in Seattle April 22 through 24. It’s all about mobile this year. She’s going to be talking on content strategy for mobile, which, by an amazing coincidence, is the exact title of her brand-new book from A Book Apart, “Content Strategy for Mobile.” Today we’re going to talk to Karen about, surprise, content strategy for mobile.

Hey, Karen.

Karen McGrane: Hi. Good morning.

Jared: Good morning. This book is almost perfect. The one un-perfect thing is that you were suffering for quotes so you added one of mine to the very end of the back of the book. But beyond that, it is really quite a great book. It never occurred to me that content strategy would be different for mobile. When did it first occur to you that this was more than just a blog post?

Karen: Well, I had been giving a talk last year called “Adapting Ourselves to Adaptive Content.”

Jared: Yeah, I’ve seen it. It’s awesome.

Karen: I will confess, when I wrote that talk, I thought it was going to be sort of an obscure topic. Structured content for multichannel publishing seemed like, “Wow, this is a bit esoteric.” Honestly, for my 15 years of being a user-experience professional, I was really surprised at the positive reception that I got to that talk.

Most important, I got a very positive reception from Jeffrey Zeldman, who, every time I gave that talk at An Event Apart, he would come up to me after I got off stage and say, “You have to write this book.” The first couple of times he said that, I was like, “Eh… Writing a book sounds hard! I don’t want to write a book! Can’t I just write a blog post?”

Jared: Exactly.

Karen: Right?

Jared: I know. [laughs]

Karen: Then, after the third time he asked me, a light bulb went on over my head that was like, “I would be an idiot not to write this book.”

That’s how I wound up taking a good six months of my life and writing what…

When I was writing it, I tried to imagine myself writing many blog posts rather than…

It’s intimidating to say, “OK, today I’m going to wake up and write a book.” But it wasn’t as intimidating to wake up and think, “No, I’m going to write a blog post on a topic that’s interesting to me, and then eventually I will add in all the connective tissue that will make it a book.”

Jared: What strikes me about this book is that it really does talk to this area that is really sort of new. Mobile has really only sprouted out in the last few years, since the iPhone made going to websites fashionable.

The idea that companies do something that isn’t just “Create a special mobile website that has special mobile content” or “Let’s just take things and put everything in PDF form,” to actually say, “OK, we have to think about how we do this and structure and model and come up with a whole strategy around how we produce things that work on every platform.

That, to me, it feels very nascent, it feels like everybody’s sort of in the Wild West of that right now. Do you think it’s settling down, or does it feel that way to you?

Karen: No, it feels like total Wild West. I keep describing it as, it reminds me of what it was like working on the web back in 1997 when everything was new and chaotic. People didn’t have the right tools, they didn’t have the right decision making frameworks. Everything you wanted to do seemed complicated and challenging.

And I love it. It’s a great opportunity to kind of go back to first principles in a way and fix some of the things that we’ve been doing wrong over the last 10 or 15 years. Many organizations that I talk to are really struggling with the problem of, how to we get our web content or our content in general, how do we get that onto mobile devices?

Many of them have figured out, “Oh right, we need to offer some simple transactional functionality.” Like I’m working with a lot of banks right now, and banking, for five years, since the iPhone came out, they recognized the importance of offering current customers the ability to do some transactions online. Whatever online banking functionality they had, they built mobile apps that can do that.

But what they haven’t figured out is, what are they going to do about all of their content? What are they going to do about all of the stuff that they’re publishing on their public facing website? When you look at the data about mobile users, who’s on mobile, how frequently people engage on mobile, what they’re doing on mobile .

You realize, “This isn’t some abstract, theoretical thing.” Like, “Oh wow, maybe we should think about getting our content on mobile. Customers are there. They’re there right now. Now is the time to do something about it.”

Jared: We were just looking at our site statistics and we’re blown away that almost a third of our site visitors are on mobile, according to Google analytics. That’s just crazy.

Karen: It is. I have seen data from lots of organizations that show 10, 20, 30 percent of their traffic is coming in from mobile devices. Really shocking numbers about painful experiences that people are willing to go through using a site that’s formatted for the desktop on their mobile device. We’re failing people.

That fact that for many of us who are expert web users, the fact that we manage to suffer through having to pinch and zoom our way through a site that’s designed for a much bigger screen, that doesn’t make it OK. It doesn’t make it what we should settle for.

One of the things that I’ve seen is that when organizations decide to invest in building a true mobile site they’re really surprised by how much those numbers go up. So if you’re seeing 10 or 20 percent of your traffic coming on mobile devices to a desktop optimized site that number will probably double when you build a mobile site.

Jared: Yeah, and I just saw a tweet from one of the developers at NPR saying that just a few months ago they didn’t have a single responsive page on their site. Now they have half a million responsive pages. I got to think that’s because of their content strategy, that they happen to fall into this content strategy. That lets them take that content and put it out in that new form, and with a small team and a budget that’s paid for by “Pledge Week.”

Karen: By viewers like you.

Jared: Yeah, [laughs] viewers like me, or listeners, I guess. And don’t forget Charles D. and Catherine T. MacArthur, or as we call them in the house, “Chuck and Katie.”

Karen: [laughs]

Jared: …that somehow they were able to get all that content pretty much easily poured into those responsive frames pretty quickly. I’ve seen you talk about the NPR strategy, and it seems nothing short of just brilliant.

Karen: It’s everybody’s favorite case study. People like talking about it because it is such a simple, straightforward, easily understandable example of what it means to truly separate content from form, what it means to truly break away from the idea that our content is going to live in a particular place that the content strategy and the content structure should be determined by what the site looks like.

To finally say, “Oh, right, we can’t do that anymore.” Mobile is going to be the final nail in that coffin to say instead, “We’re going to have to think about content and how it’s structured as being independent from how it’s going to look or independent from the particular platform or device it’s going to live on.”

NPR started working on this strategy five years ago, frankly before most of the devices that their content can now live on even existed. And the investment that they made in developing structured presentation independent content has really paid off for them.

What it means is that now when they decide, “Oh, what we should do is we should start building responsive templates,” they can do that much more quickly. Because they don’t have to go back in and try to figure out how to strip their content out of designs or templates where the content is all mixed up with the formatting, and so having done that they can focus on making great decisions about how the new responsive site should be designed.

They can focus on making the right interaction design decisions, the right aesthetic decisions for that platform or for that channel because they’re not having to go back in and figure out, “Oh, wait, what do we want to do with our content?” They’ve already made those decisions.

Jared: Yeah, it just feels to me like they were the ones who have demonstrated to the world the loudest about the value of making that upfront investment, because making a good content strategy, that’s not an inexpensive investment. You’ve got to have commitment there to do it.

Karen: Yeah. It’s something that you have to make choices that you then have to live with, or you have to say, “OK, great. This is how our content is going to be structured. We’re going to have these content elements, and we’re not going to have those content elements.”

It means that then when your designers go to work on your new responsive templates they don’t always get to do exactly what they want. They don’t get to say, “Oh, you know what I would like is this 300 by 250 image size will fit perfectly here.” It’s like, “You don’t have a 300 by 250 image size. You are going to use that 300 by 200 and make it work.”

Same thing. I use NPR as a best practice example all the time, but they actually only cut one headline, and so if you go to their iPhone application they actually wind up doing something I tell organizations not to do all the time. I joke about it, which is they truncate their headlines.

You go in, and they run out of space, and they drop in an ellipsis. You look at that and you’re like, “No, NPR, No!” But the truth is, they made a decision a while back, that they were only going to cut one form of that headline. That’s what they had to work with.

Jared: So, it really is a “pay now or pay later” deal.

Karen: Right. And if you pay now, it’s much cheaper. It is expensive to set up a content strategy, and it is. But better to do the planning and make some decisions now, than it is to constantly be going back and having to strip things out for previous platforms. Do the work over again every time you want to get your content onto a new platform.

Jared: So, it does seem to me though, that teams that manage to get into their budget a time machine, and can go into the future and see how the content is going to be used, are going to have a much easier job than teams that have to wing it.

Karen: Yes. Time machine is an important part of all of my content strategy recommendations.

Jared: What do you recommend to those folks who just don’t have the budget for the time machine?

Karen: Unfortunately, as with everything on the Web or in the digital space, you have to sometimes make good decisions based on the available information you have now. You can’t predict the future, but you can at least try to look across the range of different uses and make some good decisions about a system. I actually like to talk about image crops as an example of how this works.

Jared: OK, yeah, help me with that.

Karen: So, having worked on sites for many large publishers, you realize, like, “Oh. If you let your designer go in and specify the exact right image size that would fit perfectly in every single design, you would wind up with a million different image sizes.” They’d all be slightly different, and publishers run into this problem and they will eventually go in and say, “No.”

We are not doing that. We are going to cut a handful of different image sizes, maybe five or six, and those are the sizes you’re going to have to work with. And you will choose one of those sizes, it may not fit perfectly. But it’s going to be close enough, and so that’s what you’re going to use.

There’s no way to necessarily anticipate what the exact right size should be, but if you think of it in the system, and you look across the range of possible places that those images might be used, you can get pretty close. You’re not going to be horribly wrong.

One of the issues that we’re running into is that many publishers today, when they’re going to mobile, actually haven’t anticipated that they would need different-sized images for mobile screens. One of the surprising problems I’ve run into, is that they actually don’t have large enough images.

Everybody thinks that mobile images always have to be smaller. But with retina displays, often times what we run into is that the largest image size isn’t large enough to be used to fill the whole screen on a retina iPhone. That’s one of those examples where it’s like OK, well what are we going to do.

We’re either going to have an image that doesn’t fit perfectly or has to be scaled up a little bit so it gets a little crunchy. Or we’re going to have to go back to our production team and say, now we need you to cut another image size. So those are decisions that…

It’s like you could make those in the long term. The fact that that might happen, the fact that you might realize at some point in the future that you don’t have all the content elements or all the image sizes that you want, isn’t a good reason to not do your best of analyzing what the system should be and coming up with some reasonable defaults now.

Jared: So what that means, is, looking hard at what could happen. But it also feels to me like you can do some research and see how are other people moving forward and collecting up the different types of images, or the different types of headlines, or the different lengths of content, and start making a little museum-like collection of inspiration for how other people are doing it.

Saying “Wow, I really like the way they handled this problem. I really like the way these other guys do headlines.” Start figuring it out. The NPR choice to go with a single headline versus having a short version and a long version. Was that an explicit choice of, it’s too hard for our headline writers to come up with this, or was it more the case of it didn’t occur to them until it was too late, and they had too much to go back and change.

Karen: That one, I don’t know the answer to. But I would anticipate that they do cut different sizes of teasers, so perhaps they thought, you know what, we’re just going to go with one canonical headline to make things easier on our writers, or make things easier on our production staff.

I might say maybe the mistake there wasn’t deciding to go with one headline, but rather deciding on a visual design for the app that didn’t allocate enough space for what was, frankly, a known character count.

Jared: Good point. This could be easier to fix because it’s not a matter of going through a million data entries in the CMS and re-editing, as much as re-visiting the visual design choices and saying, “Let’s be a little smarter about this.” You could even do something where the text is variable height, variable font size, based on the actual length that it exists in, right?

Karen: If I were a visual designer, and frankly the world should be grateful that I am not. I would be pretty happy to know the exact characteristics of the content that I had to work with before I started designing. It would make my job easier to say, “Great, I have these pieces to work with.” I have these images of these dimensions, what can I do with this palette, this library of different content elements.

I am very sympathetic to designers who are frustrated by not knowing what the content is going to be, or trying to get clients to be more specific about what content choices they’ve made, or how that content will be structured.

This approach to defining what the reusable content store of structured content will be, actually should make design better. It should make the designer’s job easier. Designers should be advocating for this as much as content strategists do.

Jared: Yeah. This whole idea about having a strategy around content, it touches everything. Right? It touches the interaction design. It touches the visual design. It probably can bleed into the user research when you go out and find out that things like ellipsis at the end of titles as a truncation is not as effective.

In our work, we have found when we’re naming our virtual seminars, we have found through usability testing that having clever plays on words don’t actually work as well as having something that has the right topic in the headline itself.

Knowing what the topic should be and having that there, that all plays into the way we create the content strategy and the way we create the CMS and the way we train people to fill out the CMS and put it in there.

It feels to me like this is not some sort of separate thing that you go off and you hire special people and they go into their special content strategy secret cave and go off and do their thing. Everything gets touched by this.

Karen: It’s true. It involves everything from how the design is going to work to how the CMS is going to be built to what the roles and responsibilities of the team will be. I think it’s extremely powerful to acknowledge that, “Hey, instead of figuring out what it’s going to look like first, what if we figured out what the content’s going to be and how it’s going to be structured?”

That’s going to give us, paradoxically, more freedom and more flexibility to make the right design choices for whatever platform we’re thinking about, because we’ve put this work in up front.

Too often, we assume that the content structure will be defined by what the design should be. You realize too late that that doesn’t work for your team, it doesn’t work in your CMS, it doesn’t actually work in the design and it provides a bad user experience.

Jared: Yeah, and you get those horrible words, “I’m sorry, but we can’t do that.”

Karen: I hate, “Oh, we’re not going to do that.” Honestly, I feel like I’m talking to a lot of organizations right now that are saying, we recognize we’ve been doing this the wrong way on the desktop. We recognize that we’ve been going desktop first and design first and when we start talking about mobile, we want to do it content first.

Jared: When you were putting the book together, was there anything in your research for the book that you sort of came upon, you go, oh my goodness, I just struck gold. Right? I mean, it’s just that sort of surprising moment where it was, before you started doing the research, you didn’t know about this, and then suddenly, this thing walks up and it just changed the way you were approaching things. Did you run into that?

Karen: One of the topics that really, I had a big inspiration around, it was a huge aha moment, was the idea that tools like WYSIWYG, you know, the what you see is what you get formatting bar, or the preview button, really privilege the desktop interface and privilege the design, it really encouraged people to imagine their content in one context.

Jared: Oh. yeah.

Karen: That is, frankly, limiting and dangerous, as you start thinking about, well, what happens to all of that formatting? What happens to all of that styling we’re imagining when we have to take this content to a new platform?

I’ve actually been working on a post right now about a new innovation we’ve come up with that causes very similar problems, which is in-line editing. The idea that the content owner can look at the front end user experience. But have editing tools that are kind of built right into that experience, and click on a box on the screen and go in and go into edit mode right from that spot.

There are powerful reasons why sometimes that is compelling. It’s the use case of, “Oh, I saw a typo and I want to go in and fix that really quickly.”

But the downside is that you’re encouraging your content owner to imagine that there’s nothing to the content other than what the user sees. You take them away from all of the metadata and all of the back end content structure that, frankly, in my mind is way more important. Particularly as you’re thinking about the idea that now this content’s going to live in lots of different places.

I think we’re going to see some interesting years, interesting developments in the CMS space, where one path is going to take us more toward a tighter connection between design and content. The path that I’m on is going to say, “Hey, content creators need to break away from imagining how things look and focus much more on what things are and what they mean.”

Jared: This is really interesting. I was actually just thinking about this morning, because I was reminded about what it was like to edit a document in the ’60s and ’70s. We don’t talk about this ever. But at the time, the storage devices were not random access. You had tape. You had to fast forward to a place in the tape, and if you were going to edit something, you had to do in place in the tape.

You had all these commands that would let you move forward and backwards and deal with the content serially. You would work on things a line at a time and you would actually store it temporarily in memory because memory was very expensive. You would store something in memory and you would edit it in memory.

Then you would save it out and it would have to rewrite the piece of the medium that it was doing, but it couldn’t collide with something that came after it or before it. It was really tricky. You had these very arcane things. There was a program called Teco, T-E-C-O, which was a tape editing program that I grew up with in the ’70s.

You could do amazing things with it. WYSIWYG, being able to see what you are editing, that didn’t come for another 20 years. It was miraculous when it showed up. Now, we take it for granted. It’s like listening to your grandpa talking about listening to radio shows and saying, “Oh my gosh, they were so much vivid when they were on the radio than they are when you see them on the TV.” There’s something to that, right?

There’s this idea that, by having such high fidelity of the result on the screen, you focus on the wrong things. You don’t ask the question in the case of content, well, what will this look like when it’s displayed someplace else? What will this sound like when it’s in a screen reader? What could this look like in a different form factor? We get stuck.

Karen: Exactly. We get so focused on imagining what something’s going to look like that we forget that our real job is to make sure that we communicate the right meaning, the right messages and that the content is structured appropriately.

I’m often reminded of the advent of WYSIWYG, meaning that now you have highly paid executives sitting around, dicking around with the font and the margins on their business letters. That’s not really a good use of your time. Or more to the point, your focusing on styling of your communication is actually taking you away from what you should really be focused on, which is, what are you trying to say?

Jared: Well, it’s interesting. I remember, because I worked on some of the first word processors. I remember that, at the time that those first word processors were coming out, some Japanese executive. It was the CEO of Sony or somebody was deriding American executives for having all these personal computers and now doing their own word processing. Saying that, you are taking powerful executives and turning them into secretaries.

It seemed like an obnoxious statement at the time, but there was this hidden truth underneath it. Which is, we are changing the focus from the message to the medium. Maybe that shift, that pendulum swing was a little too far.

Karen: Agreed. You see that on the web all the time, that we are trying to make the web make sense to us by telling people that it works just like Microsoft Word. Asking them to imagine that their control over the experience and their control of what something’s going to look like and how it’s going to work will be as stable and as fixed as them printing out their document on the laser printer that sits next to their desk.

The Web doesn’t work that way. The web’s never worked that way. But we’ve allowed people to imagine that it does.

Jared: Yeah, Word doesn’t even work that way.

Karen: Exactly.

Jared: Wow. This has been great. I am really excited for the workshop, because you’re going to help us really understand how to take this problem apart. Break it down to pieces and deal with the fact that we can’t get management to buy us that time machine. Instead, have to come up with more present day strategies for figuring out what our future content is going to need to be.

That’s really exciting. I wish in our conference, we could have required workshops, because I think I would make yours required for everybody.

Karen: Well, you run the conference. You could totally make them take my workshop in order to get course credit.

Jared: Ooh. I could do that. That’d be awesome. Maybe they’d have to take the workshop just to be able to get a drink ticket.

Karen: Ooh. I’d do that.

[laughter]

Jared: Hey, Karen, thank you so much for taking time to talk with me today. This has been awesome as always.

Karen: Thank you for taking time. I enjoy our conversations very much.

Jared: Excellent. I want to thank our audience for taking the time to listen to Karen and me talk about this topic today. I think this is a really exciting topic. I’m hoping you got a lot out of it.

You, of course, can catch Karen at the UX Immersion Mobile Conference which is going to be in Seattle, April 22 to 24. Of course, if you haven’t done so, you need to go right now and buy a copy of Karen’s “Content Strategy for Mobile,” which is from A Book Apart, the fabulous publishers. In fact, you should buy several, because they make great gifts. You will not be disappointed.

Thank you again for listening. Of course, as always, thank you for encouraging our behavior. We will talk to you soon. Take care.

Here’s an excerpt from the article

Imagine being in a foreign city, trying to get across town to catch a train. Not knowing where you are, relative to the train station. Getting to the station and having trouble find your way to the train. Interpreting the schedule to ensure you’re on the right train at the right time. Knowing what your food options are before you get onboard.

What could we do with that hyper connected super computer in our pocket? We could start to design an experience that puts us at ease and helps us navigate the world.

We could start simply, by giving simple direction and time estimates on when you’ll arrive at the train station, whether you take a cab, walk, or other local transportation options. This is easy to do with today’s technology.

On the same screen, we could have the information about the train we hope to catch. If it looks like we may have trouble making it to the station in time, we could give information about other routes to get to our destination city.

Read the article: Context-Aware Design: A New Frontier.

Start mapping your customer’s experience

Are you interested in mapping out the future of your customer’s experience with your applications? Chris Risdon’s full-day workshop at the UX Immersion Mobile Conference in Seattle, April 22 will help you develop the user’s journey. Learn more about Chris’ workshop.

Where do you think the future of context-aware design is headed? Tell us about it below.

The organizational content we’re creating for the web is too often formal, lacking emotion. It’s written for organizations, not people. Writing content for humans is challenging, and doing it while articulating your organization’s personality is even more difficult.

MailChimp is one company that’s successfully established a brand voice—and is still working to keep it. As a result, they’ve become known for their punchy, honest messaging that builds trust with users and makes them smile, too. Kate Kiefer Lee will share real-life examples of empathetic writing and talk about the importance of establishing content standards that make corporate writing fun.

Kate delivered an earlier version of this presentation at a sold out Confab in 2012.

If you want to maintain a consistent tone in your content while putting readers first, then sign up for Kate’s seminar today.

Des Traynor is an expert on crafting microcopy. In his virtual seminar, Microcopy That Strengthens your Design’s Experience, Des identifies the key questions to ask when creating microcopy so that it doesn’t get lost or created by accident. The audience asked a bunch of great questions during the live seminar and Des joins Adam Churchill to answer some questions in this podcast.

• How does globalization come into play when crafting microcopy?
• How should you store and retrieve microcopy for reuse?
• How can you scale your effort when supporting multiple products?
• Are there guidelines to using pronouns in labels?
• What is the value of mouse-over clarification text?
• How can you prevent stakeholders from insisting on copy you know to be problematic?
• Are there principles to writing error messages?
• How can you get a writer involved earlier in the design process?

Recorded: November, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this fall, Des Traynor presented an entertaining but also a very important virtual seminar. It was called “Microcopy that Strengthens your Design’s Experience.” This seminar, along with 100 others that teach the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library.

In this particular seminar, Des showed our audience how to craft clear microcopy that facilitates user interactions without friction. He spoke to the graphical elements on websites or applications that can be improved with plain language or labels. He showed examples of transactional content that further clarifies the user experience without generic marketing fluff. He even shared how you can establish a personality and compel your users to come back for more.

Hey, Des. Thanks for coming back to talk more about microcopy.

Des Traynor: Thanks, Adam. It’s great to be back.

Adam: For those that weren’t with us that day, can you talk about what you covered in the virtual seminar?

Des: Sure. We talked about microcopy as a whole. When we talk about microcopy, I usually mean the small pieces of text that define interactions or relationships in a product or website. What we looked at was the key areas that you should be aware of when you’re writing microcopy, how to write effective microcopy, how to spot it and test it and make sure it tests well.

Some of the topics we zoned in on were the role of microcopy in current popular websites. A great example of this actually came up after the seminar, which was, on Thanksgiving Facebook changed their microcopy inside their “update status” box to no longer say, “What’s on your mind?” which is the normal text, and on that day it said, “What are you thankful for?”

As a result, anyone who logged into Facebook saw a stream of “I’m thankful for XYZ”-type messages, which is just one tiny example of how a super-subtle change redefined Facebook for a day. The knockout effect of that is huge, because it means they can do things like Thanksgiving summary emails. Every single Thanksgiving on your timeline will then be so much more meaningful because it’s punctuated by this compelling content.

That was one of the topics we looked at, which is how popular sites control their microcopy to gather the content that it is that they want.

Then we looked at three types of microcopy that, as a designer, you have to control. We identified the interface microcopy, which is typically the labels used on buttons or for form fields or how you define relationships. For example, do you call someone a “follower” or do you call someone a “friend,” et cetera?

The next type of microcopy we looked at was the blank-slate experience. What happens when you log into a product or website and you have yet to do anything there, so if you have no friends or no projects or no time tracked?

And the last piece we looked at was the content definition itself. It’s often left till the end for a lot of popular, say, review sites or content sites, travel sites, to define what exactly is, say, a review of a hotel. Yet whoever makes that decision actually makes probably the most important decision for the entire Web product. However, it just seems to be oftentimes phoned-in. People will say, “Well, let’s just put a big box here and call it ‘review.’”

And we looked at how, say, things like the Apple App Store suffer badly from the idea that the only way you can review is on a one-to-five-star scale and a text box. Whereas I believe, if they augmented the reviews with things like “Is this product value for money?” or “How often do you use this product?” you’d get a much more meaningful way to search, browse, and validate the products that are there.

The closing piece of the seminar, we zoned in on a framework for writing microcopy and how you can make sure that it doesn’t get lost in the process or doesn’t happen by accident because no one bothered checking the wireframes. I identified the key questions you ask — who are you talking to, what are you saying, what’s the purpose of the message, how is the message displayed, when is it sent, et cetera.

Then, finally, we just talked about how you can apply these principles across all a company’s communications, the key idea being that every product or website has a tone of voice, and whether you like it or not, you establish one. It can be an inconsistent mess of 10 different people writing whatever comes to their mind, or it can be a wonderfully branded experience that is constantly reminding the customer why it is that they love the company or product.

We just looked everything from transactional emails — i.e., typical reset-your-password stuff — all the way through to what happens on day 7 or day 30, what sort of content is sent then. We just talked about how you can capture all of these and make sure that the product benefits from this consistent tone across the board.

And lastly, I think we did a few questions.

Adam: We did, but there were some that we didn’t get to and others that we thought were worth readdressing, so let’s tackle some of those.

There were some really good questions, Des, on some topics that feel like they’re related, but they’re actually very unique and separate challenges — localization, internationalization, translation. And we were talking about how to circle back on this topic. You told me about an acronym called GILT. Can you just say more about that acronym and how those different pieces come into play?

Des: Sure. GILT stands for globalization, internationalization, localization, and translation, and they’re all different principles when you decide to make your product work across more than one locale, if you will.

At the bottom, if you like, of the pyramid, you’ve got translation. Translation is literally what happens when you take a word in one form and change it to be in another language. You literally translate everything you see in English to German. Translation can leave some things behind. For example, something that’s cute and funny in one language, when literally translated, can be neither cute nor funny. And you see that a lot. It happens when you, say, talk to tourists in certain areas, they don’t understand your local sense of humor or whatever.

Translation is at the bottom of the pyramid. Unfortunately, a lot of people, when they’re dealing with microcopy, they feel it’s OK to dump a text file online and say, “I will pay $400 to have all this translated.” The two problems are what they get back is neither appropriate from a contextual/locale point of view — simple stuff like what was funny in English might not be funny in a different language.

Also, it’s bad from an interface point of view as well, because a lot of languages tend to be a lot longer than English, and a lot of languages can be a lot shorter than English, too, depending on the sort of character set used.

What you end up with is a button such as “complete transaction,” when moved into a different language, can actually cause a ridiculously ugly 600-pixel-wide button. That’s where translation falls short.

The next step is localization, which is when you look at what’s appropriate for any given locale that you’re targeting, if you like, any locality. You go through your same content challenge, but you factor in the locale of where it’s addressed. In my framework, we were saying how one of the questions you ask is “who?”

A related question, when you’re applying localization is “who?” and “in what area?” This is when you will readdress, say you might re-frame a welcome message or a cute joke or a funny sort of message on your home page, or your terms and conditions or something strict and legal. You might re-frame it so that it’s more appropriate in the language it’s being said in.

The next step up, if you like, is internationalization. This is the process of managing how do you maintain a product across an entire suite of languages. And this is where I think things can get a little bit tricky, because it slows down your development process immensely when you can’t freely adjust microcopy.

Now, that slowdown comes with its own cost and its own benefit. Obviously the cost is everything moves a bit slower. If somebody builds a fantastic, quick feature, it’s not going to be, “Let’s deploy this today,” because you need to actually go through a lot of work to get it across the board. However, the benefit should be that because you’re trading in all these other extra countries, you should be open to a lot more revenue. Rolling out one feature can actually have multiplicative benefits because so many different people are experiencing it.

At the top of the pyramid, you’ve got globalization. Globalization really just concerns itself with the process of internationalization, which is like when you’re removing every single barrier that actually needs to be addressed for a business to trade across different languages. The biggest differentiator there is, it’s one thing to say, “Whoopee! Our site’s now available in English, Finnish, Spanish, Portuguese, et cetera.” But what happens when Portuguese customers start emailing you customer-support requests? Well, then you’re in trouble, right?

Globalization is usually when you start to concern yourself with it’s one thing to have a business that is represented online in many languages. It’s another thing to have an entirely globalized business. And that’s the top of the pyramid.

I hope that addresses what we were talking about.

Adam: It does. It feels like that’s a whole separate seminar in itself. Kathleen wanted to know how you recommend storing and retrieving bits of microcopy for reuse.

Des: The most productive way — I’ve never done this — is unfortunately related to just, it’s when you’re collocated with your design team and you can all just reference the same white board or the same Basecamp or the same Google Docs spreadsheet or whatever. The key question here is, when we define terms, how do we make sure that they’re consistent across the board, I guess? And the best way to do that is to have a good shared repository of these things.

I’ve seen varying solutions here. There’s a tool called Copycopter, which extracts all the text from a Web product and keeps it all there. It makes things like internationalization a lot easier. I’ve also seen simple things like just a Google Docs spreadsheet which just has a section called “confirmation mail,” and it just has all the key pieces of text that are used there so that as they’re updated they can be replicated across the product. But what you’re looking at there is effectively document management, of a sort, across the team.

Typically, whenever people ask me that question, there’s no tool I can recommend that’s going to fit into your work flow any better than something you can come up with yourself. As I said, whatever you find is the easiest way for maintaining text files within a team, so that everyone has access, can update, edit, and view them, that’s the right solution for you guys.

Adam: Regarding the solution that’s chosen, how have you seen them scale when people are supporting lots of products and lots of words associated with them?

Des: Absolutely. This is where it gets a little bit trickier. This is when a white board won’t scale, because you’re probably not collocated as a design team anymore. You need a way to control the copy or the content of your product independent of everything else. And this kind of feeds into the first question, too. If you’re getting to that scale, you’re probably also not just trading one set of content, you’re actually trading multiple sets. So you have the content of the Web application, and if you decide to change the phrase “welcome to our product” to something else, you have to make that change seven times, update it everywhere, and re-roll out your product across the board.

So how do those things scale? Well, the best I’ve seen tend to be quite problematic solutions where you have a developer or a content strategist/developer who is in charge of the product copy, and what they will end up doing is using a variation of a source code control tool, like, say, GitHub.

And what they will do is they make adjustments, merge them in, assign tasks based on the adjustments so it’s then localize this word, localize that word, etc., or update this phrase, and they will basically be the governing body for all the content that comes back, and as they complete they will then merge back into sort of the master product which we’ll roll out.

But that tends to be a big product. The point at which these things are a concern is the point at which you should have people in place who are fully responsible for the content of your product, and, if appropriate, the internationalization of your product. But there’s no magic bullet. If you’ve got that big a product, that many users, that many locales, you have to be investing in this, because the return is significant.

Adam: David wanted to know if you had any views on pronouns in labels, and the example he offered up was something like, “my profile,” versus, “your profile.

Des: Yeah, this one come up a lot, and it’s kind of whenever we used to work with startups it was always the most contentious question, because everyone has an opinion and a preference. But we tested this quite a bit for a client before just because it was one of those ones where it turned into what we call a bone fight, where everyone thought they had the right answer. You might call it like a [indecipherable 12:37] , but everyone sort of felt that they had a valid opinion, and because there was no science backing up anyone’s opinion, it felt good to throw in with anything.

So we tested it, and there’s no measurable difference. The biggest problem we identified was that whichever one you choose you have to generate all of the copy you’re going to write at decision time. Don’t say, “Right, we’re going to go, “my” across the board,” and then later on you might trip yourself up writing your health documentation saying, “To log into your account, click My Account, and then your password into the My Password field” which is when you think about that sort of thing you realize, right, we really screwed that up, like, because that sentence should not be read by any human ever.

So if you’re going to make these decisions don’t do it on a whim, but also just think it through a little bit deeper than just like if you’re deciding whether to call it, “My Account,” or, “Your Account,” it’s not just the login box that you’re going to make that decision for. You’re making that decision for your help, for your seminars, for your frequently asked questions, for your reset password, emails, for everywhere. So just make sure you’re able to be consistent across the board.

My personal preference tends to be speak to, “My,” but honestly it doesn’t bother me either way. What you will also notice similar the rule that Jared offered about icons when he said you can swap out icons as long as you keep the positions the same, most people kind of…they zone out for those words, anyway, like as in whether it says, “Your account,” or, “My account,” what they’re actually seeing is, “Account.” They kind of…they skip over that. It’s not a valuable word for them. So as long as you don’t get it inconsistent or trip yourself up with linguistic sort of gymnastics you should be OK.

Adam: What’s your take on the value of mouse-over clarification text?

Des: It’s a valuable question. My pet peeve with like mouse-over text is that it tends to be what people should have said in the first place. So a classic example of this is for so long before humans got used to it, we used to say, “CVD,” for a credit card form, and then you have a question mark on the other side on which you would hover, and it would say, “This is the three digits on the back of your card.”

And I always felt that it’s like we’re putting the human explanation behind this question mark, and we’re putting the machine explanation as the default. That kind of stuff frustrates me. Another thing that frustrates me is when people put really, really data-rich useful stuff like, for example, sample inputs that are valid behind a hover, and they’re using a label that’s quite arcane or weird.

And I remember working on a gambling site where this happened a lot where people, they’d ask questions such like what odds faction do you want? And no one knows. Like we worked with a lot of gamblers, pretty professional guys, too. No one knew what that meant until they put a…they went for the assistive text or the hover text, and it would then explain, “This means do you want 11 to 4, or do you want decimal odds?” And then everyone was like, “Oh, I know exactly what that means now.”

So there’s a lot of value in there, but what frustrates me is that people tend to put the good stuff in there and leave the bad stuff as the field because they feel like they’re being in some way more correct or true to labels. In reality the label, like what a business calls something is actually irrelevant to what the users calls something, and it’s the user you’re serving with these interactions so focus for them first.

Secondly like if you find yourself using a lot of these because you simply can’t fit the explanation you want to fit in your form, take that back to your UX designer or whoever who laid out the form and explain the problem that the terminology we’re using here isn’t just username/password. It’s quite complex so you need to design us a form that let’s us put a sentence for each input.

There are plenty of good examples of this done well like where people have long explanations of an input followed by the text area itself, and I find that’s a better solution than an arcane label no one understands and then a tool tip that’s three paragraphs long to try to justify it. So that’s kind of my answer.

Yes, use it, but if you find yourself leaning on it or relying too heavily on it — you can check this kind of stuff with analytics — but if you do find that it’s becoming the default everyone knows then your default design is broken and your backup supportive stuff is what’s saving you, and that’s not a good position to be in.

Adam: Sure. Sure. How do you help stakeholders or clients from insisting on something that you know to be problematic copy?

Des: This is actually funny because it does relate to the exact previous question, because a lot of times when I see people using assistive text to save themselves it’s usually because oh, the stakeholder pounded the table and said that he really wanted to call this the CRX form, and it turns out none of the users know what CRX is.

The only way like — and this is kind of related to order design decision challenges that you come up against as a consultant — the most effective way is home truth. A great way I once solved this was sitting in a boardroom of a university, and everyone was fighting over what we were going to call this input on a form, and it was just getting ferocious where people were being so passionate about what should be so meaningless, expect for I knew it wasn’t going to be meaningless, because if people didn’t understand this it was going to fail.

So I said, “Right. Well, let’s ring all the people who we know are definitely going to use this form and ask them what they would call it.” And everyone’s looking at me disgusted like, how dare I. Surely we can divine the perfect thing here with this argument. So I started ringing people, and it turned out everyone’s guess was totally wrong, because no one knew what the form field was.

But I only had to have three or four phone calls before the stakeholders turned around to me and said, “You know what, Des? We don’t need to be here for these phone calls. Why don’t you ring everyone and then come back to us with the answer, and we’ll just accept it.” And I said, “OK, thank you.” And that’s what you have to do.

There’s no best practice UX for identifying the right copy to ensure a stakeholder won’t challenge it. What you really need to do is meaningfully address the challenge of what is the right copy. And there’s two ways you do that. It’s similar to how if… if any of the listeners have worked this information architect before, it’s a similar challenge to identifying what’s a good navigation choice.

What I would do when I’m trying to identify what the right labels are, and I want to push it past the stakeholders the two things I do is, one is exploration. And I do that through observation of how people talk in the domain. So if you’re working on a gambling site you ask people do they call it a bet, or a gamble, or bet slip, or do they call them odds, or do they call them decimal points, or do they call them wins?

And you just observe the language that is used, and you make note of what you believe are the right choices or the most frequent choices, whatever particular terms people use most often.

That’s your exploration phase. So you gather a lot. And then, individually, you’re going to take the terms you’re considering using and test them. The best way to test these things is just — you can do it pretty lightweight. It doesn’t even need to have a full interface or anything.

If you ask somebody, for example, “Do you know what an authorization is?” chances are they’ll say no, and you’ll say, “OK, we’re going to need to explain that one better.” Yet if you turned around and asked them, “What would you expect to find in mail preferences?” they’d say, “Oh, I’d expect to find how I can control what email I receive there,” and you say, “OK.”

The observation is to gather all the different candidates that would make sense, and then you can test them individually with users by asking do they understand what these terms mean, do they guess correctly what they would mean. You don’t need to do this for an awful lot of stuff. You only need to do it for the contentious ones where the board or the stakeholders are likely to push back.

But if you do do it, it’s a pretty lightweight involvement. And it does help you — the wrong word is “railroad,” but it does help you ascertain your professional standpoint and, basically, get these things signed off much quicker if you do it.

Adam: Felicia wants to know if there are principles for writing error messages.

Des: Yeah so, there are a lot. It’s an area we’re quite familiar with because we used to work on an error-tracking application, and we’ve seen an awful lot of terrible error messages in our time.

There are different categories of error messages, but the key idea here is, “What has gone wrong and how do I fix it?” is what people want to know. The most frustrating versions of this you’ll see is, I’m sure every one of the listeners has had the experience of clicking on a menu item only to see it faded out.

It’s probably the most frustrating experience when you’re first using a product, that you can see what it is you want to do but for some reason it’s faded out, and they don’t explain why. That is the worst version of an error. “You can’t do this, but we’re not going to tell you why.”

What you need to do is, basically, every error message has a state of what has happened or what can’t happen that you want to happen, and then a resolution, which is, “What do you do about this to make this go away?” Sometimes you will end up with a frustrating one such as “Please reboot your computer,” or it could be something like, “Oops, the application has crashed. We’re working on this right now. We’ll be back as soon as we can. Please check our status site for further information.”

The key idea is you can’t leave people lost. When they see this error message, it has to be clear and unequivocal, as in, “This process did not happen.” And then it also has to give you a next step, which is, “Here’s what you should do now to make sure that this never happens again.” That’s the core principles.

In terms of tone on language, different people get away with different things. Twitter tends to be quite cute about it. So does Gmail and Chrome. They use things like, “Oops, our tab crashed,” and they give you a sad face and stuff.

I don’t think that stuff helps or hinders. I think the key idea and what most people want to know is, “If this didn’t work, tell me what to do now.” That’s a core tenet in customer experience anyway. If you tried to go for dinner in a hotel and they just said “No” but they didn’t explain why, it’d be pretty frustrating. In software, if something didn’t happen, the user wants to know why, and they want to know how can they fix that. As long as you get that right, you’ll be OK.

Adam: John makes a comment that he sees a lot of development efforts that involve user-experience people at the beginning but not necessarily a writer, and he wants to know if you have any tips to help get writers involved in the design process earlier.

Des: This is a higher-level question. John’s correct in that these days UX is now understood and valued, and it wasn’t always the case. If you trace back to maybe even 2004 or 2005, UX people still had to argue their case, because everyone felt, “Well, we need software developers, sure. But why do we need these guys? All they do is draw pictures, right?”

The question is, why don’t people now say, “Well, you know what? We need a writer involved early”? The challenges here are, there has yet to be an iPod of content or content strategy. There are a few great examples, but there has not been the mainstream, widespread one. And when I say an iPod, I mean an iPod or an iPhone or even particular products on the iPhone. They’re all great champions of design and they show the real commercial value of excellence in design.

When people hold aloft the new iPad Mini on stage, everyone — executives, top stakeholders, et cetera — they get that this product is succeeding because it is designed really well and it is marketed really well. What they’ve yet to see is “and the copy or content or micro-content throughout the product is that excellent.”

It becomes harder for the content strategy team or the writers to get their foot in the door in these early meetings, which means that they tend to still be an asset that’s tapped into on demand but not a driving force in the product.

I think it will remain that way until you see more and more examples of people like your MailChimps, like your OkCupids, et cetera, where their interface is so good and so effective because it’s so well-written. When you see more of that, I think you’ll see people start realizing that there’s a serious commercial value with having well-written products in early.

The other sort of danger they fall into is that writers tend to often get lumped with the tasks that business doesn’t value particularly highly, so things like knowledge bases and FAQs. An awful lot of businesses and products tend to regard these things as a necessary evil rather than a massive commercial advantage. There’s no reason for that.

We published a piece on the UIE blog recently, saying all content is marketing, and that if you do these things quite well, they can deliver intense commercial value. But until that becomes the standard, I think writers will always have to fight extra hard — harder than, say, designers or developers — to get involved in software. That’s my feeling.

Adam: Awesome, Des. Thanks for coming back and joining us for a little bit more talk on this topic.

Des: Thank you so much for having me, Adam. It was great fun.

Adam: To our audience, thanks for listening in and for your support of the UIE virtual seminar program. Goodbye for now.

Building a prototype is a great way to test your design early on with users. Whether you choose to go for a high-fidelity representation, or go lo-fi with paper, you can learn a lot about the usability of your site. Often, teams are concerned with which technique or tool to use because of the litany that are available.

Kelly Goto, founder of Gotomedia, suggests that the importance of the tool lies more with when you use it than why. Like a great chef preparing a meal, they use the right tool at the right time to arrive at the finished state. Use the appropriate tool and you’re sure to cut down on difficulties you might encounter.

Part of having a mobile strategy in the first place is understanding exactly why you’re “going mobile”. Once you’ve determined what the value is to a mobile experience, Kelly says even something like paper prototyping can help validate the concept quickly.

Kelly is presenting one of the daylong workshops at the UX Immersion Mobile conference April 22-24 in Seattle. For more information about Kelly’s and the other workshops, visit uxim.co.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Well good day, everybody. We have another episode of the SpoolCast here. I am Jared Spool. I am the guy who talks to people. Today, one of the people I want to talk to is Kelly Goto, and I am very, very happy to have her.

For those of you who don’t know Kelly, she runs Gotomedia, has been around in this industry since day one. She wrote a fabulous book years ago called “Web ReDesign 2.0: Workflow that Works,” and she’s going to be speaking at the UX Immersion Conference in Seattle, April 22nd through 24th, giving a session on prototyping for mobile designs, a full-day workshop on it.

Kelly, welcome. How are you?

Kelly Goto: I’m great. Thank you so much. I love that we’ve been here since day one. We don’t have to talk about our actual age, but yes, we have been here since the beginning of digital time.

Jared: Since the beginning of digital time. Before that, we did not exist.

Kelly: Exactly.

Jared: Right, there is no record of us.

[laughter]

Jared: You’re going to be talking at the UX Immersion Conference. You’re going to be talking about prototyping for mobile designs, which is a topic that I hounded you into giving because, frankly, I know that you guys at Gotomedia do such a fabulous job with your design work. We wanted to learn all of the techniques and tools that your team has at their disposal to actually get ideas out in front of people, try out things, see if it makes sense, and then use that as the way to guide their development process.

Just curious. Over the years, what tools have you been using, and which ones are still the most effective for mobile? Have things changed, or is it basically the same?

Kelly: I think I want to back up just slightly. The reason why I think prototyping is important, and the reason why I allowed you to force me into that whole session, is because I think that prototyping is actually the communication tool between businesses, between teams, between designers and developers, and obviously between the end users.

The prototype is a codeword for the best communication tool that we can create between all these groups, so that’s why I think prototyping is so important. To answer the question, we have been using multiple tools, and yes, it has shifted and changed over the years, but one of the things that I’ll be talking about and that I cover in the workshop is what tools are appropriate for your team, your toolkit, and what tools are appropriate at the different stages.

For instance, in the conceptual stage, it’s going to be different people that are creating this concept, this prototype, and its different end users–potentially board members, potentially C-levels, potentially people that are funding this, potentially end users–to begin to understand if this is something that really works.

That might be one set of tools. Another set of tools might be from a design and conceptual standpoint. And then, finally, as we move into this communication between design and development, we have to have a whole another set of tools that actually help create or replicate the specification process. There is no one tool or set of tools that I want to actually put on the table right at this moment.

Jared: That’s interesting. I really love this idea. It’s almost like the way a chef cooks in the kitchen. They don’t have one tool that they make the whole meal with. They have all these tools that are hanging around or in drawers or things, and they grab the right one at the moment they need it. That shifts the conversation from “Which tool should I master?” to “How do I master picking the right tool at the right time?”

Kelly: Yes. I won’t get into pies, but I was just typing out how this session is a piece of the pie, whereas some of the conversation we’re going to be having at the conference itself is not only a whole pie but it’s potentially something completely different from pie itself. I was thinking about this cooking metaphor, actually.

And yes, these are tools. Toolkits. We’re really big on creating a process that’s flexible for people and then inserting concepts and ideas for the toolkit that will be appropriate to that team in the right time and the right place. You do want to pull out what makes sense.

There’s a ton of new prototyping tools that have been launched in the last few years that actually supplement what we used to do with Flash or PDF prototyping, or even Axure or Balsamiq. There’s a number of new tools that I guess fit into different pieces of that cooking structure, depending on what you’re trying to accomplish.

Jared: Now, as people are moving to mobile, how important is it that they start to think about what their whole mobile strategy is before they start prototyping? Or should they just roll up their sleeves and start sketching or banging out some design and just get their head around it? I guess my question is, is it more about thinking about the strategy in your mind, or is it more about understanding the medium?

Kelly: For me, I guess, I hate to say it’s twofold, but when we start off, one of the things that we’ve seen…Obviously, the mobile space has shifted so much in the last decade. You and I’ve been around a while, so we’ve seen it shift and change. It used to be really focused on what handset you’re using and what OS and what type of language you’re coding in.

People were so heads-down that they weren’t really taking a look at the big picture. The concept of mobile user experience was not even a term before you and I started talking about it, before I started blogging about it. Mobile user experience was really limited until recently.

What I see happening is a lot of companies saying, “Oh, we need to get on mobile.” They’re using it as a really broad term, kind of like, “We have to deal with our branding.” I’ve found that the first thing that we need to do is to help companies understand why they’re going mobile, what that means. Is it a mobile device, is it platform-specific, or is it mobile in terms of allowing people to deal with their service or their product in whatever context or situation that they happen to be in? That’s really how we define mobile in this day and age.

Instead of saying, “Oh, we need to build an app,” we need to understand what is the core experience that they’re actually trying to create, with potentially a streamlined experience, on a mobile device. We want to look at the value, the features, the usefulness, and the intent behind what mobile means to that company. Does that make sense as a starting point?

Jared: Yeah, it does. I’m wondering now, if I’m trying to figure out what value does mobile bring to the experience, is that before I start prototyping? Are there actually prototyping tools in my toolbox that help me visualize that process?

Kelly: Coming off of a number of, I guess, client relationships, and also some workshops, I think that prototyping, even paper prototyping, can be a really quick sort of validation of what that concept is, and then you need to pass it around and evangelize it within your organization.

I think that getting to the concept, there’s a number of steps. From a mobile perspective, when you, quote, “go mobile,” does that mean that you are taking your website and putting it onto a phone? Does that mean that you’re recreating that experience for the phone specifically? Or are you taking a service or a product within your company or your company’s experience and then creating an app for the phone specific to a function or a type of thing that people were used to doing online before?

Just understanding exactly what the experience is and then understanding the platform, the context, is it a complex or a simple kind of interaction, I find that to be really important.

There’s something that came out of the lean startup space which is called MVP, which is the minimum viable product, and we’ll be talking about that a lot in the session, in the workshop. Minimum viable product is actually quite interesting, because there’s a tendency for companies to want to go feature-crazy and say, “We’re doing all of these things and this is what we’re capable of doing,” instead of focusing on what are the minimum elements that need to be absolutely perfected before we launch, and what are those elements and how can we make them the best possible.

Focusing on that MVP, the minimum viable product, is actually a great way to start prototyping.

Jared: The interesting thing, I think, about this minimum-viable-product stuff is that a lot of the business people are learning about this now and reading about this, and it’s a common phrase we hear about that. That’s a great way, I would think, for a designer to get the interest of the stakeholders and to say, “Look, this is a way for us to test the minimum viable product,” and to put together a prototyping strategy based on those business needs.

Kelly: Yeah, absolutely. If you look at that methodology, I like to use the term “lean” a little bit more than “agile.” I feel like Agile’s also one of those terms that just sort of came out and it’s overused. But if we think about a process that allows this sort of streamlined communication between stakeholders to concept, and then moving from there into rapid deployment and iteration, that’s really what we’re trying to do, and that’s what that process is about.

It’s not about doing something so fast that you can’t think about it, and it’s not about providing less documentation or trying to approach it haphazardly. It’s actually about focusing on what really matters, making sure there’s buy-off and understanding at all levels from a business standpoint, and then continuing to iterate within both an organization and also with your end user.

We want to create something that’s streamlined so that we can get through the most important pieces in a rapid way. I really believe that this does not mean that it has to be haphazard or that anything really needs to be lost in terms of the quality that’s being put out.

Jared: I do know that that phrase, “minimum viable product,” sends shivers up the spine of people who tend to have a perfectionist streak to them.

Kelly: But the other thing that is really helpful to think about from an organizational standpoint is prototyping bits and pieces. For instance, in one of the products that we’re working with now, we have prototyping for a lot of pieces that we have questions about. Because touch is newer and different than what you can do online and there’s a lot of space issues that we need to deal with, constraints, there’s questions that we have about nuanced interactions that we want to test.

One of the things that I’ll get into in the workshop is breaking it up into segments of interaction. You don’t have to prototype everything. There are tools that are potentially better for testing out those snippets of interaction that can help you create a whole picture in the end, but you don’t have to test everything. You can just test pieces that you have questions about and make sure that in a 10-minute test with someone that it’s working for them.

Jared: Now to be able to do these 10-minute tests you need to have some fluency with the tools. How do you recommend people get to know a tool? Is there a way that you guys like to practice when a new tool comes your way? Do you just play with it for a while or do you just tackle the project with it? Or how do you suggest people get to know some of these prototyping tools?

Kelly: Well, I think everyone has their prototyping tool of choice, and so if you just run a little poll within your organization everyone’s used different things from Keynote to Balsamiq to Axure or Paper Prototyping. People have their own tools of choice.

I think it’s unwise to force people away from something that works for them, especially when they’re working in a quick fashion. They’re used to something, and they can execute it.

However, I have found that introducing a series of tools or one at a time with an organization and then having a training session…We’ve been really lucky to have some of the founders of some of the tools that we’re looking at come in, because they’re local and they want to get feedback and actually walkthrough their tool with us and how they think it’s different.

That’s been really helpful. You can take a look at podcasts and screencasts together and understand how easy, for instance, it is for a tool. I think for a tool to work across an organization it needs to be useable by the non-technical people. It needs to resonate with the people that have a technical bent, and in the end, if it is working towards requirements. It has to have really documentation abilities and output.

Now, we haven’t one tool that fits all those pieces, but we are experimenting with a few of them that say that they do that, and really I think you just need to actually dive in and use it. So, yeah, jumping on a project and starting to use it right away, that’s really going to be probably the best way to approach it.

Jared: Do you do any crosspollination stuff where like if you have someone on your team who’s really good with Balsamiq do you have them do workshops to help other team members learn enough Balsamiq so that they can do a decent job pretty quick?

Kelly: We’ve been doing that with a couple products. One of the tools that one of our designers likes to use is Axure RP. It’s actually a tool that’s come up in almost every workshop that I’ve done over the last decade, because I’ve actually been looking at prototyping for a long time and how it fits into the overall process.

It’s not that I recommend this tool for every organization, but there are a lot of people that use it because it has really robust capabilities, and it can do things at a higher level. There’s some super easy to use newer tools like Proto.io, and I guess FieldTest is another one that a lot of people like to use. I mean there are so many out there. Easel is a new one that we’ve actually been working on in-house, and we’ve actually like it a lot.

I think that the newer tools, although they’re slick and clean and they get your site looking really mobile ready, fast, and it’s a great kind of wow factor, unfortunately some of those tools don’t allow the level of detail necessarily for some of the interaction that I was talking about earlier that needs to be tested out in snippets, like new ways of doing gestures or swipes or pull down menus or just a little more detail that you need in order to get into the nuances of the interface.

But for concepting, it’s fantastic. Once again it will differ where you’re at and what tool that you use, and we’ll definitely be getting into the pros and cons of that at the workshop.

Jared: I want to go back to this idea that there are different tools for different stages, and maybe you can help me understand like a tool that’s really good upfront in the design process but not so good…what makes a tool be less than desirable in one stage, but really awesome in another?

Kelly: Well, I think that if you think about the stages from a really basic standpoint, you have brainstorming in concept exploration so you have that at the first stages. Then you actually have the concept development moving into UI creation, and then as you continue to the right we have specification development and moving into communication with the development team. So that’s kind of, I guess, the basic outline of the stages.

Then you have states. So you have low-fidelity, the high-fidelity. In the years that I’ve been thinking about prototyping and prototyping in our group and testing, generally, low-fidelity to medium-fidelity is really excellent to get validation from early concepts to, like I said, the snippets moving into getting feedback.

Even the earlier that you test–we will always, always get into this–the more feedback you get early on it’s always going to be better. Sometimes low-fi is really a fantastic strategy for every company to be able to engage in because they’re going to get feedback early on.

People who look at it are going to feel that their feedback is something that’s being accepted because it’s in early stages. They’re not going to offend anyone. It’s a really good way to get continuous feedback in a really quick manner.

As we move into concept UI and the UI itself and then specification it kind of moves up that ladder from low-fi to high-fi, and we get into high-fidelity, we get into tools that work easily or merge with Twitter Bootstrap, and one of those is Easel. That’s why we’re playing with it, because we’re trying to consolidate our libraries and all the different toolsets that we’re using in our organization.

Then moving into what I had mentioned earlier, which is something like Axure RP, which is super high-fidelity and really leads into specification development, and it’s a little bit more tricky to learn. It has a higher learning curve.

Jared: The low-fi tools, those are the sort of rough sketch tools that are just really fast, and because they don’t have much fidelity you can just get the idea out there. There’s an advantage to low-fi tools because they don’t look finished, and because they don’t look finished, people don’t comment on things like, “That’s not the shade of red you’re going to use,” or, “That’s not the font you’re going to use,” and stuff like that.

You get to change the conversation from that level of inspection to, “Gee, is this the right functionality? Are we even solving the problem in a meaningful way,” right?

Kelly: I think that’s why people love Balsamiq and why Paper Prototyping UXPin has some really great paper prototyping tools. I think that’s the reason why Balsamiq is so popular because it’s saying, “Hey, I’m not finished, but can you comment?”

There are some low-fi products that maybe get a little bit into the medium category like Fluid UI or what’s another one? Mockups I think is another one. There’s Just in Time or Just in Mind–I can’t remember– that actually look professional, look finished, but they’re super easy to get something up and running quickly.

There’s a lot of drag-and-drop and in-browser interfaces, and then the shareability is pretty quick.

I think low-fi doesn’t necessarily have to be rough in order to be shown. I do think that when people see things early on and they know that they’re not offending anyone, they are more likely to comment from an honest standpoint and not try and please you and say, “Oh, that’s beautiful! That’s great! I love it!” I think that’s why it is nice to do the paper prototyping and use Balsamiq from time to time.

Jared: The high-fidelity, when you’re there, the conversation changes, right, from what you have when you’re in low-fidelity. What are the things you notice that people talk about differently when you’re working with a high-fidelity version of a prototype than a low-fidelity version?

Kelly: Well, high-fidelity means it’s going to be more complicated. You’re going to have to look at how you’re actually creating the pieces. For instance, with Easel, if you want to build a responsive site and look at that from a design perspective, you need to build it a certain way, you need to import in Twitter Bootstrap library, and you need to know code in order to really execute it properly.

There’s a larger learning curve, a longer time to actually create the prototype, and if you want to export it in any way that’s usable, then it just takes a lot longer.

I think the other factor is the time to get your thought out. The beauty of some of these easy tools is that you can get your thought out quickly. As we move into easy tools that have a robust export feature, the idea there is that you can get your ideas out easily for non-coding types, and then the coding types can take that as a hand-off and then create specifications out of that and even move into an actual code environment.

I haven’t seen that, personally, run as smoothly as the proposed service might think it might run. But for teams that are working, small teams, in-house, moving fast, I do think that some of these tools could cross the gambit and fulfill all those needs. It is tricky, and it needs to have the right resources.

Jared: It does make sense, on some theoretical level, that if you’ve got this thing looking right on the screen and it’s interactive, that somehow or other developers could use that as a specification. Where does that tend to break down, though, in reality?

Kelly: Well, usually, the code is throwaway code, and so the time that it would take to actually structure something correctly in one of these environments isn’t really going to yield the code that you need because, in the end, it’s more complicated than what a machine output can create.

The reality is that we usually hand off something. In the old days, we would hand off a Flash prototype and put it into a specification use case and sort of create the desired movement, the desired behavior, within the animation and use that to help developers understand what they should do. In today’s world, you can mock that up pretty successfully using a lot of these prototyping tools, and then you can actually test that live. Some of the interaction will work.

But like with any tool, it’s really whatever the best fit is for that individual person. You have to take into consideration what their skill set is and what their goals are and what they’re trying to do. I really do believe that it’s quite a diverse tool set, for each company, each team, and each individual, and you need to look at a lot of different features.

There’s so many versions of tools out there that it really is boggling my brain, doing all this looking and research, so I have to stick with my toolkit mentality, where you pull it out when you need it, at the right time.

Jared: I’m interested in the relationship with the developers. Do you find yourself bringing the developers in earlier into the process than you might have otherwise? And if so, are you working with them side-by-side on the prototypes, or are you basically handing this prototype off to developers and saying, “This is the spec. Code from this”?

Kelly: What we’ve been doing is working within more lean-UX principles. I don’t want to say “Agile,” again, because I think that’s loaded. But it works best when the teams can work closely together, when they have daily meetings, when they have access to each other, even if it’s one day a week, where they can actually work on a white board and sketch things out and show things in person. I find that the designers and developers truly need to establish whatever means of communication that they need that works for them.

Prototyping is a great tool, but I guess I would prefer that the prototype mimics a concept and shows a behavior rather than it becomes a full spec, because I believe that if you have the right level of communication between the design and development team, that you can translate that fairly easily using wireframes and screenshots and call outs, along with a prototype mimicking behavior, to get that specification across.

When we’re in a Lean environment and we need to work quickly, then we need to use whatever communication means is viable, while still maintaining some level of process so it’s not completely haphazardly done.

Jared: It feels to me like prototypes give you this opportunity to speed your process in a way that you don’t get when you’re either doing some sort of large Word document specification or the ritual of drawing things on the white board and hoping the thing you imagine in your head is the thing they imagine in their head.

Kelly: Exactly, yeah. There’s some great tools for just sketching something out, taking a picture of it, putting it on your phone and testing it right away, and there’s some tools that actually allow you to stack these things and create interactivity on the fly.

I think that getting your idea out and getting feedback is really the gist of what we’re trying to do, and whether you’re getting feedback from the stakeholders or the business leaders or your development team, and most importantly your end users, you want to get that feedback quickly, you want to iterate, and then re-put out that prototype or even build it into the process of the development cycle, and get continuous feedback throughout.

Jared: You had mentioned earlier about responsive design, and this is something that I’ve had conversations with, and I guess I’m not clear on the answer. Which is, if I’m starting to think about responsive stuff, so I’ve got what my design looks like on a high-resolution desktop, or I have what it might look like on a small-screen-size phone –though some of those can be really high-resolution now– or on some middle-size tablet type thing, what do I do with my prototypes?

Do I come up with three different prototypes of what the interaction might be like in each of those sizes, or do I primarily pick one and then just focus on that to start with? What’s your practice there?

Kelly: That’s why we’ve been using Easel and we’ve been playing with it, because Easel allows you to build these containers, and then you populate the containers, either through drag-and-drop or through code. The containers scale, so there’s output for Web, tablet, and mobile. We’ve been playing with this. It’s only been out for six months, and it’s still in development.

We’ve been really impressed so far. But we do need to show our clients, usually wireframes with breakpoints, and if we’re able to wireframe and do prototyping, using something that automates this process, it’s so much more helpful and streamlined for us.

We’ve found this to be working and to be highly successful, and we’re also trying to integrate changes with the product itself that would even help it streamline that process in a more efficient manner. So it’s been a continuous, I guess, moving through this. We used to spend so much time creating three different versions or two different versions to show different breakpoints, and now we’re finding that we can use tools like this to mimic it real-time.

Jared: That’s fabulous. I’m really excited about the workshop. I think that people are really interested in learning how to make sure that prototyping is part of their design process. It was something I was really glad that we were able to snag you for this and have you, because I think people are going to really love it. I’m really looking forward to your workshop at the UX Immersion Conference in April.

Kelly: Yeah, absolutely. I really think that prototyping and the level of communication that’s needed just constantly comes up. In every organization that I see, they’re asking the question, “What should we be using? What should we be using?” Because this is such a topic, combined with a more streamlined process that we all know that we’re trying to achieve, I think it is a perfect addition to what you’re proposing for a curriculum for the UX Immersion Conference.

Jared: Fabulous. Kelly, thanks for taking the time to talk with us today.

Kelly: You’re welcome, and I’m looking forward to April as well.

Jared: I want to thank everybody. You can learn more about Kelly at gotomedia.com. She’ll be at the UX Immersion Conference, April 22nd through 24th, doing her full-day workshop, “Prototyping for Mobile Designs.” It’s going to be a lot of fun, and a whole bunch of people have already signed up and seats are going, so you want to make sure you get your seat.

If you listen to us on iTunes, it would be awesome if you were to go and just check out the ratings for our session and put in your opinion, because people are listening to us and they’re looking for new stuff, and if you thought this was great, it would be wonderful if you could put that there. We look at the ratings and would love to know what you think.

Thanks again for spending the time to listen to us. We’ll catch you at a later time. Thanks for encouraging our behavior. Talk to you soon.

Here’s an excerpt from the article

I have to think about the user, so I typically start with a text file. I create the content in a text file based on conversations with the client and with end users. I then hand it to the designer and the designer really builds the site around that. Once I hand it to the designer and some comps come back, I might make a few UI/UX suggestions in the notations as part of the content.

Otherwise, I leave it entirely up to the UX designer to create wire frames around the content itself. In all cases so far, the designer has really loved this process. It’s liberated that person from having to think about the content because it’s already there and that’s what’s ultimately speaking to the user. It’s created a structure and a process around the most important stuff to be communicated without requiring the visuals to lead back to it.

Read the article: Making Content More Usable for both Designers and the End User.

Hear more from Steph Hay

On February 14, in her seminar Building Trust with Your Users through Messaging & Copy, Stephanie Hay is going to show you how to take cues from online and offline interactions to write candid content, craft helpful user experiences, and maintain users’ confidence even when you “fail.”

How do you begin your process of moving from content into design? Tell us about it below.

What makes a user want to download an app in the first place? Ideally, it’s the promise of fulfilling a goal or need for the user. With the hundreds of thousands of options available, and the immediacy of the mobile context, you have a small window of opportunity to engage your user. If users can’t easily use your app, they simply won’t.

Mobile devices are stuffed full of sensors and cameras, yet forms tend to be the prevailing means of input on these devices. Creating an account, uploading a profile photo, and registering, right as you first open an app creates an incredible barrier to use. Luke, in his app Polar, opted to let users experience the app itself. Because users see what it does first, there’s a greater conversion rate.

Luke says that with 80% of mobile app use time being focused on entertainment, the phone has really just become another screen in our lives, like the TV. Games and social networking make up a lot of the time users spend on their phones. Luke suggests that companies consider this aspect of entertainment when developing their own apps.

Luke is presenting one of the daylong workshops at the UX Immersion Mobile conference April 22-24 in Seattle. For more information about Luke’s and the other workshops, visit uxim.co.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everyone. I want to welcome you yet one more time to another episode of the SpoolCast and today, today, today, we have our returning champion, Luke Wroblewski, to come talk to us. Luke has won every episode of the SpoolCast. The high-score file is his. I don’t know, how many shows have you done, Luke?

Luke Wroblewski: That’s a great question. I’m guessing it’s around 10-ish by now?

Jared: Yeah, it’s got to be. It’s got to be something, yeah.

This time, we have Luke coming back because he’s got news to tell us about his new company. He’s going to be speaking at the upcoming UIE UX Immersion Mobile Conference, which is going to be April 22nd through 24th in Seattle, Washington, and he’s going to be talking on designing mobile input.

Today we’re going to talk about his new venture. This is a new thing. If you haven’t heard about it, it’s really awesome. It’s called Polar. It is this little phone app that is very cool. I hear you guys have hit a major milestone this week with Polar.

Luke: Indeed. The application allows people to collect and share feedback through little polls, hence the name Polar. The major milestone we hit last night, actually, is we crossed one million votes. One million votes is a pretty big number, but the more interesting thing about it to me is that the second half-million of that total came in the past eight days, whereas the first half came in the first 11 days. People seem to be voting an awful lot.

Jared: It’s really cool. I’ve played with the app a lot. It’s one of those things I fire up when I’m looking to kill a little time. People are posting pictures and, “Do you want this? Do you want that?” You just click with your thumb and all this stuff.

You’ve been working on this for quite a while now. How long have you been working on it?

Luke: My co-founder, Jeff, and I got together around the March time frame, and we were sort of batting around, “What do we want to build? How do we want to build it?” I think we actually started making things around April or May. That took us up until November. Six-ish months, something like that? Seven-ish months?

Jared: For years, you’ve been telling other people how to build mobile apps. And this is your second one. You had Bagcheck before, and now you have this one. What are the big things that you had to sit back and say, “Yeah, this is what I tell people all the time. This is what we’re going to do”? What were those big lessons that you were able to apply?

Luke: At a high level, I don’t think I have anything to share unless I’ve tried some things and learned stuff, right? At a very big-picture level, I’m always trying to make things, so I can learn and actually have the lessons firsthand, so that any information I’m sharing with other people actually has some basis in reality.

The interesting thing about that is I think it really comes from me being a designer. The designers I work with, at least most of them, and the way I work is, if a designer’s faced with a problem, what we do is we just get our hands dirty and jump into it. We start to iterate. We start to do little sketches. We start to do little prototypes.

Through that process of building and making and designing, you learn a bunch of things. You uncover connections you didn’t know were there. You uncover problems you didn’t know were there, and you go on tangents that ultimately lead you to more valuable stuff.

I think it’s very, very healthy to always go and do what you’re talking about, because it level sets you, right? It lets you know if you’re actually talking about the right thing and also gives you a whole new set of stuff that you uncover, and ultimately you’re like, “Oh, I learned this. I want to tell somebody about it!” So it’s good.

Jared: Of those things that you’re trying out, was there anything that you were surprised at either how well it worked, like it surpassed even your expectations?

Luke: Yeah. Let’s talk about a good example and a bad example, something that I thought would work and didn’t, and something that I thought would work and is working. Actually, I’ve got a whole slew of these insights, which is kind of cool, so maybe we can talk about a few of them.

On the side of things that are good and are working, for a long time I’ve been advocating this idea of “sign-up forms must die.” The general principle there is, instead of having the first-time experience with a Web application being “sign in, fill out this form, register, create an account,” before you even know what the thing does and how it does it, let somebody in and let them get going, learn about what you’re doing and actually interact with stuff.

That was the approach that we took with the mobile app, Polar. If you download the app, you can open it up and you can just start voting, voting, voting, all you want. There’s no form. There’s nothing out the gates. As you interact with it, we’re actually storing all of your results in a unique token, if you will, or a unique-to-you set of events.

If, at any point in time, you decide, “Hey, I kind of like this. I want to create my own poll, or I want to leave a comment, or I want to share,” something beyond this initial voting process, we’ll actually take all the votes that you have and map them over your account so you don’t lose any of your activity.

What that’s done for us, I think, from a data perspective, is actually pretty compelling. I saw, there was recently a post written by an entrepreneur who was talking about the problems they faced building mobile-first companies. The way he defined mobile-first is “build a native app first.” Which, I don’t want to get into the debate of those definitions, but that’s what he was doing.

He outlined some of the problems, and one of the problems he highlighted was, just because somebody downloads your app doesn’t mean they’re actually going to use it. He cited some numbers from a big app manufacturer that has over 100 million downloads, that their stats showed 50 percent of people that downloaded it didn’t even open the app.

Other data that I’ve seen, when I worked with a really large, very popular mobile app earlier in the year, who I can’t reveal who that is, their sign-up flow in their mobile app had something like 25-percent conversion, which is really low, right? It’s hard enough to get somebody to download your app off an app store when there’s so many hundreds of thousands of apps.

And then the other piece of it is OK, you finally got that download out of them. That was hard enough. People download like one or two apps per months. Actually, it’s two and a half apps per month. You got that download out of them. That was a lot of work. You had to work really hard. Now you lose 50 percent of people from signing up because you have this login screen upfront.

What we did with Polar that’s different is you open it up, you start using it. The numbers that we’re seeing — and this is in our first three weeks or so — is 85 percent of people that open the app actually vote on it. Much, much better than the 50 percent or the 25 percent or those kinds of dropoffs.

That’s an example of me taking one of these ideas that I’ve talked about for a really long time, “kill sign-up forms,” putting it into action and actually having some data behind it and seeing what happens in real-world use and experimenting to see what we can learn and how we can make it better.

Jared: Yeah, I completely get that. I watched my fiancée play with it. She downloaded it. I was like, “You’ve got to see what Luke’s doing.” She was like, “OK, fine. What is this?” “It’s polls.” She’s like, “OK. I don’t think I need to use this.” Then five minutes later, she was like, “Oh yeah, I find myself voting on things.”

[laughs]

And so now she’s using it.

Luke: Yeah. I think you don’t get that value if you don’t let people in right away. Everybody’s naturally a skeptic, probably, right? Like I was saying, there’s just so many things out there fighting for our time. How much effort is somebody going to really put in if you just keep throwing barriers in front of them?

I download this app. “OK. Connect to Facebook. Connect to Twitter. Fill in this form. Upload your picture. Tell us about yourself.” Seven steps later, you still haven’t done the thing that the service or the app allows you to do.

One of the big ideas with mobile, in terms of mobile input, is make it fast and easy. Also, make it fun. The fun factor is actually something that I’ve been talking a lot about recently because a lot of people downplay this. But I have a theory, which now I actually have some data to back this up, which is that I think mobile is another screen for entertainment in our lives. Just like the TV is an entertainment screen, the mobile screen, in many ways, is an entertainment device.

There were some stats that came out three or four days ago from Flurry that showed time spent in the US in mobile apps is encroaching on time spent watching TV, which is just crazy. In addition to that, mobile devices and TVs are actually kind of hand-in-hand. 40 percent of Americans use tablets or smartphones while watching TV at least once a day, which is also huge.

When you look at that, OK, people are using these things a lot. What are they doing on them? Well, 80 percent of mobile app time is spent on games, social networking, and the generalized entertainment category. I think the actual number is 79 percent of mobile app time, therefore, I say, is spent on fun. I think that’s a reality you have to be cognizant of. Mobile is the new entertainment in many people’s lives.

Jared: This fun thing. Is this fun thing something that applies to every application? If I’m working on an app for an insurance company or something like the American Red Cross, or even something like TripIt, which tracks your travel itineraries, is fun really a piece of that, or is there something else to it?

Luke: I guess I love the word “entertainment” more than “fun,” because “fun” implies the wrong thing.

Let’s take some of these examples. I hadn’t thought about this at all in this conversation right here, but you may actually use this as a filter for whether or not you should build a native app for mobile. If you’re an insurance company, and your primary objective is to get information out about your insurance, allow people to sign up, all those sorts of things, do you really need an app? Maybe you need an app to allow people to take a picture when an accident happens and file a claim quickly, but that happens once every 10 years.

Jared: Well, I think, for insurance companies, I could see claim and account management, being able to use my mobile app to find out when my next payment is and what the balance is. Because some folks, when they’re paying their auto insurance, they’re working hard each month to get that payment put together, so they need to know what date it’s going to be pulled out of their bank account or when it’s due. That’s a piece.

Then you’re right, the claim thing. Which, my car is currently in the auto-body shop, so right now I’m neck-deep in auto-claim-related stuff. Knowing what the status of various things are, I could see an app for that. And yeah, I would only use it when I have an accident, but now that I’m using it, it’s a big deal for me.

Luke: Right. I don’t doubt that it’s useful in some of those situations. Like in your case, you got a car in the shot, but how often does that happen? From the company’s perspective, is it worth the effort of building and maintaining these apps. I don’t know the answer to that question.

Jared: Right. Well let’s say the ROI is there. Let’s say that if you can stop someone from calling the 800 number to get, for instance, the information about how many…Let’s take a simple thing that happens in an auto claim. You get a rental car approved. What is that maximum dollars per day of the rental car approval?

I’m standing at the rental car agency and the guy says, “Well, what’s your insurance company going to pay, the maximum number?” I have a choice now. I can either go into the app or I can call the 800 number.

The 800 number has a cost to it. The app doesn’t, or as much. You’re talking about an up-front cost to develop the app, versus an ongoing cost to answer that 800 number.

So the ROI could be there. So let’s say the insurance company says, “Yeah. That would save us a ton of money”. Now, where does this entertainment thing come in?

Luke: In each of these cases I think you have to look at what are those use cases, right? You’ve mentioned a couple of good ones and that might justify the ROI. But if I was that insurance company, I wouldn’t expect people to be using that app every day. I wouldn’t “blow” it all on mobile. That’s the lens that you look at the majority of use at.

The things that are going wild on mobile is things like social networking and games because that’s the things people can pick up at any point in time throughout the day. If your goal is to create a ton of engagement with people through mobile devices and you’re an insurance company, you may be swimming up the wrong creek with those kinds of use cases.

Jared: OK. But here’s another one, and maybe I’m an exception because I’m traveling so much. But I use TripIt multiple times per week. I’m looking up my travel itinerary and different details about it multiple times per week. Where does the entertainment factor come in there?

Luke: Well, I would say that that’s not in the entertainment factor. I would say that piece is in the other 20 percent of mobile time spent. If you look at a chart here, they have in there, 10 percent is utility. I would characterize that as probably utility.

You have productivity. You have news. You have health and fitness. You have lifestyle and you have other.

But when you look at the big portion of the pie, when something is consuming 80 percent of it, it’s something that a lot of companies should at least consider. It may not be that they do anything in that space at all. Clearly there’s traction in mobile as an entertainment device.

It doesn’t in any way negate the fact that utilities are useful on mobile. But it’s less likely there going to become an everyday, multiple times a day kind of engagement which is what everybody’s dream is for a mobile app they create.

Jared: Well, is it? I’m wondering if that’s…

Luke: It sure is out here in Internet land.

Jared: Well, OK. Yeah, but you live in Silicon Valley. Things aren’t real there. I’m wondering if…

Luke: Yeah. If you’re a news site you want people to read the news every day.

Jared: Absolutely, yeah.

Luke: If you’re a fitness training program where people are tracking their calories or activity, you want them to use it every day. If you’re a productivity tool, like a calendar manager or something like that, you want people to use it every day.

I don’t think it’s just one niche of things that people that are in it, not just like the Silicon Valley social app thing, that has that goal of daily engagement. I think there’s lots and lots of domains that are aiming for that.

Jared: Yeah, but I’m thinking of a lot of the big blue chip companies that have things that could warrant having a mobile presence. They have desktop apps.

One of my clients is in the yoga studio business and people could use their mobile apps to make appointments to go see the studio, to find out, if they’re traveling, where the closest studio is. That’s not an everyday thing maybe but it could be a once a week thing. It could be a once every other week thing.

Luke: Yeah. In all those cases you’ve got to justify that cost versus the benefit you gain from it. I totally do not mean to diminish any of those kinds of use cases. I think they all make a ton of sense. I’m simply pointing out that if you look at where the bulk of the pie, the activity in mobile is happening right now.

People are spending a lot of time.

To be fair here, entertainment apps and utilities actually gained some market share at the expense of social networking and games. That might be an interesting trend to look at.

Last year games were about 50 percent of time spent in mobile apps, while social networking was about 30 percent. This year games is down to 43 percent and social networking comes in at 26 percent. What you’re describing actually could be gaining a lot more traction, meaning utilities have started to come up.

That may be a sign of a larger trend too which is mobile’s really starting to mature now. It used to be everybody’s like, “What the heck is this thing? What can we do there?”

Now, just this week, we’ve seen a couple of big companies release some things which to me are really mature mobile products. Flickr put out something new. Google maps for IOS came out.

They’re really well designed in most cases. They’ve really though through mobile use. They’ve taken advantage of touch. They’ve taken advantage of cameras. They’ve taken advantage of the gyroscope. All the stuff that I’ve been talking about for years is starting to come to fruition.

Not to toot my own horn, that’s a result of me or anything like that, but it’s very cool to see it as somebody’s who’s been excited about this space for such a long time.

Jared: I’m wondering if we’re reaching that stage where in order to put something out now you have to have a higher level of sophistication than you used to have to have, both for native and web apps. In order to just play the game, to be part of the game, you have to really have stuff together. Because you will stick out like a sore thumb and look so 2010 if you don’t have something that takes advantage of this latest thinking.

Luke: Or, God forbid, you look so 2008, right?

Jared: Yeah, for sure. Or, God forbid, it’s looks like Whap right with the press one for our main navigation, yeah.

Luke: 2008 were the first round of IOS apps that came out for the iPhone.

It’s interesting that you say like the bar has been raised because in my mind it feels that we’re finally getting started. We’ve had this period where what most people were doing with mobile was port over their desktop experiences or take all their existing web knowledge and fit it in these small screens and weren’t really making mobile things.

Now, when you look at the types of products that are coming out, they are very clearly mobile. The new Google maps for IOS, it takes advantage of the gyroscope, you can move your phone around. I use it as a digital compass to orient you. It gives you 3D space to move through. It’s got street view that uses the gyroscope.

The way you send feedback is you shake the phone. Which maybe that’s silly but they use tone of gestures and they had this great quote when they talked about it. The director or product manager for Google maps said something like “There are no menus. The map is the user interface”.

And for me, a guy who’s been super excited about this stuff for many years, I’ve been like, “Let’s use all these sensors to rethink the interfaces. Let’s use touch. Let’s kind of create different kinds of experiences based on what these devices can do.” Now it feels like that skill set is in place and people have learned how to do that.

The apps that are coming out now are just way, way ahead of what we had even a year or two ago. I think that’s great for everybody, because, like you say, it raises the bar for the industry. But I also feel like now it’s the start of this truly mobile set of services and applications as opposed to things in which they’re trying to figure mobile out or trying to retrofit themselves into a mobile use case when they didn’t have one from the beginning.

Jared: It feels like where we are now is at this really neat turning point in that we’re going to get a chance over the next few years to really invent a new vocabulary of what you can and can’t do in mobile. That’s not even including the hardware we haven’t seen yet. That’s just dealing with the rich capabilities of the devices that we have now.

Luke: Right, exactly. People will raise this stuff, “Well, now you’ve got 50 percent of people in the US have a smartphone and 30 percent globally. Isn’t this mobile thing starting to play out?” Again, I thought, “Well, no, it just feels like we’re getting going.”

A, 30 percent globally, that’s a small number, relative to who you can reach, and then, B, as you were describing, right now, the toolkit’s in place, the ideas are there, and the thing that’s changed is now we have examples. Now we have proofs out there of people doing this stuff and being successful with it. You start to build on top of that. The foundation’s there. Now we can actually start building.

Jared: When you were building Polar, I remember seeing some of the early stuff, and it was dead simple, and you were just getting it out there and having people play with it. You built it very incrementally. You didn’t try and come out with this very rich set of functionality in the first release. You tried one thing and then you tried something else. Was that frustrating, to take all that time, or was it energizing?

Luke: Couple of things in play with that. A, the way we released the app was pretty measured. What we did in the first iteration is we put it out to tens of users. Whenever we put it in TestFlight, it got 40, 50 people in there, learned a bunch of things, made some changes. Then we didn’t really launch it, but we put it out.

It’s got a couple people in there, so we got to the hundreds. So it wasn’t really a launch, but we were testing the waters at a different scale. Instead of tens of people, we got to hundreds of people. Again, we learned some things, made some changes. Then we did our actual launch, got to the thousands level, learned some things, made some very quick and, in some cases, tough changes, and now we’re moving to that next level and doing that same level of iteration.

I really like that process because I think you learn different things each time you make that order-of-magnitude jump. It’s a totally different experience when there’s 10 people, then 100, then there’s 1,000, there’s 10,000, and onward and upward. That process I actually like.

The other piece to that question that you raised, in my mind, is things that look simple on the surface, I think that’s a real big deception, because in order to make something very simple and clear and focused, like there’s so much stuff going on on the back end.

In fact, Anthony Kosner at “Forbes” wrote this great little article, and I applaud him for getting at the stuff that’s going on behind the scenes with our app, because he titled the article, “Polar: A Simple App that Shows…” I think it was like, “how much actually goes into making a simple app.”

Jared: Yeah, yeah. I like that article.

Luke: He outlined all the stuff that we’d been doing, and that actually has a big impact. When you drill into that, you realize, it seems super-simple upfront, but man, it takes a lot to get there, right? I appreciated his perspective on that.

Jared: What surprised you, that didn’t quite work out the way you expected?

Luke: There’s one thing that we did that I think is still a failure and we need to address it. Similar to that Google Maps example I was telling you earlier, where they don’t have any menus, right? They make the map the UI.

We have, in our interface, it’s a photo kind of a voting interface. We didn’t really put any buttons that say “vote,” and we don’t have any calls to actions and “vote on this thing.” Instead, we want people to interact with the content, touch the picture or touch the side that you want to vote for.

When you do it once, then you get it and you get going. But what happens when people share these polls out on the Web, we get feedback that’s like, “Well, I didn’t know that I could vote. There wasn’t anything that told me I could vote.” While we have this dream of “Let’s make the content the UI,” or “Let’s get rid of this chrome. Let’s not have buttons. Let’s not have instructions in our interfaces,” there’s still this real-world reality check, that when somebody sees something in a browser and there isn’t a control there, they get paralyzed.

Many of them get over the hump and they click or tap or whatever, and they figure it out instantly, right? But they still need that first, initial push of either directions or an explicit control to interact with stuff. There’s probably similar things going on in the Google Maps app for iOS, because there’s a lot of things that are hidden.

Ironically, somebody actually made a poll on Polar that was like, “Have you found the 3D mode yet? Do you know how to activate it?” [laughs] It was a poll like, “Have you found the hidden gesture-based feature inside the Google Maps app?” We haven’t hit that point yet where people are just comfortable with, “Oh, everything’s part of the UI,” which I’d love to get to.

Jared: Yeah. When things are hidden like that, you run into the problem that I’ve been calling “socially transmitted functionality,” where the only way you can learn about something is by actually clicking on it, or hearing about it from someone else to know that you’re supposed to click on it. A lot of the “pull to refresh” or “this magic swipe at this particular moment” is how you learn how to do that.

The funny thing is, I’ve been watching people do this, and it’s like, “I can’t figure out a way to delete things from my address book.” “Oh, you just swipe across and you press delete.” It’s like, “How did you figure that out?” “I don’t know, somebody showed me.” It goes on and on.

Luke: We get that stuff all the time. I started developing little hacks around it. I’ve actually written these two things up. I’ll give you two examples. One of the things we have in Polar is pull-to-refresh to get the results list to download. What we did there is we teased a little bit of an image when you actually pulled on the screen, so it looks like something’s happening. It’s actually the bottom of a bear’s butt.

[laughter]

Luke: As you keep pulling and pulling, you start to see that this bear is hanging onto another bear by his shorts, and that bear’s hanging onto the rim of the top of the screen, and as you pull-pull-pull-pull-pull, more of that picture gets revealed to you. It’s actually your socially- transmitted functionality thing, taken to the level of, “OK, we want you to socially transmit it.”

What we’ve seen with that is we actually have people making polls saying, “Have you seen the full bears picture yet? Have you kept pulling to refresh so that you can see the whole thing?” It got people talking about it.

Another example that we do is we have this create a poll where you enter text at the top for what question you’re asking, and the keyboard comes up. For a long time, people were asking us, “How do I make the keyboard go away? How do I make the keyboard go away?” Certainly, you can just swipe down across the screen and the keyboard goes down. But, again, hidden.

What we ended up doing is, when the keyboard comes up — there’s a profile picture up at the top — we replace your profile picture with a “keyboard down” icon. It slides up as the keyboard slides up. You hit it and then the keyboard slides down.

I bring that up as an example of a just-in-time action, right? Shouldn’t be there at all times, but when the keyboard’s up, we’re going to show it to you really quickly and give you a way to get out of there. It’s not that that control is always on the interface. It just appears when it’s relevant, to make these hidden gestures more visible to you directly.

Jared: This is very cool. I can’t wait to see how you are taking the lessons from the stuff that you’ve been talking about so much and put it in and start publishing what you’ve been learning, because I think that it’s great that you’re using this as a laboratory for your own techniques and your own methods and then can turn around and talk about what’s working and what’s not for you, and then people can try it out themselves. You are a good man, Mr. Wroblewski.

Luke: [laughs]

Thanks. I’d like to put that on the tombstone if I ever get one. That’ll work out nice.

Jared: Yes, yes.

[laughs]

Thanks for taking the time to talk to us today.

Luke: Thank you, sir.

Jared: Excellent. I want to thank our audience again for spending the time listening to us. Hey, if you get a chance and you’re listening to us on the iTunes, please, by all means, take a moment and fill out the little rating on the iTunes, because that really does actually help us get feedback on what we should do better and can do all sorts of things. We pay attention to that.

You can check out Luke Wroblewski. Of course, he’s written the fabulous book “Mobile First” and “Web Form Design,” but he’s also going to be speaking at the UX Immersion Mobile Conference, which is going to be April 22nd through 24th in Seattle, Washington. He’s going to give a full-day workshop there on designing mobile input, and we’ll talk to you there. It would be awesome to see you there.

Thank you very much for coming and listening to us today, and as always, thank you for encouraging our behavior. We’ll talk to you soon.

In part 2 of of our 2 part series, you’ll learn how to explain the benefits of attending the UX Immersion Mobile Conference to your boss. Part one outlined the expenses associated with sending you to the conference.

Understand what your boss wants

Before you present anything, find out what information your boss needs to say, “yes, you must go to this conference.” Often at the top of the list is cost and benefits to the company. Dive deeper – ask what they mean by benefiting the company. Is your boss asking to see:

1. How you’ll solve a specific pain point within your organization?
2. How the material you learn will help finish up a current project?
3. How this new information is shared with the rest of the team?
4. How your new-found mobile UX knowledge saves the company from hiring someone to do a specific task or skill?
5. Will you bring in a new skill set that the company is lacking?
6. How are you adding to the basic UX knowledge of the team?

Addressing Your Design Needs

Only you know which workshops will address your most pressing design needs. The UX Immersion workshop descriptions lay out what you’ll learn during the day, the practical take-aways you’ll get, and how to implement the new processes and techniques you’ll learn.

Explore the workshops that fit your training and design needs. Find 3-5 points within the workshop description that addresses the 6 questions above.

Training others

One of the best methods to reinforce a new skill is to train someone else. We call it the “watch one, do one, show one method.”

In the daylong workshops, you’ll learn by “watching” and “doing.” Then, once you’re back in the office, you’ll “show one” by teaching the rest of the team the fabulous material from the workshops.

To help with the sharing/showing, you’ll receive audio and video recordings of the short talks plus all the materials from every workshop and talk. These items are included as part of your registration.

Increasing your value to the organization

Most organizations care about, and invest in, their employees, wanting them to have the skills and tools necessary to succeed. Amping up your UX knowledge makes you a better designer and a more valuable and productive employee.

Conferences are an opportunity for you to glean best practices and network with others facing the same challenges. You’ll gain more than you can get from simply reading articles or books.

In Summary, Provide a Benefits Worksheet

It’s difficult to put an exact figure on the ROI for attending the UX Immersion Conference. Your boss will want something that quickly quantifies benefits and shows what the costs are. Here’s an example.

As an added incentive, tell your boss you can save $200 if you register by February 28 with the promotion code BLOG.

In this first post of our 2 part series, we’ll cover cost.

There’s no way around it, conferences can be expensive. Your boss wants to know what it costs to attend and not just the registration fee.

Breakdown of prices

We summarize this information in a table at the bottom.

Registration – The current price is $1,689. But if you use the promotion code BLOG you’ll get a $200 discount. The next price jump goes to $1,989 starting March 15.

Hotel arrangements – We’ve secured a special group rate of $189.00/night plus tax at the Renaissance Seattle hotel. This is the conference hotel, so by staying here, you’ll avoid daily transportation costs.

There are other hotels in the surrounding area at lower prices. Explore additional options at Hotels.com or Orbitz.com. Be aware that hotel rooms booked on these sites may not refund you if you cancel. Also keep in mind that some of these hotels will not be within walking distance.

Flights – Flight cost varies depending on day of week, location, and number of stops. Flying out of a major hub typically gives you more airlines, times, and non-stop options. However, non-stop flights are often more expensive.

Save yourself money by looking into flights that have a stop. If possible, look at flights that have you leaving on a Saturday. Often flights and hotels are cheaper when there’s a Saturday night stay involved. You may actually save yourself money by coming a day early, and Seattle is a fun city to explore.

Do your homework and use sites like Hipmunk or Kayak to compare flights.

Transportation to and from Seattle airport – There are several ways to get to the conference hotel from the airport. Going by taxi will cost the most with the estimated cost of $40-45 each way.

A shared van service typically costs $19 one way, however anticipate having to stop at a few locations before you get to your destination. It’s not necessary to make reservations in advance from the airport.

The least expensive option is the Light Rail, Seattle’s subway line. This option will leave you 1/4 of mile from the hotel.

Food – Your conference registration includes breakfast all three days, mid-morning and mid-afternoon snack and beverage breaks, lunch on Tuesday, and a reception with food on Tuesday evening. You’re on your own for lunch on Monday and Wednesday plus all your dinners during the conference.

Expect to spend an average of $8-12 for lunch and $12-20 for dinner.

Summary of expenses

Here’s a chart with your average expenses. The hotel cost is for the Renaissance Seattle Hotel.

Ideas to save on some expenses

There are a few ways to save some money.

1. Book your flight at least 6 weeks prior to the conference. The closer you get to the date of the conference, the higher the flight costs.

2. Use public transportation. Use the extra money you save towards food.

3. Share a hotel room

4. Be sure to register with the promotion code BLOG and save the $200.00. And register by March 15 before the rate increase.

Read part 2 – Part 2: Convincing Your Boss – Selling UX Immersion’s Benefits

Here’s an excerpt from the article

This year, it will be hard to find an organization that doesn’t prioritize making their web site responsive. Yet, as we talk to organizations moving in this direction, we’re finding they haven’t nailed down their strategy for getting there yet.

The Core Tactics

Almost everything you read about responsive web design starts with what I call the core tactics — the basic elements that make responsive sites be responsive. You can’t ignore these, they form the basis of the overall strategy.

The first core tactic is discovering the breakpoints. These are the page widths that will cause design elements to re-order. In between breakpoints, items will change their size or flow, but at the breakpoints, you’ll see a sudden change in configurations.

Read the article: Devising a Strategy for Responsive Design.

Moving to Responsive Design?

The UX Immersion Mobile conference, April 22–24, in Seattle WA, has full-day workshops to make sure you get your strategy right. Jason Grigsby will show you everything you need to ensure you’ve got your core tactics in place. Karen McGrane will dive deep into creating a content strategy specifically for mobile. See the full program at UXIM.co.

What are your strategies for preparing a responsive design? Tell us about it below.

UI17 OnDemand brings you the skills you need to keep up with the latest tools, techniques, and processes to deliver the best user experience possible.

You’ll hear from these UX experts:

Luke Wroblewski – First Person User Interfaces
Remove distractions from UI’s and create immersive experiences.

Kevin Hoffman – Designing Stellar Meetings
Run meetings that result in better insights and bring teams together.

Kim Goodwin – Your Toughest Design Challenge
Use specific strategies to become a masterful change agent.

Aaron Gustafson – Building Adaptive Designs Now
Learn techniques to design adaptive, multi-device experiences effectively.

Dana Chisnell – Three Levels of Happy Design
Shift your thinking to start designing for emotion.

Nathan Curtis – Fearless Prototyping for Skeptics
Use HTML to prototype or sketch out your ideas.

Adam Connor and Aaron Irizarry – Discussing Design
Improve how you collect, deliver, and receive critiques.

Karen McGrane – Adapting Ourselves to Adaptive Content
Create a more flexible content workflow.

Purchase the recordings for $189 until February 21. After the 21st the price goes up $50.

Here’s an excerpt from the article

Our best chance for establishing trust with our users is to be honest. After all, trust inspires confidence. And it’s confidence—not just a knowledge of differences—that compels decision-making.

Perhaps we should stop fixating on what makes us different and, instead, acknowledge the real aspects of who we are, what we do, and why people choose us.

How can we start getting real?

Read the article: Being Real Builds Trust.

Build Trust With Your Users

On February 14, in her seminar Building Trust with Your Users through Messaging & Copy, Stephanie Hay is going to show you how to take cues from online and offline interactions to write candid content, craft helpful user experiences, and maintain users’ confidence even when you “fail.”

How does your copy install trust and inspire confidence with your users? Tell us about it below.

Mobile changes everything about how we conduct usability research. Not only has the way we design and build websites and apps had to adapt, how we study them has to as well. Traditional research methods won’t translate to a mobile environment.

Cyd Harrell, formerly of Bolt | Peters, has been conducting mobile usability tests. The problem with traditional usability testing labs for mobile is that the users aren’t in their normal context of use. There’s this awkward interaction of holding the device in the right position, or operating while it’s attached to a sled or rig. Observing this unnatural interaction won’t give you the greatest results.

The context of use paradigm is only one important aspect. If you and your designers are all iPhone users, for instance, thinking of things in terms of iOS is natural. With the variety of operating systems on these devices, testing your app in the right context as far as both the user and device are concerned can be a challenge.

Cyd is presenting one of the daylong workshops at the UX Immersion Mobile conference April 22-24 in Seattle. For more information about Cyd’s and the other workshops, visit uxim.co.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello there, everyone. It’s another episode of the SpoolCast here. I’m Jared Spool. I have today with me the amazing Cyd Harrell.

Cyd, up until very recently, was the VP of research for the UX design firm based in San Francisco called Bolt | Peters. Then suddenly they got sucked into the great Facebook acquisition vacuum cleaner.

Cyd’s miraculously escaped and is out doing all sorts of good for the world and sharing with us her expertise in usability testing, in particular, around that of mobile usability testing, which is exactly what we’re going to talk to her about today.

Hi, Cyd. How are you?

Cyd Harrell: Hi, Jared. I’m great. How are you?

Jared: I am doing fabulous. It’s a great day here.

Mobile usability testing. This requires a lot of hardware, now, doesn’t it?

Cyd: It can. I think that there’s a little bit of a perception that it requires more than it in fact does, because there’s an idea that if we’re going with the traditional lab model, and we want to take perfect videos and we want to get every single mobile device that our audience might use all lined up in the lab, then pretty soon, we are indeed talking about 20 pieces of hardware in addition to what we’d normally have for a test.

But there are ways to do it that minimize that a little bit, and there are ways to do it without adding on too much hardware at all. If you think a little bit more about how you might do a guerilla research study or how you might do a study in a home or even how you might do a remote study, which is just starting to become possible with some of the new developments. It’s pretty exciting what’s going on these days.

Jared: Let’s talk about this. If I was doing this in a lab, do I need to retrofit the lab with special cameras to capture things and stuff like that or are there tricks to this?

Cyd: There are some tricks. A lot of people will retrofit the lab by adding sleds for particular devices. I don’t think you need to. In fact, my favorite way to set up the lab for a lab mobile study is to have the participant sit in a comfortable armchair and place a little target on the arm of whichever hand they’re most comfortable using. Then have an over-the-shoulder camera, which can be something as simple as a flip or one of the small video cameras on a little boom that can focus on the mobile screen.

Then if you just do a little bit of tweaking to make sure that if it’s either a device you’re providing you can set the brightness so that it’s easy for the camera to catch it or that if the participant’s bringing it in, you just take that moment at the beginning to get it set right. You can get a really nice video without ten extra pieces of equipment.

Jared: That’s interesting, because I’ve gone to presentations and stuff. They’re always talking about molding these little plastic sled things that you mount the camera on and you mount the phone on. Or you have to have the phone, like they tape a little box on the table and the phone has to stay in the box so that the camera can hit it and stuff.

But you’re just doing this in a comfy chair.

Cyd: I think it’s better in a comfy chair, just because the participant is more comfortable. You can still have a target area on the arm of the comfy chair, but rather than necessarily laying the phone down, you can figure out in your pre-flight, which I certainly hope anybody does for a study, what’s the approximate angle that a couple different people hold their phone at. You can set up the boom so that you just need to do a little tweak to the angle as each person comes in and you’re good to go.

I do think sleds can be useful if you want someone to walk around in a lab environment, but they are hard to use out in a real world environment, which is, of course, the other environment where we really want to see people doing mobile testing because of the in-context nature of mobile use.

Jared: Now you’ve done some out in the field studies, right?

Cyd: Oh, yes.

Jared: What’s that like with the mobile stuff?

Cyd: It’s incredible fun, because you really can get embedded in peoples’ lives. It can be crazy technology-wise. I’ll tell you that the first mobile study I ever did was probably the most technically complex, but in some ways one of the most interesting. This was at Bolt | Peters, and one of the major car manufacturers wanted to create a concept car for the 2009 Geneva auto show that would take account of the way that drivers use mobile devices in their cars.

They asked us to do some ethnographic research on how people use various devices, including phones, iPods, and anything else that people actually happen to use. We proposed that we would actually accompany participants on trips that they planned to take for reasons of their own. Because of the location of the car company that was sponsoring this, we needed to broadcast it to a couple of different countries in real time so that they could send in questions.

This became quite an adventure, but it worked really well. We had a camera person along taking high-res video, and then we had a researcher with a laptop who also rode along and used the webcam on their laptop together with one of those Sprint devices that lets you connect pretty well from anywhere.

These days you’d use WiFi probably or something like that, but that was what was available at the time.

We got some incredibly rich information from seeing–I’m going to laugh for a minute here, because one of the things that people do tend to lie about is things they’re not supposed to do–like the way that they might use devices in a car.

By being there on trips that people actually cared about, they were going to pick up their kids. They were going to shop at the mall, they were going to take their dog to the dog park, perhaps. We could see what their real environment was like. We could see how did they manage with the dog in the car? Was it really true that they would never text while the care was moving? Not true for most people.

Jared: You were doing this in California?

Cyd: Yes.

Jared: Is it illegal to text in California?

Cyd: It wasn’t at the time.

Jared: OK. It is now, so if you were to do this, you’d actually have video evidence.

Cyd: Yeah. We have quite a consent form on this.

Jared: [laughs]

I bet you do.

Cyd: Yeah. But, you know, the interesting thing about this being the first mobile study that I did made the technical complexities of my future mobile studies really seem minor.

Jared: There’s a good recommendation. You just make your first one the most complicated one you’ll ever have to do, and it will make every other study seem so much easier.

Cyd: I think that once you sit down to technically plan something…The really tricky element there was the fact that we were broadcasting. If we had just been recording it it would have been significantly simpler.

But we did the same thing a number of other times with things like in-store walk-arounds, where we had a client who had an app that they wanted to enhance the in-store shopping experience. There really wasn’t any way to get at that besides actually going to the store and walking around with people and their phones. We set up something very similar, although we were able to take advantage of in-store WiFi that they had to make the broadcast a little more stable.

For me, I don’t feel like we have to start with the assumption that in-context mobile research isn’t possible. If we’re choosing to do it in a lab, then we should do that for good reasons. There are excellent ways to set that up, too. But it shouldn’t just be a choice because we assume that we can’t max out the realism of our research scenarios.

Jared: It feels almost like the lab is not necessarily the first choice for doing the research in a lot of these projects. That and the fact because doing them in context is not that much more difficult, we should be strongly considering that as we’re doing the studies.

Cyd: I think we should. I strongly encourage people to do it. Again, live broadcast is a complexity, but if you’re not doing live broadcast, you have a lot of ways that you can be with someone.

The other, bigger challenge in some ways is if what you’re studying is studying is an episodic activity, so it’s not something where a person walks into the store and then they might be using the app during a half-hour activity. If it’s something like checking directions that they might do throughout the day, it’s a lot harder to arrange and pay the incentives and make things work with a full-day session with a person.

What interests me with that is we’re getting better and better options for putting together sets of tools that can let us do things like diary studies or experience sampling studies using people’s mobile phones as essentially the research platform.

Sometimes, obviously, we’re talking today mainly about instances where the mobile phone is also the topic of the research, but it’s also possible to do it for completely different topics, where they might be doing an activity episodically that’s not specific to their mobile phone.

Jared: Say a little bit more about that.

Cyd: Well, there’s a famous example, actually, from back in 2008, which was called the “Happiness Project,” which I suspect a few of your listeners might have signed up for. It was a graduate student at Harvard who decided to survey people’s happiness and try to understand what activities actually make people happy and don’t. He set up a really fun incentive for this. He said, “If you participate in my project for two weeks, I’ll send you a graph of your happiness.”

The way that the study was engineered was you’d receive a text on your iPhone. This, of course, was on second generation iPhones, the 3Gs mainly and some of the first generation ones. When you receive the text, you are supposed to respond to a survey in a mobile website that asks, “What are you doing? Who are you with? And how happy are you right at the moment?”

Jared: I think I saw a TED talk on this.

Cyd: Yeah. It was a really interesting study model. The unfortunate thing was that with the iPhones of the time, filling out a mobile survey was enormously painful. You know, it was really hard to get through the survey that was only supposed to take 30 seconds, so a lot of people dropped before two weeks.

They ended up getting a lot of good data, I think, but now, in 2012 and heading into 2013, there are some really exciting developments in terms of mobile storytelling and mobile survey and mobile form creation applications, where you can really create a pretty pleasant experience for your participants of taking part in your research.

Jared: This gives us an opportunity to use mobile as a research tool to study things that are much broader than the phone itself. Like if I was trying to figure out when people are needing, for instance, my company’s intranet, I could have employees collect that data on the phone throughout the day in a diary-like study.

Cyd: Very much so, yes. I have heard of people…This is at the stage right now where a lot of researchers are duct taping together their own. There’s one platform that’s really designed for this which is e-Scout. They have a great team over there, and the app is developing along.

But I have heard of people using Survey Gizmo. I have used Blurb Mobile myself. There is a really nice new web and mobile form generation product that’s going into beta called “Typeform” that I haven’t seen yet, but I’m really excited about. It’s possible by the time we talk in April that it may be out. Things are really moving fast. That’s one thing in this space.

Jared: How did you find yourself, you know, doing a lot of mobile stuff? Was it just the projects just kept coming in, or were you guys pushing that as an expertise thing, or what was it that got you? Because at Bolt | Peters, you and the rest of the team there were doing some of the most advanced stuff I’d seen.

Cyd: Well, thank you, and, you know, it started out client-driven. The study that I described a little earlier was one of the first requests we got, and then we felt like it was part of who we were and what we were excited about to be able to, basically, take research technology limitations off the table, something that we did in our game research, and in our web research, and all of the development of things for remote research.

We started to get excited about mobile because of that because we wanted to push ourselves in a direction that people were thinking of exactly the way you mentioned at the beginning where, “Oh, no, this is a scary technical area.” It was always our answer to that at Bolt | Peters to say, “No, it’s not. Grab your duct tape and let’s do this.”

Jared: Is that approach of just challenging yourself to say, “Look. These things we believe are restrictions don’t necessarily have to be,” is that something you find yourself coaching other folks to think in terms of?

Cyd: I do, often. In fact, I’ve done a lot of coaching the last two years with Code For America fellows who are largely wonderful and technically-inclined people, but I think that as we think about research there are certain classical methods, and there are a lot of places that teach methods or techniques more than they teach theory and practice, if that makes sense if methods and techniques are a little different than theory and practice.

The most important practices of research are the design of research and asking the right questions and setting aside the technical limitations until you figure out what the right questions are and then seeing what you can put other to get those right questions answered.

That really is where I’m excited about the potential of mobile to let us answer some of those in-context questions about mobile behavior itself, which is, of course, one of the new things over the last few years that we’re all seeing a lot of, but also about other human behaviors.

Jared: I think this is really cool, this idea that mobile is a research tool in addition to just figuring out how to evaluate designs that we might be putting on the devices themselves. Have you been doing work that is looking at the questions of the apps that I’m building, let’s say, for mobile, “The apps that I’m building for mobile, are they a good idea versus have I got all the details right, right?”

It’s sort of a different process when you’re just looking at “Well, what ideas should we be focusing on?” versus, “Is this design we’ve come up with the best design we could have?”

Cyd: Yes, I think it’s really important to do that. I think there are a lot of clients right now who are concerned that they might be behind in mobile or concerned with competitive pressures in mobile and so who are developing an app. You know that’s really a choice now. That’s one strategy.

There are really good ways to build mobile websites that are not apps, as well. There are more strategic choices that need to be made, and there needs to be a reason to make any given one. Like any research you need to understand if you’re solving a real problem with something that you’re building.

There are a lot of interesting ways to do early prototyping on mobile. Mobile phones have nice photo capabilities so some of the simplest things are putting screenshots into a sequence much like you might do a click-through prototype for early testing on web or a desktop app.

I’ve seen a very cute paradigm where someone used regular-sized Post-It notes, which are about the width of an Android phone, which they had done nice sketches on and used that as a true paper prototype on a mobile setting so the person could demonstrate what they would do, and then they could peel off the Post-It note to get to the next “screen.”

So there are all kinds of methods to do what we would think of as kind of prototype concepts level tests, and then there is also just understanding the behaviors that people do with their phones, which where we started out with the concept car study was looking at that.

If I’m in my car, and I’m driving my dog to the dog park, what’s important for me to have within arm’s reach? What are the things that I either have taped together a way to do while I’m in the capabilities, or find that I can’t do and get irritated about, or never need to do? So that then they can take that and understand what capabilities they might want to provide in a very futuristic car that would serve people who are connected all the time.

Jared: Well, I think this is cool, this idea that you can do future-thinking prototyping, and idea generation, and even just sort of seeing the context that people have today and collect that data, and then at the same time go back and try out a design and try a prototype at various levels of fidelity, whether it’s a paper prototype that’s low fidelity or moving towards more higher fidelity screenshots.

Is there something that you think is still too difficult to do on mobile that you wish was a lot easier than it is right now?

Cyd: That’s a great question. I think that one thing that stumps a lot of teams is dealing with the proliferation of mobile devices and the different operating systems, and it’s easy to get in a bubble there. If you and your team are all iPhone people, then you can look at everything in iOS and consider it.

If you are dealing with the Android market there’s, of course, many, many different handsets, and there’s still, I think, a lot of question around…Some of them are almost sort of persona style questions, “Is there an android type user who is different from in iOS type of user who might be different from a Windows eight type of user?”

I think that that just plethora of platforms, to be a little bit alliterative, is something that we have some ways to deal with, but it doesn’t feel easy.

Jared: Yeah, I mean, I saw pictures that Facebook has posters up all over their offices. They’re paying employees a reward if they start using an Android phone so they can test the Android Facebook app, because I guess at some point they gave all the employees iPhones, and so now everybody’s got an iPhone and nobody has an Android phone.

So they’re resorting to paying people about to get this to happen so they can use it themselves. It would seem to me that’s problematic, plus do you have to worry about the different operating systems that Android runs on? I’m an iPhone guy so I actually know very little about Android so is it the case that the various…They’re all named after things I’d rather be eating.

Cyd: Absolutely.

Jared: Ice Cream Sandwich and Gingerbread House, and Peking Duck. I don’t know exactly what they are.

Cyd: I think that there are some differences in how things run on the operating systems, but that is going to get into the detail level when you’re really talking about usability and testing, which, obviously, is something that you should do as well as high-level in-context research.

The ways that people solve that question…There are a few firms out there that specialize in helping with specifically that testing in operating systems at the end. There’s one in San Francisco called OTIVO. There is an online crowdsourcing company called Mob4Hire that basically has a panel that has a broad diversity of different kinds of devices and operating systems.

What’s interesting to me about that…I’m not normally a big fan of panels. I think that for deeper research, you don’t want a lot of them, but just in terms of penetration of “Can I see someone use it on this operating system?” I think they might be onto something there.

I think, in general, if you are looking at behavior questions, they’re probably… [laughs] In some ways, even though I’ve done a bunch of these studies, I don’t feel like I have enough data yet in my layers of personal data to say, but I don’t feel like you need to account for five different Android operating systems in most user-research study designs.

It’s often a good idea to look at iPhone and Android. Of course, you want to consider, some people put tablet in with mobile research, some people don’t at this point, but it’s another platform that may be of interest.

Another thing, actually, that I would bring up is that once your app gets to a beta or even an alpha stage, there are starting to be platforms through which you can distribute it out to users and collect data on what they do with it.

I am beta-testing, actually, a civic app right now via a system called Test Flight that installs unfinished apps onto people’s mobile phones bypassing the app store so they can be tested. There’s another thing just for iOS called Delight.io that, I believe in that case, your app still goes through the app store. It’s for post release.

It’s an open question and apps make it more interesting, but much like we don’t test a website on a Mac and a PC and a Linux machine necessarily these days. If we are just doing usability research I think that you can restrict a little bit what you do. I think you can comfortably say, “I’m going to choose iOS. I’m going to choose an Android operating system that I have in the lab, or I’m going to allow users to use their own phones and I’m just going to record what they have.”

I think that’s part of what people feel overwhelmed by, honestly, is the notion that there are all these phones and, in addition, there are all the technical complexities of cameras and maybe, as you say, molded pieces of plastic and sleds and, “Oh, gosh. I’m not sure this is worth it.”

Jared: Yeah. It sounds like the fear of this is really just in our heads and that we just have to get over it and go off and do it and realize how easy it is.

Cyd: It’s easy, and furthermore, it’s really fun. A lot of the times when we’re talking about researching behavior on a computer we’re talking about a person sitting at a desk, but when we are research behavior on mobile we can be researching someone interacting with a city or interacting with a retail experience or a whole other range of human experiences.

I think it’s fun and I think getting over the technical hurdle can be fun if you enjoy duct tape, which I think most people should.

Jared: Yeah, I don’t get as much opportunity to enjoy duct tape in my life as I would like.

Cyd: That may be a little bit of my Bolt | Peters history sneaking back in there.

Jared: Well Cyd, thank you so much for taking time to talk to us about this. I’m really looking forward to your workshop at the conference. I think it’s going to be really cool because you’re going to give folks a chance to see what all the different pieces are, including how you use mobile technologies to research things that are beyond just what happens on the phone or on the tablet, right?

Cyd: Absolutely. Yes, I’m planning to do some work with walk-arounds and some exercises around how to get out in the world. I’m super excited for that, too.

Jared: Fabulous. Cyd’s going to be giving this full-day workshop on using mobile technology for usability research, “Conducting Usability Research for Mobile Apps,” we’re calling it, at the UX Immersion conference, April 22nd through 24th in Seattle, Washington.

We’ve already started seeing a lot of people register. Folks are signing up for Cyd’s session. It’s going to be great. If you’re interested, you want to get in there because I’m going to bet it’s probably going to sell out.

Cyd, thanks for taking the time today.

Cyd: Absolutely my pleasure.

Jared: I want to thank the audience one more time for listening in. As always, we love having you here. If you have a chance, please go to iTunes, if that’s how you download your podcasts, and just give us a little rating and let us know how you think about all these things that we’ve put together. We love the ratings and they help us make this better. We love to see what you have to say.

Thank you for listening to another episode of the “Spoolcast.” As always, thank you very much for encouraging our behavior. Take care. We’ll talk to you next time.

Here’s an excerpt from the article

Sketches enable us to quickly depict and share ideas with each other, but are also considered disposable. Sketches represent an intermittent state leading to something better, more refined. As artifacts, they are fleeting renditions of the concept, a point in time idea dismissed into the (ideally recyclable) waste baskets of sketching sessions and desktop brainstorming.

We may find ourselves amid the next hour’s design studio summation. Or the day’s prototyping. Or the next week’s task scoping. Or the next quarter’s project proposal. But the sketch’s value extends beyond the initial presentation and discussion.

As such, we’ve adopted techniques for organizing our sketches for future reference, even into the annals of antiquity!

Read the article: 6 Tips for Organizing Sketched Artifacts.

Learn More

Want to learn more about how to capitalize on the productive power of sketching? Join us on January 17, when Nathan presents Sketching for Understanding. Nathan will lead you through the processes, people, and purposes behind different types of sketches.

How have you organized your archive of sketches? Tell us about it below.

The ultimate goal for user experience is that users enjoy using your product or service. Many companies use satisfaction as a metric for measuring their success. But satisfaction is really just the lack of frustration. You should be focused on what you can do to delight your users.

In his virtual seminar, Jared presents the Kano Model. The Kano Model helps you gauge your users’ expectations. When you approach delight from a perspective of pleasure, flow, and meaning, you can then determine which features meet these objectives.

The audience asked a bunch of great questions during the live seminar. In this podcast, Jared joins Adam Churchill to revisit some of those questions, as well as tackle ones we weren’t able to get to.

• Is consistency in design a bad thing?
• What research methods are there to unearth customer expectations?
• How can you meet customer expectations on a new product?
• Do you plot different audience segments in the same model?
• What if the people selecting the product are not the users?

Recorded: November, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this fall, our own Jared Spool presented a fantastic virtual seminar. It was called “Building a Winning UX Strategy from the Kano Model.” This seminar, along with over 100 others that teach you the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library.

In this seminar, Jared tells us about a tool teams use to make design decisions. The Kano model focuses on users’ basic expectations first. It predicts the investment a team needs to make to elicit delight from users. In this seminar, Jared talks about how your competitors, existing design debt, and the evolution of ideas, from innovation to market maturity, all affect how you need to design today.

Hey, Jared. Thanks for taking some more time to talk about this useful design tool.

Jared Spool: Well, thank you. I’m happy to be here.

Adam: For those that weren’t with us that day, can you give us an overview of the seminar?

Jared: Yeah. I talked about this simple little model that was invented by a Japanese dude, a guy named Noriaki Kano, that helps us predict what users can expect in terms of satisfaction based on the investment that the team makes. It basically helps map the types of investment that you get, and it helps us understand whether the design is going to come out delighting users or it’s going to come out frustrating users, and when it comes out frustrating users, where we might have missed in our investments.

It turns out that there’s three curves in this model that make the most difference. The first one is what was called the performance payoff. The performance payoff is a straight feature-building model where you just keep adding features, and the more features you add, the more payoff you get.

The second curve we call basic expectations, and that curve talks about how, as you increase the amount of investment to meet basic expectations, these are things that the users just naturally expect, they don’t get very excited about. They’re features that every product in the genre has to have. The amount of investment that you get as a result of basic expectations is going to be limited in terms of the satisfaction it will generate, because you can’t get above neutral satisfaction by meeting a basic expectation. All you can do is frustrate.

And then, finally, we talked about excitement generators. Excitement generators are things that often take a little bit of investment but, in fact, are the delighters that we hunt for, and how the more you invest in these things, the more likely you’ll delight folks, but that those delightfulness things are often short-lived, because once your competitors do it and everybody else in the market does it, they shift their way down to basic expectations, and suddenly you’re back in the game where you have to hunt for delighters and you’re not making people happy with just the basic things again.

It turns out that these three curves help us understand why users get frustrated when they do and why they get delighted when they do and what we have to do to make things right. That was the shortest version of that presentation I’ve ever given.

Adam: Very good. Well, as always, we had some fantastic questions from our audience, and as is often the case, we didn’t get to all of them, so let’s tackle some of them. One of the things that came up in a bunch of questions, and there was even some reference to it on the Twitter stream. You talked about consistency and made it sound, in a lot of cases, like a bad thing. Can you talk a bit about that?

Jared: Yeah. It’s not a bad thing. Being consistent’s not a bad thing. Focusing on consistency from a design perspective is not a good thing. The difference is, it’s how you approach the problem, right? I don’t think anybody argues that if you use a term in one part of the interface, you might want to use that same term in another part of the interface. That is what we often think about when we think about things like consistency.

But once you start to go down the road and say, “Well, things need to be consistent with everything else,” it becomes really problematic, because you’re constantly designing to draw from things that you don’t necessarily know that the user is actually paying attention to and users don’t care if things are consistent with things they’re not paying attention to. They only care when it’s consistent in a way that they expect. The key word there is actually “expect,” not “consistent.” The trick is not that you want to make things consistent. The trick is that you want to meet user expectations.

Let’s take the idea of a term, right? On many Windows interfaces, if we were to have a function that would let me send to the printer the document that I’m working on, Adam, where would you expect that function to be located?

Adam: In the File menu?

Jared: In the File menu. OK. What would you expect that to be called?

Adam: “Print.”

Jared: “Print.” OK. If we called it something else or we put it someplace else, we’re going to piss a lot of users off, right? But that’s because that’s what users expect, and they expect that because people who use Windows have used a lot of Windows applications and every other Windows application puts it there. But if you think about it, under File, Print makes no sense whatsoever.

Print makes even less sense if the application is, let’s say, some sort of database app, where the screen I have currently up is a data record–not the whole file, but just one record within the file–and I hit Print, and all I want to do is print that one record. Let’s say it’s a contact record, so I want to print the name and the phone number and the person’s email address, right?

Why is it under File? If all I want to do is print a single contact in my contact database, wouldn’t it be better to be under Contact? But everybody expects it under File, so we should probably put it under File. But the only reason they expect it under File is because of years of training that Microsoft has done and all the other Microsoft apps, that Print is always under File.

This is going for expectations. If you say, “Well, we’re just going to make things consistent, so we’re always going to put things where they are in other things, or we’re always going to label them the same way as they’re labeled other places,” but we don’t pay attention to what users do and don’t expect, things will start to break.

The trick is to follow the expectations, to go after what users are expecting, to say, “OK, what I want to do is really understand who my users are and what their expectations are. Do they expect the print command to be under File, or do they expect a big button on the screen to say ‘Print,’ or do they expect it to say something else?”

For things that are not frequent–print is a frequent function–but say we want to email this record so that it shows up in your version of your contact database. Do we call it “synchronize”? Do we call it “email”? Do we call it “make synchronization record”? Now we have to figure out, “What do users think? How do they think about this function? How do they approach it?” and talk to them about what they’re actually doing, and then give it a name that matches their expectations, which may or may not be the same name we would’ve given it someplace else. That’s the trick.

Expectations is very user-focused. It’s focused on what the users think, whereas consistency is very system-focused. It’s focused on the system we’re building. When we’re always given a choice between doing something that’s user-focused versus system-focused, most of the time we want to opt for user-focused, because that will create the best experiences. That’s why I say that designing for consistency is not the right thing, but designing for expectations is the right thing.

Adam: Let’s stay on this theme of customer expectations. The team at Work at Play wants to know about some more research methods that might be available and particularly good for unearthing customer expectations.

Jared: All of the standard research practices work here. I mentioned in the seminar that field studies, going out into the field, are a great way to look for basic expectations in particular. They teach you what users are currently doing and how they do them, so you can then see, “Well, OK, these people are heavy Excel users, so they’re going to expect things to work like Excel when we’re dealing with Excel-like things.” We can start to look at those mappings and those things and work from there.

We use field studies to do that. We also use the field studies to identify the excitement generators, because, oftentimes, when we’re in the field, we can see what we call tool time. Tool time is time that the user spends working on something that doesn’t really give them any significant improvement in the outcome or the quality, but just ends up taking time.

For example, imagine an application that a system administrator uses where they have to set up a new record for a new user in whatever the application is. They have to create the user’s record, and then they have to go and put in various preferences. They have to put in their access rights. They have to change their permissions. They have to do these things.

If you put all those things on separate screens and you make the system admin jump from screen to screen to screen, identify which user each time and then set the settings, and then go to another screen, identify the user and set the settings, and do that six different times, and potentially forget to do one and then realize that he forgot to do one so he has to go back and change it again, all of that is tool time, right?

If you can put that all on one screen and eliminate that tool time, that’s an excitement generator for that experienced person, because suddenly it’s like, “Oh my gosh! Everything I want is here. I can, in one thing, go click-click-click, and I’m done and it’s perfect.” Maybe smart defaults would help there.

These are things that you can discover when you go out and do field studies, because you see that movement where they do six different things, and you say, “We can combine that into a single, one-minute activity and be done with it.” Field studies are a really important method for going out and discovering this stuff.

Another one is to look at different ways that the organization currently gets feedback. The most common way, of course, is customer support. In customer support, you have people calling up and asking, “How do I do X?”

Well, some of those things that they’re asking are things that they want to know and it’s just not obvious. That’s an opportunity to make it more obvious. That’s a way to delight customers by making these things such as you don’t have to call to figure out how to do them.

Another thing is, people are calling up and asking for things that you can’t do with the application. In some of those cases, those are going to be basic expectations that you’re missing. You want to ask the question, “Should we have that basic expectation in the application?” The answer isn’t always “yes.” Just because someone asks for it doesn’t mean you should do it.

The fact is that they’re calling support and asking, “Well, how do I get headers and footers on this printout?” You might want to start asking the question, “Why do people want headers and footers? What are they doing with this output that they think they need to have a header and a footer on it?” That will help you understand whether you’ve missed a basic expectation or not. That’s a key piece of it.

The last thing is that there’s a variety of lab techniques that you can use to look for things that are delighters and expectations, but primarily basic expectations. The first one that I like to use is something called interview-based tasks.

This is when we don’t necessarily give the user an assigned task off the bat. We don’t say, “Can you pretend that you are interested in finding out where the company headquarters is located and go look and tell me where the headquarters are located?” That’s what we call a scavenger hunt task.

What we want to do instead is interview the participant in the study, so we interview them for a few moments to find out, “So, tell me about the last time you needed to contact someone in your database? What was that like? Who did you have to contact and what did you have to do? Were they already in the database or did you have to add them into the database?”

You start asking all sorts of questions about this last experience. Then you have the task that you have them do in the test. You basically have them replicate what it was that they just asked you to do.

By doing this, you’re using their terms and their ideas and you get to see things. What happens is the types of things they show you are problems that would emerge that don’t emerge when you create the task yourself and ask the participant to do that task the way you want it done because they’re going to create all sorts of little pieces to the puzzle that are asking the user to do things they way they want it done. All of a sudden, you’re gong to discover missing expectations that should be there, that are getting you in trouble and you don’t even know it.

Adam: That suggestion to use customer support is an interesting one. I suspect the trick there is to avoid that common trap of trying to be all things to all people.

Jared: Yeah, so that’s true with any of these things. You have to sit back and ask yourself the question of “What is it that this person is trying to do?” It’s not even trying to be all things to all people, but taking things at face value.

When someone calls up and they’re asking about the question of “How do we get headers and footers into this thing?” It’s like, “OK, well we could implement headers and footers.” That’s sort of an understood technology, lots of applications do it.

The real question is, “What is the person doing with this printout that they actually want headers and footers for? What is the problem that headers and footers are solving that you’re not solving in the application already?” That’s the really interesting question.

That’s the point where you want to take a moment and actually see what they’re doing. Go out and visit them and see the way that they currently are using this and discover that maybe headers and footers is just a hack that they thought of to solve a problem where the problem is something different.

They need to have these things individually labeled so that they can stick them in a filing system so they can find them later, or some other thing that frankly, if you knew the bigger problem, the computer could probably come up with a better solution than adding headers and footers. You want to really go explore what the user’s trying to do and that’s really key there.

Adam: What about with a new product or service? The CBC asks this and wants to know how do you get to meet the expectations when your users may not have fully-formed expectations?

Jared: They almost never have fully-formed expectations. Expectations are often things that they can’t talk about. For example, imagine Adam, that you and I were going to open up a new hotel. In this new hotel, we’re going to put in hotel rooms that are really comfortable, really useful.

We ask our customers, what do you want in a comfortable, useful hotel room? They might tell us things like, “Well, I want the bed to be really soft and I want the television to be really nice. I wouldn’t mind if there was a glass of wine waiting for me in my room when I got out of my business day and maybe the coffee was waiting for me outside the door.”

They could tell you all sorts of really neat little things like that. I’m going to bet though, they’ll never say, “Oh, and I want to make sure the shower has hot water.” Yet, if you don’t provide the shower with hot water, you’re probably going to piss off every customer. It doesn’t matter if there’s a glass of wine waiting for them if you don’t have hot water in the shower.

Most basic expectations, you can’t just go and ask. You have to explore. You have to spend time actually watching and listening and seeing how things are there. The thing about things that haven’t been built today is that even the things that haven’t been built today almost always are solving a problem that people already have.

Problems have been around for a really long time and people don’t change that much. The example that I like to use, I ask people this, and I don’t think I ever asked you this, Adam. Do you know when the first fax machine was invented?

Adam: Oh gosh, no. I mean, I would probably guess in the ’60s at some point?

Jared: That’s interesting, a lot of people guess that. It turns out that it was a fax machine that actually helped the FBI get Al Capone because they faxed his fingerprint record, so they actually had it in the ’30s. It was also heavily used in World War II.

It’s a very expensive technology back then. Both sides had to have these very expensive pieces of equipment and they had to match up exactly. The ones that they used in the ’30s were over telegraph wire. It turns out that the first fax machine was like in the 1870s.

Adam: Wow.

Jared: OK? If you think about it, all the fax does is it gets a message from one place to another. The problem of getting a message from one place to another, that pre-dates the 1870s by a lot.

Adam: Sure does.

Jared: We’re talking the Greeks were worrying about getting messages back and forth, and the Egyptians. The fax is just a new solution to an old problem. For us, it’s not even that new anymore. In the total scope of the problem, it’s actually relatively new.

Chances are, whatever problem you’re building to, it’s been around for a really, really long time. You’re just coming up with a new way to solve it. What you really want to do is figure out how people are solving it today, because chances are, that problem isn’t going unsolved. There are very few things that we design today that are for unsolved problems. They are solved in some form or other. They’re just more clumsy than the way you’re hoping it will happen.

You need to just spend time looking at how people do things today. If it’s really that brand new, then there aren’t that many expectations. You’ve got this nice green field. You can build it however you want.

When Twitter came out, there weren’t a whole lot of expectations around Twitter. But it had a completely different set of challenges, because without any expectations, people don’t come to the design knowing anything, so now you have to explain to them why they use it and how they use it. Think about those early days of Twitter when everybody just had no clue what they were supposed to do with it or why.

That creates a whole new design problem. If you don’t have expectations already, that actually doesn’t make your life any easier. [laughs] It just changes the dimension of the problem. I always get worried if people are telling me that they don’t think that their users have any expectations, because that means that they are in for a hell of a ride. [laughs]

Adam: So, hotels. Our friends at Marriott ask a question about…Their line of questioning, there were some questions they had during the seminar, that they were actually thinking about how to use this model, and this particular question I thought was interesting. If you have a different audience or different audience segments that show variations in their expectations, do you try and plot those in the same model, or do you separate them out?

Jared: Well, the model is really for the design, so to separate them out gets you into trouble. But if you have folks who have wildly different expectations–and more importantly, conflicting expectations, expectations where they believe that one group of users will expect a feature to be a particular way and another group of users will expect it to never be that way and will be upset when it’s that way–you’ve got a problem, right? You have to map those expectations out and figure out, who’s going to be upset when this thing is missing?

I guess you could draw different sets of expectations for different groups of users for the same product. But really, the idea here is, I don’t see teams drawing these models very often. The model helps explain what we’re seeing, but the model itself, I haven’t seen much practical use in the act of producing the product, in other words, sitting there and saying, “OK, this feature is currently sitting at this point on the model and that’s why it’s where it’s at.” I think just dividing the features up into basic expectations or just feature growth or excitement generators is a useful exercise, but plotting them on the graph, per se, is not that useful, so I don’t think you need to do that.

But this gets to a bigger question, which is, are you designing for user populations that have radically different sets of expectations? If you do, you might consider creating separate designs for them, right?

I can see, for example, designs for corporate travel agents, people who are booking dozens of hotel rooms simultaneously, all the time, day in and day out. I can see their expectations being very different than the casual vacationer, or even the semi-frequent business traveler who books their own travel. I’m not sure that you’d want to try and build one interface for all of those folks, but instead, maybe come up with a way to build separate interfaces for each of them to match each of their separate expectations and delighters.

That would make life a lot simpler on the design side. Of course, it makes it a lot more difficult on the execution and maintenance side. Design is always about trade-off. The question is, how much do you break these things out? I think that you want to at least look at that and see how that plays.

Adam: Jared, how about in corporate environments where the people who are selecting a product or a service are not actually the people that are using it?

Jared: Yeah. This happens a lot in companies, right? Where people are getting an application, say an SAP or an Oracle, or performance-review system or an expense-reporting system or a time-clock system like Kronos, and they need to use this. There’s a team out there who’s trying to make the best of it, but the features and functionality are being determined by other people.

In some cases, features are added because it makes the HR department or the accounting department’s job easier, but it doesn’t at all make the job of the person who has to enter the data easier, and so the system is there.

The thing here is that you’ve got a couple of different things that are happening simultaneously. One is that you have to ask the question, right? The Kano model predicts delighters. It predicts what’s going to delight people. But is it the end users, the people who are entering the data, that you have to delight, or is it the people who are choosing the system that you have to delight?

As we talked about before, if you end up in this situation where, to delight one group but not the other is a trade-off you have to make, you may go after the money side of the equation, the people who are buying this thing, and not go after the user side of the equation, the people who are using this thing, and therefore they’re going to be frustrated.

What you can do is you can spend time looking at what these people are trying to do, what the users are trying to do with it, and look for basic expectations and places where you can make them happy. But it’s always a hard sell because, frankly, if they have to use it, then you don’t have to make any investment whatsoever.

The place where the cost comes in, which people don’t often take into account, is the quality of the resulting data. That’s probably where you want to go with this, is to look at not just the money that gets invested in changing the design, but the money that’s invested as a result of really bad data that comes out of the system.

Imagine an expense reporting system, where the accounting department doesn’t get what they need in order to get the expenses right. They, therefore, are rejecting a lot of things, and people have to do it again. Morale is now lowered, which causes other performance problems throughout the organization.

If you can start to factor all of those costs and start to look at why all of those things are causing problems, now you have a different formula for that investment side of the Kano model, and you can map that to satisfaction, and it will probably tell you quite a bit.

If you just try and go with the dollars, the end users aren’t investing any dollars in the product at all. The developers are. But the developers are answering to the people who are making the product choices, and they’re delighted by just having this. They’re not going to see why spending money to make it easier for the end users to enter this data is going to pay off if they’re already getting the data they want to get. You have to prove to them, “OK, what happens when the data they want to get isn’t the data they want to get?”

That’s really where you have to go. It’s a complicated answer and it’s not simple, because it’s not a simple scenario. It’s a complex space, this idea that the people who pay for it are not the people who use it. The people who use it don’t get a say in what’s going to make them delightful, and that’s where you get into trouble.

I hope that helps answer the question.

Adam: It did for me. I’ve been in that world, so I know how it can get disjointed.

Jared, this was great. Thanks for joining us.

Jared: Thanks for having me. It’s nice to sit on this side of the microphone for once. [laughs]

Adam: And to our friends listening in, thanks for your support of the UIE virtual seminars. Goodbye for now.

In Sketching for Understanding, Nathan Curtis of EightShapes will lead you through the processes, people, and purposes behind different types of sketches. Whether you’re trying to sell your ideas, crystallize disparate discussions, or engage remote teams in UX decision-making, you’ll be glad you’ve got Nathan—and loads of new sketching exercises—on your side.

In the seminar, you’ll learn to:

• Sketch with purpose
• Sketch within large teams
• Sketch with remote teams

So if you’re just learning about sketches or looking to capitalize on more of their productive power, this seminar should be on your calendar.

Sign-up Once. Pay Once. All live seminars January through June, 2013.

All 10 live seminars, plus their recording links – $1,149

We have some great presenters and topics lined up for you. With these educational events on your team’s calendar, you’re sure to maximize your core knowledge and skills.

Here’s an excerpt from the article

The concept was a dramatic shift from anything prototyped, discussed, or even sketched during the studio. It was safe to say: the client had never seen this before. To introduce this idea at this stage risked shaking things up and requiring yet another presentation that convened the stakeholders.

As the flourish concluded, we had to make a decision: do we share this idea, risk the implications that we start prototyping again from scratch, and have to “re-sell” an idea, again? Or, do we play it safe, stick with concepts everyone already knew?

With sketching, we could propose both.

Read the article: The Power of Sketches: How We Sold a Huge Project Shift with 5 Index Cards.

Learn More

Want to learn more about how to capitalize on the productive power of sketching? Join us on January 17, when Nathan presents Sketching for Understanding. Nathan will lead you through the processes, people, and purposes behind different types of sketches.

How have you used sketches and prototypes to sell your concepts? Tell us about it below.

Responsive web design allows the notion of “one web” to be a reality. Designers are increasingly able to sell to their organization the idea of delivering content to multiple platforms. Putting it into practice is another story.

Jason Grigsby, co-founder of Cloud Four, says that it is easier to sell the idea of responsive web design than to do it well. Simply shifting the layout of your design to fit different screen widths is only half of the battle. Page weight is another consideration.

A huge part of mobile experience is performance. Though connectivity speeds are increasing on mobile, shrinking your desktop site to fit on a mobile screen isn’t the best option. Jason says that this is an often overlooked aspect of responsive design. Most of the concern is around how a site renders on various devices, but the importance should fall on the entire experience.

Jason is presenting one of the daylong workshops at the UX Immersion conference, April 22-24 in Seattle. This year’s conference features 6 experts covering various aspects of mobile design. For more information on Jason’s and the other 5 workshops, visit uxim.co.

As always, we love to hear what you’re thinking. Share your thoughts in our comments section.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Hello, everybody. Welcome to yet another episode of the SpoolCast. I know you’re going to be very excited today. I know I’m very excited. If I’m excited, I’m thinking you’re excited because we’ve got the amazing Jason Grigsby here.

Jason co-founded Cloud Four, which is the fabulous mobile design and development agency and has sort of become the center of the “How do the hell do you get this responsive design thing done?” world. He is speaking for us at the upcoming UX Immersion conference, which is going to be in Seattle April 22nd through 24th.

I’m very excited that we have a chance here, right now, at this very moment, to talk to Jason about just this stuff. Jason, how the hell are you?

Jason Grigsby: I’m doing well, Jared. How are you?

Jared: I am doing fabulous.

Here’s the deal. I’m seeing everywhere people are buying into this responsive design thing. It’s like the Gangnam Style of the web. Everybody is buying into this thing. They are selling it to their boss. They sell it and they sell it and they sell it and the boss finally goes, “OK. I get it. We have to make everything work on all these different devices. Everything’s got to get big and small and do all this stuff.”

The boss says, “I’ve got it. Give me something in five months. Go.”

And then all these people go, “Oh my God. What the hell did I just get myself into?” Because, as I understand it, it’s easier to sell responsive design than do responsive design. Have I got that right?

Jason: I think that it’s easier to sell than to do it well is the way that I would describe it.

Jared: What does not doing it well look like?

Jason: There’s a few different ways. I think the most prominent way is when I did a survey in 2010, I went to the Media Queries gallery, which is a bunch of responsive designs and looked at them. I found over 80 percent of the sites were built in a fashion that the mobile version of the site, essentially what you would see, or mobile screen size of the responsive design, was the same size or larger in total page weight as the desktop version.

The same thing was true of a study that Guy Podjarny did this year. He looked at 347 sites and he found that only three percent of them were significantly smaller on small screens. You would expect it to be much smaller.

What’s happening is, is that people are basically just taking their desktop site, adding some media queries to it, and shoving it onto the small screen. What you end up with is something that looks OK for mobile but is…

For example, Disney just did a responsive design. Their responsive design looks great. It’s 4.5 MB on an iPhone, which is far, far too big, even if somebody’s on WiFi. It’s just way, way too big. And it doesn’t need to be that big. If it was built properly, it would be much smaller.

I think that’s the part about doing it well that people really miss. We know statistically that they miss it, because the vast majority of sites are built that way.

Then there’s a bunch of stuff that gets hard with infrastructure and decisions and changing your process. I think that there are pieces of it that are hard, just generally doing a responsive design and bringing responsive design into an organization.

Then I think that there’s a whole area of responsive design that most people aren’t focused on, but that is actually critical if you’re going to actually build something that is fast and responsible and people have a good experience. It doesn’t just look good, but it actually feels good.

Jared: This is shocking to me because the whole idea of getting stuff for mobile was to get it so it works well on mobile. If the performance is slow because the page sizes are too big, that’s a step backwards.

Jason: That’s an interesting…Is it really a step backwards? I think…I read a blog post a little while ago that said that number one thing that you could do to make your site optimized for mobile is to make it faster. The point that I was making was that most of the modern smartphones actually have really good capabilities for displaying a desktop site and allowing somebody to tap in to read text or pinch and zoom to zoom in to read areas of the page.

It’s not as nice as if the page is designed correctly for mobile but you can get around on a desktop site without too much trouble. There are gestures to support being able to read desktop content on a mobile phone. There’s no gesture that any user can do that will make the thing load faster. The only gesture they’re going to give you is a single finger up in the air as they run away from your site.

The whole idea of building something that looks good but actually takes too long to load and so nobody actually bothers to visit it is, I think, really problematic. I don’t know whether it’s a step back because these sites are too slow now. They’re slow but they look good on the sites on the phone so it’s, I guess, a little bit of a step forward but it’s not doing it well. I think we could all agree on that.

Jared: Yeah. Is the strategy, you think, to get a slow responsive site first and then make it fast or should we be thinking about speed up front?

There’s an old saying in the programming world which is you don’t optimize code that doesn’t work yet. But are there things we understand how to do to get faster code sooner? Does that make sense?

Jason: Yeah. I would say that it’s not that doing things in a way that implementing it is incredibly difficult. It’s just not what most people first do when they start doing responsive design.

The primary way to actually make things fast on responsive is to do mobile first responsive web design, which means…Luke Wroblewski has taught about mobile first from a design perspective. In that, he’s talking about the constraints of small screens enabling better design.

What I’m talking about isn’t that, although it borrows that name. What I’m talking about is actually technical implementation. It means reordering your style sheets so that the styles are based on the screen size and go from small to large. You can use the cascade of CSS to progressively enhance the page from the small screen to the large screen.

When you do that, you run into some challenges that you don’t run into if you just throw media queries at the end of your style sheet to make things look mobile. That’s where some of the tricks come in and where people start running into problems with, say, responsive images or retina displays or IE before 9, because IE before nine didn’t support media queries.

These are all things that I guess, with the exception of responsive images, which we’re actively working on with the W3C and the web WG. The rest of them are sort of known solutions, they’re best practices on how to solve these things. It’s just that overall awareness of them is lower than I think they need to be, or than it should be.

Jared: This is good news then. There are things we know how to do to get the page size down and be able to get these responsive sites to literally be more responsive, because they’re faster, because they load faster and people can work with them.

Jason: Correct, correct. Yeah, a couple years ago, when Ethan wrote his piece on responsive design, I was looking at the problem and basically nobody had really worked out how to do this stuff. At the time, it was like, yeah, responsive design may make sense in some cases, but you should be really, really hesitant of it because of these issues.

Fundamentally, if you have a site that looks good but it’s so slow that nobody visits it, you’re not going to accomplish your goals, you’re not going to solve things. I mean, every single study we’ve ever seen says that performance matters in major ways to conversion in UX and perception and all of these different things.

In the last, I would say that since that time, two years from now, we’ve reached a point where we view responsive design as the default approach in our project. We basically looking for reasons why we might not be able to do it.

We hope we don’t bump into them, but sometimes there are organizational issues. Maybe the current system is too complicated to do responsive design and so they’re going to do device detection and do responsive design on the mobile version of their site and hopefully eventually replace their desktop version with that mobile version. By mobile, they’re doing responsive design on that.

Those are cases where responsive design can’t be done or can only be done in conjunction with device detection. Other than those times, we start from the premise of, we can do responsive design and we can do it in a way that’s fast and looks great. Then only use these other tools if we need to use them.

We’ve come a long ways in that two-year period.

Jared: How did you get started in all this? What sort of got you in the center of this world?

Jason: We’d been doing a lot of mobile related stuff and had been, like everybody who did mobile web, responsive design before media queries became popular, we had been doing them using device detection.

The first time I saw a site that was doing responsive design was before Ethan had coined that term. Somebody brought it to us because it was really slow on mobile. Basically, what I found was that there were Google maps embedded in the site that didn’t show up on mobile. But that Google maps code resulted in, I don’t know, it was somewhere like 40 to 60 different files getting downloaded.

Jared: Oh, wow.

Jason: Yeah, all these images. I mean, it completely bloated the page. But it didn’t even show up. That sort of alerted me to this issue.

Then, last year, my co-founder, Lyza and I, we wrote “Head First Mobile Web.” When I had published my article talking about the performance issues with media queries, the response that everybody said was, OK, Jason’s right. This is a big problem. But all we need to do is do mobile first responsive design.

So, when we were outlining the book, we said, OK, well, chapter one will be responsive design and chapter two will be mobile first responsive design. We’ll go figure out what people are doing for mobile first responsive design and we’ll just write it up, right? Easy enough.

Then, we found out that nobody was doing it. [laughter] Which meant, essentially, that we ended up having to plow through a bunch of research. Everything from responsive images to techniques for doing progressive enhancement from small screens up to large screens in order to be able to complete the outline that we had committed to.

And I’m really glad we did. I think that that research, particularly the research on images has turned out to be pivotal to the work that’s being done now by others to redefine HTML to support responsive images. But it was sort of inadvertent. We just didn’t know what we were getting ourselves into is really what it amounts to.

Jared: Yeah, that’s a common story that we hear. That people just suddenly that they’re in the middle of this stuff and they sort of back into it, not knowing. So I’m really interested in what’s going on with responsive images. Help me understand the problem. So the problem started with the fact that different screens have different resolutions, right? And now with things like retina displays the resolutions could be wildly different, right?

So that means an image that has got a small number of pixels in it might look good on a small screen with a small resolution, but you then blow it up on a big screen and it looks like crap. And similarly, an image with a lot of resolution looks great on that big screen or that high resolution retina display, but suddenly I’m now downloading all of this weight and then have the local processor shop most those pixels out to be able to display that image.

Jason: Correct. Yeah.

Jared: So how is this possibly solvable? I mean, either I’ve got high res, or I’ve got low res. I mean, what’s the ideal future for this? That somehow or another the image is smart? Or that the server technology knows what it’s talking to? Or is this handled all on the client but with some sort of wacky ass compression?

Jason: [laughs] So when it comes to CSS, we’re in a reasonably good spot. So CSS background images, you can define different sizes for everything based on screen resolution, screen width, or pixel density, or any of those sorts of things. So on the CSS side, we’re actually in really good shape. It’s actually just in HTML that we have the big issue, which is we’ve got an image tag that only has one source. And there’s really no way around that. So the long-term picture is we either need changes to the mark up in some fashion, or we need a new image format. People point to something like JPEG2000 which allows progressive downloads.

So the same file could be used and the client would only grab what’s necessary. So a phone might grab the first 30K of an image and that’s all it needs to display this image on its device. But a large retina screen, iMac, might grab might be grab 200K or something like that. Those file formats are theoretically possible. From a practical perspective, there are a lot of reasons why that doesn’t seem to be where we’re headed.

The cynical version of this is that there are patents involved and nobody seems to be able to agree on a format. And that’s essentially problematic. It’s great to say that we should have this magical format that works this way and that everybody should adopt it, but if there’s no political will to do so from the browser makers then it doesn’t really matter. The second issue is that the big problem that we have, and this is going to be a little technical, probably even a little bit more technical than I might talk about in a workshop or something like that.

But the big conflict between the image and the browser is that the browser wants to do what they call the look ahead prefecture, which is it will start downloading assets in the web page before it’s figured out what the layout is going to be. And the problem is that even if we had this magical image format, in my dream world what we’d have is this magical image format and I would upload the highest resolution version of the image that I have.

Because I don’t know in the future if I might use it at a larger resolution or something like that. So I’m going to upload the highest resolution I have. Now, what could happen is say it’s a small image being used on a large screen. What the browser wants to do is it wants to use the size of the screen, the size of the view port really, as indicative of how much of the image it should download because it doesn’t know at the time it starts downloading images what size the image is actually used on the page.

And so what you could end up with is a really, really large download for an image that’s being used as a small piece of the page. So we run into what I think of as the conflict between the person who likes to travel and schedule everything. I know exactly where we’re going to be and what we’re going to do, versus the person who goes on that trip that’s like, yeah, I don’t want to have anything planned. It’s that fundamental conflict between the web developers who really want to be able to define what this experience is going to be and what size file and all this stuff and the browser that’s like, I’ll deal with that later. I’m just going to start grabbing stuff.

Jared: I know exactly what you mean. I used to travel with this coworker and we’d go on these three or four day trips. And she couldn’t decide what clothes she wanted to wear in advance, so she would bring her entire wardrobe. So I’d have this tiny little bag that the exact number of shirts and pants and maybe one extra of everything and she would bring two bags of suitcases because she’d just basically take everything with her. And then she would decide and she would wear one tenth of it. And so it would take her forever to unpack and pack. It was crazy to travel with her.

Jason: [laughs] Yeah. So we’ve got this fundamental conflict. Whenever people propose solutions to the problem, they end up bumping up against that. And I don’t know what the end solution is going to be. What we do and what we’re recommending for others is there’s some techniques that avoid these problems and allow you to define different size images for different size view ports.

And we basically say, hey, this is what you should use now. This works. It’ll allow you to have a web page that performs well. And you should make sure that whatever you do, however you solve this problem, and there are a couple of different techniques to do this, that you’ve built it in a way that you can replace it two years from now. Because I don’t know what the solution is going to be, but I know that whatever you’re implementing now is not what’s going to be there two years from now.

And so if we know that that’s the case, we should plan for the fact that it’s going to be deprecated and then plan around it. And I think these are the sorts of challenges that happen when responsive design hits the real world. It’s the same sort of thing when organizations realize, hey, our existing content management system is really problematic for us. Or our waterfall design process isn’t going to work in a world in which we need to make multiple design decisions as we’re adjusting to screen resolution as we’re resizing our browser.

The designers aren’t going to design the entire design across that whole continuum. They need to be working together with developers, and that means a change in our process. And these are the sorts of challenges that people run into when they actually get to that point where the boss is like, “Yes! You must have this site up in five months.”

Jared: Right. The other thing that somebody asked me about the other day, and I didn’t know where we were with this. Is responsive design still really only good for content sites? Or can we start to get into web-based applications and make it work there?

Jason: I’ve got a blog post coming on this, Jared. It’s been permeating like all my mind for two or three months now. And I just need to sit down at some point and write it down. So I’ll give you the short version of this. We had a client who asked us to help with sort of taking their whole infrastructure and making the transition to responsive design. Part of it was that they had some applications and those applications were using UI frameworks, Kendo UI and a precursor to that.

The thing that they had, though, is they basically had these desktop apps. I’m like, we need to figure out how to make this work. I spent a couple hours looking at this and trying to figure out how to take their desktop application and make it work responsively.

After sort of banging my head on the desk for a couple hours, I stopped and said, “OK, forget this, I’m just going to figure out what it would look like if I did mobile.” Once I did that, it became really apparent how the responsive design would work up to desktop.

The other piece that this process made me realize was, the Kendo UI folks have this interesting blog post where they talk about how they feel like tablet UI is so fundamentally different than phone UI that you can’t just do a phone UI and have it work for tablet or vice versa.

I read the post and that line really struck me because the Samsung Galaxy Note II is a five-inch display device. That’s a phone. We have tablets that are seven-inch devices. Is there really that much difference between a five-inch phone and a seven-inch tablet? Does anyone think that across the continuum of things that we’re not going to get a six-inch tablet or a six-inch phone? That we’re going to continue to have this gap there?

The whole idea, then, that somehow a tablet design is fundamentally different between seven inches and five inches is crazy.

If you take that and you start extrapolating from that, then you start looking at the fact that tablets are now going from seven inches to 13 inches. We’ve got these Windows eight devices that have touch in the laptops and have detachable keyboards. They’re like tablets/laptops. Where does the continuum stop?

If you’re building a desktop app, and you’re doing a web-based version of it, it could be used on a Microsoft Surface device, which is touch enabled and becomes a tablet. If you’re not building it responsively, how in the world are you making a decision about what is desktop and what is tablet, or what is tablet and what is phone? There are no lines anymore.

When people are building applications, yeah, it’s harder to do responsive than it is to do segmented versions of it. I just don’t believe that, I believe that you’re going to have an unsolvable problem of segmenting device classes.

If that becomes true, then given the choice between the impossible task, like just mathematically proof impossible task of defining differences between these device classes and building something that’s responsive. I’m going to take the challenge of building it responsively versus trying to prove a negative sort of math level, not possible, where do these lines end up?

Jared: I mean, because you have to draw the lines in so many different places, right? Because there’s definitely, if you’re working on an 11 inch tablet, the larger iPad, for example. The ergonomics of typing are very different than typing on an iPhone and very different than typing on a desktop with a keyboard. I haven’t tried the Surface yet, so I don’t know what that typing experience is like.

You’ve got some fundamental ergonomics for just typing right there. I would think that because an iPhone in portrait has such a restrictive width and an iPad in landscape, particularly with Retina, has such a broad width that there are things in layout and things you can do in design that you can’t get away with the same in both places, right? You’ve got more to work with in one and a more constrained resource in the other.

Then the question becomes, I think, if I’m hearing you right, what you’re saying is you have to look at this on an app by app basis and say, “At what point does it make sense to start interacting differently based on what your data and what your app needs and less about what the physical device is?”

Jason: I think what you touched on is actually the key, which is a lot of what people talk about in the differences, and they talk about, “Hey, we’re going to do something that’s for desktop because somebody sitting at a keyboard and mouse is doing input differently.”

The first piece is that that is no longer true. Somebody sitting at a laptop that’s a Windows eight laptop has a touch screen. They may be trying to hit those targets that you’ve defined and were thinking of somebody hitting with this really tiny pointer with their fat finger. This was something that Josh Clark has written about and that Luke has been talking about. They’re right on. Touch is the baseline experience because touch goes across all the device classes.

If you build something with touch in mind where the targets are larger and it’s easier to hit, because if it’s law, it’s going to be easier to hit with a mouse, too.

From a design perspective, I think that that informs us to say, “Hey. It’s not that we’re going to be designing differently for one category of devices versus another. We are going to be designing differently, but we should be designing for touch across that whole spectrum,” which is a change.

Then I think that the big challenge, and particularly for web developers, is to try to start thinking about input as progressive enhancement in that the presence of a physical keyboard, how do we support that keyboard in a better fashion if it’s present? Or how do we support input with the Kinect on Xbox, which now has Internet Explorer? Or a remote control when it comes to TV.

This is something Luke has been talking about for a while. His company’s all input factory and everything. I think that input is a bigger determinant of what we need to do with the interaction design of the things that we’re building than anything that we’re making decisions on based on form factors or screen size. I would state that it’s not solved by any extraction of the imagination.

But I do think that where we’re headed, clearly, is that even for applications, that responsive design is going to make sense because the ability of an individual application to predetermine what classes of devices are going to interact with it is just gone, fundamentally. Particularly from a web based perspective.

If you’re doing stuff natively, you probably have better control but web perspective, you cannot.

Jared: Yeah, my mind’s about to explode.

Jason: I’m sorry. I ranted on that.

Jared: No, but I think you’re absolutely right. This is just so complicated because I’m thinking of even little specific use cases. If I’m sitting at a desktop and I have a mouse and I select text, the browsers on the Mac, for example, can interact with that text. I can put a bold button in and it can then react to the selected text and bold it.

But on the iPhone, getting that selected region back to the app is actually really hard to do. Right? And so, now I can’t implement a bold function for selected text inside a paragraph. And, in fact, just the act of selecting text with a finger is ergonomically far more complicated than selecting text with a mouse.

Jason: But the thing is with selecting text, the thing that allows you to do that is…I hope that I’m remembering this correctly, but it’s content editable, is the…

Jared: The attribute.

Jason: Yeah. And you can client side test for content editable. If that’s a key piece then you need to be testing for the existence of that and either your baseline experience doesn’t assume that that exists and you’ve got other ways to get things done like type in the bold tag or sometimes maybe your baseline experience just absolutely requires it. You’ve built something using WebGL or something and you’re doing a game, in which case you progressively enhance from a web page that says, “Sorry, you need WebGL,” and then you feature attack for WebGL and then you build the whole thing.

I think that the reality is is that this stuff has always been out there. It’s always been a bit of an issue but the percentage of diversity was low enough that we thought that we could ignore these issues. Now it’s just…The diversity is right there staring us in the face and we just have to start building it in a way that…

I think that the big thing that Ethan did, even more so than defining the ways in which people do responsive design, was actually defining the mindset that we need to have as designers and developers to be responsive to the environment in which the user is interacting with what we’ve provided them. I think that that’s going to be true for apps and for content-based sites.

Jared: Yeah, I would agree with that. I think that responsive design is one of the biggest things to happen to UX in the last…In that it creates all of these questions and issues that we still are struggling to get good answers to but it is definitely the path of the future, I think.

Hey, Jason. Thank you so much for taking time today to blow up my brain in this new and novel way.

Jason: Well, one of these days I’ll actually get that blog post written and then, I’ll think, more clearly articulate what I’m trying to say here.

Jared: Well, good. We’ll have a nice transcript of this discussion for you to start with.

Jason: Excellent.

Jared: Thanks. It’s been wonderful.

Jason: Thank you.

Jared: I want to thank you, our lovely listener. Yes, you. The one sitting there with the headset on. Yep, that’s you. I want to thank you for taking the time today to listen to Jason and suffer through my silly questions as he gave brilliant answers.

If you have a moment and you listened to us by downloading the podcast from iTunes could you go to the iTunes and give us a rating and tell us how we’re doing? Because that really helps us. I would appreciate that.

Thank you again for encouraging our behavior and we’ll talk to you soon. Take care.

Daylong Workshops Are the Core of the Conference

We have a fantastic lineup of UX mobile experts. You’ll choose from 6 workshops all focused on improving your mobile UX design skills.

Luke Wroblewski – Designing Intuitive Mobile Inputs
Kelly Goto – Prototyping for Mobile Designs
Chris Risdon – Mapping Your Customer’s Journey
Karen McGrane – Adapting Your Content for Mobile
Cyd Harrell – Conducting Usability Research for Mobile
Jason Grigsby – When Responsive Design Meets the Real World

Save your spot today before the price goes up at UXIM.co.

Here’s an excerpt from the article

On the surface, this story was about a company using the inventions of another company without permission. Apple claimed — and the jury agreed — that Samsung violated some critical patents in the design of the iPhone. Samsung should’ve either paid Apple for the rights or come up with their own inventions.

Yet, just below the surface, the trial’s key message was how desirable a great experience is and what a company will do to achieve it. Samsung might’ve come up with a great experience on their own, but borrowing from the Apple iPhone experience was too good to pass up.

How good? The jury awarded Apple $1 billion. Ok, that’s pretty good.

Read the article: 3 Big UX Lessons Ripped from 2012 Tech Headlines.

See Jared in person

Jared is keynoting at this spring’s UX Immersion Mobile Conference in Seattle, WA. Three days that delivers in-depth full-day workshops on every important topic for mobile UX designers. Get the details at UXIM.co.

Which UX related news story grabbed your attention this year? Tell us about it below.

From the reasons why people pull out a mobile device to how we can lay out navigation options on small screens, Luke will detail mobile design thinking and solutions that will help you organize your Web sites and apps. You’ll see how to make your design remain future friendly as Luke shows you what’s coming next.

See what the web is uniquely good at and how to adjust your site’s content accordingly. You’ll explore the best way to place navigational elements, to ensure your design has great clarity and retains your users’ focus on their tasks. Luke will explore new techniques, such as responsive web design, for handling multi-device layout.

Join us on January 10 for Organizing Mobile Web Experiences with Luke Wroblewski. Register your team, or make this part of your 10-seminar package.

Navigating the Mobile Landscape
Luke Wroblewski

Mobile is the “hot topic” these days. It’s increasingly at the front of designers’ minds. In a world where the power and capabilities of the device in your pocket are so great, the possibilities become somewhat astounding. The mobile landscape is changing so rapidly that it makes developing a formal strategy to “figure mobile out” all but impossible. Luke discusses how taking advantage of the market as it is today and the capabilities of these devices can lead to the refinement and evolution of your product.

Listen to Luke’s podcast.

Mapping the User Experience
Chris Risdon

In the current multi-device, interconnected landscape, a user can interact with your product or service from a variety of touchpoints. At each, you must address the user’s needs at a particular place and time. Those needs will be determined by where they are in the experience.

Listen to Chris’s podcast.

Mobile-first Responsive Design
Jason Grigsby

Speed and performance are a critical aspect of mobile design. Using media queries to design your site responsively is a great way to ensure proper display on mobile devices. But just shrinking a desktop site to work on a mobile device can affect performance.

Listen to Jason’s podcast.

Designing Multi-Device User Experiences
Luke Wroblewski

Context is an important consideration in designing a mobile experience. As new devices enter the market, designers have to contend with new form factors and consider things such as ergonomics. Even things such as Apple’s retina displays affect approaches to design.

Listen to Luke’s podcast.

Content Strategy for Mobile
Karen McGrane

Your content is visible practically everywhere. Content strategists need to structure content to allow for viewing on an array of devices. What does that mean for your content management system? And what do you need to build into your content to make it flexible and adaptable?

Listen to Karen’s podcast.

Buttons are a Hack
Josh Clark

Touchscreen devices give you the ability to directly manipulate content. This allows designers to create interfaces where the content itself is the control. This lessens the need for buttons and can reduce the level of complexity within your design. The problem is making the user aware of the availability of gestures in your design. Gestures, especially multi-touch gestures, are powerful control mechanisms but useless if the users aren’t aware of them.

Listen to Josh’s podcast.

Adapting Your Designs with Progressive Enhancement
Aaron Gustafson

It’s difficult to predict how users will access your designs and your content. More and more, people are connecting to the internet through some sort of mobile device. Using the latest advances in HTML and CSS can leave aspects of your site incompatible with some browsers. How do you ensure that you’re providing a good experience to your users over a broad spectrum of scenarios?

Listen to Aaron’s podcast.

Innovative Mobile Intranet Design
James Robertson

With mobile, you simply can’t have as much content on your pages as you do on the desktop. Intranet access within enterprises is crucial and accessing it with mobile devices is beneficial. However, the vast amount of pages and content is cumbersome and impractical for a mobile setting. James Robertson asks, what are the few essential things users need while they are away from their desks?

Listen to Jeff’s podcast.

Creating Great Mobile User Experiences
Rachel Hinman

Mobile is greatly influencing the user experience community. It’s challenging traditional approaches to design, but also bringing with it a host of new opportunities. Being a user experience practitioner in this changing environment is a bit scary. Yet coupling existing skill sets with the constraints of designing in the mobile space makes for an exciting world full of possibility.

Listen to Rachel’s podcast.

Examining Mobile User Input
Luke Wroblewski

Touch screen devices are commonplace. It’s now expected that your mobile experience work as well as, if not better than, your desktop experience. With faster connection speeds, cameras, GPS, gyroscopes, and accelerometers, we can deliver information to users in new ways. But we can also receive information from them as well.

Listen to Luke’s podcast.

Discoverability in Designing for Touch
Josh Clark

While the traditional “mouse and cursor” interfaces are still in use, many of us are becoming familiar with touch-based interactions. The power and capabilities of mobile and tablet devices is growing. Often, these devices are the more convenient alternative for users to access your content. But beyond accessing your information, how are they interacting with your design?

Listen to Josh’s podcast.

Beyond Channels: Context Is King – A 2012 IA Summit Podcast
Emily Wengert

When smartphones and tablets first emerged, designers focused on channel differences like screen size in order to understand the basics in this new area. It’s time to set aside channel-centric planning and think of a user’s context first.

Listen to Emily’s podcast.

Looking to enhance your mobile UX design skill set?

Choose from six daylong mobile design workshops. You also attend a day of 90-minute talks. All at the UX Immersion Mobile Conference in Seattle, WA, April 22-24. Explore the conference topics at UXIM.co.

With so many teams and divisions within organizations, falling into a pattern of designing within your own silo is incredibly easy. Mobile teams are focused on the mobile products. Desktop teams are concerned with the desktop experience. But customers interact with your product or service from an increasing variety of touchpoints. They expect a seamless experience across channels and devices. This often is not the case.

Chris Risdon, Adaptive Path’s Lead Experience Designer, emphasizes that a customer’s journey is about their relationship with an organization, not these disparate experiences. Designing in silos creates an amnesiatic environment. Oftentimes, the different parts of an organization aren’t talking to each other, subjecting a user to redundant experiences. For example, when a customer repeats account or service information to a call center representative after having already entered it into an automated system.

Getting a diverse group involved to map the customer’s journey will lead to greater design collaboration. Chris says that the process of mapping the journey is ultimately more important than the artifact it creates. The process allows you to see how you fit into your customer’s life. You identify more about the context of use and how to effectively tell the story of the customer’s journey.

Chris is presenting one of the daylong workshops at the UX Immersion conference, April 22-24, 2013 in Seattle. This year’s conference features 6 experts covering various aspects of mobile design. For more information on Chris’ and the other 5 workshops, visit uxim.co.

As always, we love to hear what you’re thinking. Share your thoughts in our comments section.

Recorded: December, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Welcome, everyone. You are listening to yet another episode of the SpoolCast, and we’re very happy that you have joined us. I am Jared Spool. I’m your cruise director for the day. I have with me the amazing Mr. Chris Risdon, who works with the good folks over at Adaptive Path as a lead experience designer in Austin, and he is also going to be giving a fabulous workshop at the upcoming UX Immersion Conference that’s going to be in Seattle, April 22nd through 24th. He’s doing a session on integrating mobile into your customer’s journey, and we’re really excited to have him.

Chris, thanks for joining me today.

Chris Risdon: Hello, sir. Thank you. I really appreciate you having me.

Jared: I really appreciate you doing this.

You and I were talking when we were putting the program together, and you were explaining to me the sorts of things that people are running into. You talked about something that just sort of nailed what I’ve been dealing with, and I know a lot of our clients have been dealing with, which is this whole problem that we design in silos, that if I’m working on a mobile app, I’m so focused on my mobile app, I’m not thinking about all the things that that customer does with my organization before they get to my app and all the things they’re going to do after the app. That leads to problems, right?

Chris: Right. Yeah, I mean, there’s two things that are happening there. One is the experiential side of things for the customer or the end user, and the other is the organizational thing that’s happening with companies and their silos.

What we realized, as we were working more and more with mobile, to exactly what you said, is we know that context is really important to understand how to design for a good user experience. Mobile really brought that to the forefront, where all of a sudden context became so important, instead of knowing that, by and large, they might be in a coffee shop or on their desk, but they’re going to be on their laptop and they’re going to have a certain type of browser. It became easy to fill in the context of use for a lot of things that were more desktop, web applications. Mobile sort of turned that on its head and really showed how important context was.

We were realizing we couldn’t necessarily design for mobile in a vacuum. We had to consider it.

Then that second part is, again, to the point that you said, organizations tend to get really siloed, and often by channel. They have their web channel. They have their mobile channel. They have the people that are dealing with the retail or they’re dealing with the phone center. Yet siloing those and creating very disparate experiences often isn’t really the way people experience their journey with that product or service over the course of a week, a month, or a lifetime.

Jared: I think that the silo thing, some of which comes from the fact that the organizations behind it are siloed. I was talking to someone yesterday who was telling me that the first thing their team did when they realized they needed something mobile was they created a mobile team, and the mobile team was in charge of the mobile part. But it turned out that there was this whole desktop component, and that was a different team, and they weren’t talking to each other, let alone what happens with customer support or what happens with sales or what happens with all these other parts of the business that aren’t even in the development side.

Chris: Again, you can slice it a number of ways. The first thing is, also, when you look at it that way and you start designing your products and services in that siloed way, you’re forgetting that a lot of people are now using channels, or platforms, or however you want to slice them, sequentially, in real tight sequence, or they’re often using them simultaneously. They might be in a retail space while using their mobile, or they might literally be on their mobile while they’re having a discussion on the phone with a call center.

All of a sudden, these worlds collide and converge to the end user, and they don’t see a distinction between that. Then, again, organizationally, you’re not communicating about what’s happening and you can’t create a more seamless experience if these silos aren’t talking to each other.

We’re seeing it a lot more. Probably in the last couple months, there have been at least three companies who’ve wanted to talk to us about helping to bridge those silos.

It’s not even just about helping them design their products and services. It’s more helping them how to think about how to arrange their organizations to be more enabled to design these more seamlessly. A lot of them have new groups, whether they’re service-design groups or customer-experience groups. But when they’re coming to talk to us, they’re saying, “Well, I’m now part of this new customer-experience group. We’re less than six months old and we’re growing, and our mandate is to bridge these silos or to help customers have an experience where those silos are seamless on their end.”

Jared: That mandate, is that an easy thing for folks to get their head around right away?

Chris: No, it’s really not. It’s easier, obviously, for a startup. On a startup standpoint, especially if they have something that is mobile-centric, the value proposition or whatever their new product or service is, what they often do is forget to realize that they’ll likely need to think about other channels. If you look at new mobile digital apps, like some exercise app, like a Nike Plus or a RunKeeper, those obviously are verily mobile-centric type of applications, but they work in concert with a web application, knowing that you do certain things with the mobile part and you do certain things with the web.

When you’re small and you’re thinking mobile-centric, often it’s a mistakable mission of not understanding that the journey that a customer uses your product in will often include another channel, and so you don’t necessarily give that channel the right attention.

But a lot of clients that we work with are larger enterprises, and that’s where it is really about that these silos already exist, and it really is the “steering a large ship” analogy, where it’s so hard to really ingrain a certain amount of buy-in to new ways of thinking about how you guys need to either organize yourselves or communicate with each other.

Jared: I could see, if you take this in its simplest form, right? A few weeks ago, I was at a conference. I’m always at a conference of some sort or other.

Chris: [laughs]

Jared: This particular conference, they were using, I think it was Eventbrite as their registration system. They were trying to check people in. They had the registration desk, like most conferences have, and they had their laptops open on the desk, and they were checking people in. Like often happens at many conferences, the first session starts at nine o’clock, so everybody shows up at quarter to nine.

At quarter to nine or 10 of nine, there was now this line with 20, 30, 40 people in it and they had two laptops in the front of the room. They were checking people off. But then, one of the guys who was running the conference looked and saw the long line.

He grabbed his iPad and he did something on his iPad, and suddenly now he’s able to walk down the line and get people’s names and check them in and say, “OK. You know what? Come back later and we’ll give you your books and stuff, but you can go get into your session so you can get a good seat, so we can start on time.”

He was able to make that happen on this iPad, which, if you go through the siloed approach, isn’t integrated with those laptops that are sitting there. But the way you’re approaching this stuff, all of this becomes a single type of experience.

Chris: Yeah. I think some of the problems is, we might be victims of our own success. We’ve talked about channels, and now the idea of cross-channel has become this thing. Yet we know that a customer’s or user experience really isn’t thought of. They don’t have a mental model that has them traversing different channels.

We now start to organize ourselves, as organizations, around channels. Yet channels are actually, if you think about them, very nebulous. I mean, you can sit there and think of mobile as a channel and you’re defining the platform as a channel.

But you have things that you can do on mobile that are often thought of as their own channels, such as chat, instant message, emails. Emails can live on desktops and different web stuff. Channels get blurry when you think of the fact that you can have live chat on websites. I know that, while sometimes they’re separate, many live-chat organizations are run by their call-center people, so the same people you would do with the phone channel are actually managing what you could think of as a digital channel through live chat.

We have this thing where we’re thinking about channels a lot, and therefore we think about them as these mutually exclusive things, and that all of a sudden hampers us. It creates a constraint around how we think about producing and designing our products and services that make it inherently less seamless for the end user.

It’s exactly to the point that you were making with your example at the conference and the Eventbrite thing. If you thought too rigidly about these siloed channels, you’re not going to be able to enable that type of experience.

Jared: Right. How did you find yourself in the middle of this? Because you’re turning out to be our go-to guy for thinking in these terms. You’ve obviously got a lot of thought behind it. You’ve got a lot of speaking. Did you just wake up one morning and say, “Oh my gosh, we’re working in silos. Let’s get out of that”?

Chris: [laughs] No. It was really about necessity. I think part of it was some of my own background before I came to Adaptive Path. I joined Adaptive Path in 2010. It was in 2010 where I saw a lot of what we were doing would be engagements around a particular area, like this is our web initiative, this is our mobile initiative, and we’d have these. We’d do the work and either one of two things would happen. One would be we would, say, as we’re helping you with, say, a mobile design strategy, we’re realizing that it involves all this other stuff. If we’re going to really look at this qualitatively and come up with a strategy for you to do it, we can’t work in a silo. We have to know more about these other parts.

Another thing that would happen, on the flip side, is they would say, “What you did for our digital strategy, design strategy”–and I’m kind of abstracting here a little bit–”what you did applies to the broader things we’re doing in the organization.” They would want to take what we were doing that, at the time, would maybe be very singular, channel-centric, like the web channel or the mobile channel, and start to apply that thinking and wanted to move it up in the organization so that it would affect other areas.

This is where we started to do a lot of stuff that is not digital. Even though Adaptive Path, up until two or three years ago, was fairly digital-centric, the past two or three years have really shown us working higher up in the organizations to hopefully embed a lot of that user-experience type thinking, or at least that empathic or user-centric type thinking, in other areas in the organization.

That’s where a lot of the journey mapping, whether it’s mobile or whether it’s for thinking about other touch points within the organization, started to come, because we, all of a sudden, had to start thinking about physical retail spaces. We had to start thinking about the phone channel. Or in some cases, we even had to start thinking about print touch points.

It’s kind of come organically, but it’s come through this evolution of moving something that was very tactical or mid-level strategic higher up into the organization and thinking how it can be applied to other parts of the organization.

Then that needed tools. That needed us thinking about tools. Experience maps or customer journey maps have been around for a while, but they’ve defined themselves in different ways, depending on whether they were used by a retail industry, whether they were being used by marketers, whether they were being used for service designers.

My personal interest in starting to think about a foundation for what experience maps should look like, especially when you’re mapping something that should be mobile-centric but looking at other touch points, came by the fact that we didn’t have a good foundational tool set. We think of other things as well. We use these ecosystem inventories or service blueprints, which I think is a very complementary methodology that comes after you look at the more experiential experience map.

I’ve had this thing where there wasn’t a real foundation so if somebody asked me should we do an experience map, there was lots of, “well, what should that be? What does that include?” I never wanted to be too prescriptive in how it should be but I figured the best way to start was to be prescriptive so that foundation is there, knowing that people will eventually kind of bastardize it and morph it into whatever they need down the line and, ideally, push the methodology of mapping customer journeys further.

Jared: I’m intrigued by some of this stuff. What’s an ecosystem inventory?

Chris: That’s actually a mash-up. What we do before we do experience maps is there’s different things you can do. I misspoke by calling it ecosystem inventory. There’s an ecosystem map which is a service design tool which allows you before you start thinking about the story you’re trying to tell and the customer journey, you’re trying to just do a bit of discovery and trying to identify everything that’s involved. What are the people that are involved?

If you’re doing a service like a health clinic you’re going to identify everything from the nurse to the receptionist to the doctors to the parking attendant or whoever it is, your devices that are involved, identifying a lot of the context that’s there before you even try to organize it into a map of some sort. What we also do separately depends on whether we’re dealing with something that’s a traditional sense of a service or something that’s more of a digital product service or something that’s a multichannel, across channel service.

We’ll do touch point inventories. When you do experience maps or you do customer journey maps, which technically there might be a difference but that’s just semantically two different ways to call the same thing, when you do those you can’t necessarily tell the story of every touch point. Your research will show what the critical touch points are or what the ones you want to highlight based on opportunities or pain points.

In the beginning, as part of discovery before you’ve necessarily done any qualitative or quantitative research with your end users or your customers, you want to identify all the touch points that exist. What are all the areas that your company comes in contact with customers or potential customers. It’s really not unlike, from an information architecture standpoint, doing a content inventory because you want to understand what this touch point is, where it happens.

It’s the metadata of it of what type of touch point is it, what are the characteristics about it, and where they occur. You have this giant inventory. You’re not really worried about it being time-based yet. You’re not really worried about it giving you any experiential insight into the customer yet. You’re just trying to that discovery of what this universe or this ecosystem of our company coming in contact with the end user is.

Jared: I’m wondering, have you guys at Adaptive Path, since you’ve been at Adaptive Path, have you guys found yourselves working with an industry or a business that you are like, “Wow, in a million years I never thought I’d be working on this type of stuff?” Something that’s just way out there from your perspective?

Chris: I can’t say that I really have. I think the point is that the wheels are already in motion that Adaptive Path was starting to do increasingly more non-digital work, or at least incorporating into something even if it started as a digital-centric initiative or engagement. Adaptive Path in 2010 saw this trend happening, but when I came aboard I didn’t really realize the extent to which I would be doing and thinking strategically about designing products and services incorporating company’s non-digital touch points or channels like retail spaces or phone channels or even print materials.

I used to really frame myself as a designer of digital products and services. I had to start really rethinking that self-identification because at least a third, if not closer to 50 percent, of my work is absolutely incorporating at the very least multiple channels and, more often than not, non-digital channels.

Jared: I think that that’s probably a trend that a lot of user experience folks are finding themselves in now is that they’re seeing that their work is growing outside of just the pixels and wireframes that they started in. I’m going to guess that that trend keeps happening.

You mentioned, when you were talking about doing the touch point inventory, that that’s part of this discovery phase. There are other steps after you do discovery that happen, right?

Chris: Yeah. Often you put discovery and research in one bucket, but I think there’s a bit of a distinction and I tend to highlight that a little bit when I’m talking about the process of creating experience maps or at least mapping this journey. Discovery is that sense of uncovering everything and understanding all the different ways your company interacts or communicates with customers, but then the research is going to be the part where you’re actually getting some insight into your customers’ or your users’ mental models, their behaviors.

We’re very user-centered so I think the qualitative research, the ethnographic type of research, is imperative, but I also sometimes think we then undervalue some of the quantitative research because that can help fill some of the gaps of limited qualitative research. If you interview six or eight people but then you’re able to get a survey with 200 people, they can compliment each other really well.

This is a fairly standard way of thinking or framework about research, but what people are thinking, feeling, and doing as a way of what we’re trying to uncover. I think some of the quantitative research you can do really illuminates some of that doing part. What are people doing? It can be as simple as web analytics or it can be a survey you send out to people.

That research goes part and parcel with the discovery process. First you have to understand that universe of that ecosystem, that universe of where your company exists in end users’ or customers’ lives and then you want to actually get insight from those customers.

The simple way we try to frame it when we’re thinking about experience maps is we’re trying to tell a story and we need to make sure that’s a true story, so we need to have real insight into a customer’s experience in order to inform us mapping what that looks like across time and place.

Jared: I go out there and I do the research. Is this with just a core team or am I bringing people from different parts of the organization in? How does that work?

Chris: The research part could work a number of different ways. I think it’s when you start to really do the mapping that it’s imperative that it’s a collaborative, cross-discipline effort, meaning if you are dealing with a journey that includes mobile, that includes web, includes retail, includes phone, whatever those are, representatives from the organization from those areas need to be involved in this activity.

The research often is dependent. The more that you can get involved, the more people can be firsthand in these insights the better. Sometimes there’s constraints where you just can’t do that. Obviously sometimes there’s research groups that help conduct the research.

We’re finding, this is kind of a newer idea, I was talking to somebody recently about how you could use the template of an experience map as a great focus group activity to actually give some structure to a focus group so it’s more of a participatory way to start to articulate what’s happening in the journey.

The research can happen in a number of different ways, but when you’re actually getting into the activity of doing the experience mapping, it definitely shouldn’t jump from discovery and research and getting these insights into somebody working in InDesign or Illustrator to create some visualization. It actually is a fairly collaborative activity when you’re doing the actual mapping.

Jared: That gets everybody involved. Then how do you, from that, pull it apart so that you know what you’re starting to think about for changing the designs that you’re producing?

Chris: Yeah. The mapping is the part that should be very collaborative. It should involve a pretty good cross-section of the organization, depending on the scale and scope of the organization and the products and services you’re designing for.

What you would do then, ideally, is when you do want to take it into artifact mode, is where you’re trying to tell the story. That’s where somebody is putting their designer hat on and thinking about the best way to communicate this journey and taking these building blocks. You have a little insight to that feeling, thinking, and doing. You’ve identified some of the context from the discovery. I know what people might be doing at this point. We hopefully have an idea of whether this is a pain point or this is an actual successful thing.

You know you want to tell a story of the journey, and that’s where you think about visualizations and you think about the ways that you can articulate it.

Then, when you’re talking about how to use the map and what you’re trying to do with it to help improve it, I think of it as there’s three ways you can apply it, and doing experience maps can be really effective for all three means, which is organizational, strategic, and tactical.

On the highest level, you can get something that you can have an organizational conversation around, because right now you have a story. The way you’re representing the story is breaking through those silos, and you can see where channels collide, where channels work in sequence, where they work in tandem, where they’re not working together, where there’s a big drop-off in expectations. At an organizational level, you can sit there and go, “How can we either know now where we should have an emphasis in where we marshal our resources or how we should organize ourselves to better support a future-state better journey that we have?”

At the strategic level, what you can do is you know you can’t necessarily fix everything, or address everything, even though it’s not about fixing it, all at once, when you have a journey that could literally cover a week or it could cover a year or it could cover multiple years, depending on what your service is and what you’re trying to do.

You can use this to create a road map of priorities. You can start to prioritize some of the things that are happening in that journey, whether they’re opportunities you’re not addressing or they’re drop-offs or some sort of pain points that are happening. You can use the journey map, again, as a conversation for actually planning your initiatives or planning that strategy of what you should do.

Then, at the tactical level, you can then start to pull the touch points out and understand, “Well, this touch point, we need to design to support this good experience at this particular point that we come in contact with them.” We can ideate around that.

Ideally at this point, you could do that normally, but at this point, you now have the DNA of the larger journey. You can sit there and understand what stage it’s in, what channels are actually involved in supporting this in a nice, seamless way, what are the things that are happening before and after it. Also, what’s the context that’s happening. We know what people’s insight are here, what they’re doing and they’re feeling and they’re thinking at this particular touch point.

Jared: If you go off and you take your journey map and you say, “OK, great. We now have this thing. Oh, look, there’s this real opportunity right at this point. I think we could fix this one thing,” is there a risk now of getting back into the silo and taking the map and working on my one thing without really getting involved with the things that come before, the things that come after it, in that journey?

Chris: There absolutely is. This, both as an activity, should hopefully improve that communication. But then, as the end artifact, it’s not a miracle worker. There has to be a commitment on the organization to want to address this. That’s why I go back to where we’re talking to companies that have new groups, often around customer experience, especially for the retailers, that have a mandate to create this more seamless experience by bridging or breaking down some of those silos.

I can tell already. Some of these are just talks, and some of them aren’t even about engagements with Adaptive Path. They’re the fact that I’m talking to other people out there about this.

The ones that have a mandate that enables them to look at that organizational level and affect change, possibly, in an organizational sense, like structure or hierarchies or things like that, are probably going to be most successful. The ones that are going to end up working strictly at a tactical level and are somehow meant to maybe facilitate a little bit of communication, throw things over those silo walls and be more of a traffic manager, won’t ideally be as successful.

That’s often why, if you hear me talk about it, I usually don’t talk about experience maps or customer journey maps. I’ll often talk about mapping the experience or experience mapping, because I really want to emphasize that it really is this process and this activity that ends up having the big payoff, and the artifact is a nice communication tool, but it’s sort of secondary to the overall process of bringing in different parts of the organization to participate in the activity.

But you need a commitment, and the activity in itself and the map and the artifact in itself can’t necessarily create a commitment within the organization to break down those silos.

Jared: This is really interesting. Is it the case that, when we’re making changes, when we do our maps and we discover, “Oh my gosh, we have a lot of opportunity here. There’s a lot of places we could do things,” is it usually the case where it’s a lot of little things that will pay off, or it’s like, “Well, if we just did this one thing. If we just put this RFID tag on this one object, then suddenly we can do all these different things that we couldn’t do before”?

Do you find that it’s more of that single point of innovation changes the world, or more of these, “Oh, no, there’s just lots of little baby steps, and when we bundle them together, suddenly we’ll see massive improvement across the organization and across the experience”?

Chris: Yeah. I would say that the first answer, I have to trudge this out at some point, is that it depends.

Jared: Right.

Chris: But I would say, more often than not, it’s the fact that there’s these little areas and that there’s all of a sudden this overriding sense that all these little parts aren’t connected to each other. There’s a little disjointedness going throughout.

I’ve had a couple things where it’s like “aha” moment, and all of a sudden you’ve change the paradigm or the framework with which you’re tackling something, and it’s usually one thing. I’ve had that happen a couple times, so I wouldn’t rule that out.

A lot of it is that scale and scope. When we’re working with larger companies that have a fairly complex set of products or service, or a singular service that has a lot of different touch points, you tend to find that it is all these little things. That’s why it tends to end up moving up the organization, because you realize it isn’t just about all these little design improvements.

I guess, in a way, I could say it’s a merger, because you’ll see all these little things, and the “aha” moment comes in, like, “At a higher level, we should be thinking about how we embed a good user experience or some type of user-centric or empathic paradigm within our organization.”

At a tactical level, it’s usually that there’s all these little disjointed bits and pieces that aren’t necessarily working together. But sometimes that kind of coalesces at a higher level about thinking about, really, if we make these one or two changes, either strategically or within our organization, we can have vastly improved results.

It’s not necessarily what you’re designing at an individual touch-point level. It’s probably pretty easy to look at what’s wrong at a particular touch-point level. It’s orchestrating how they all work together that is usually the more “aha” moment that you find.

Jared: This is just fascinating. I’m really excited about the workshop that you’re going to be doing at the UX Immersion Conference in Seattle, because I think really, it’s so often we get caught in the weeds and we are so looking at the details, and we’re trying to get the pixels right and we’re trying to get the buttons to be just the right size of our fingers and the flows to be so when we click here it goes there. But we don’t step back and say, “Wait a second. What is the user really trying to do here? What else has happened in their lives before they got here? Do we really have to ask this information? Have we asked it 10 times before?” All of those things.

Because of the way mobile is causing organizations to rethink, I think this topic is critically important, in a way that it’s never been before.

Chris: Yeah. The timing’s good. I’m really looking forward to giving the workshop, because I realize that a lot of our initiatives come from a mobile starting point. They’re looking at their mobile strategy and they talk to us, and it’s really when we realize that, except for the occasional startup that you’re looking at, but mobile rarely exists in a vacuum without touching other channels from the organization.

It really started to make sense to think about this activity from a mobile context, so that people who are in charge of mobile can realize and start to understand to design for that, knowing that it’s going to have an impact on other parts of the organization.

Jared: Very cool. Chris, thanks for taking the time today, and I’m looking forward to your workshop.

Chris: Thank you. I’m really looking forward to it. Thanks a lot.

Jared: Excellent. I want to thank everyone who’s been listening for participating and letting us know. If you listen to us through iTunes, it would be awesome if you went and gave us a rating on the iTunes, because it actually helps us get the word out to other folks and it’s useful. If you like it, go ahead, put in a rating and let the world know what you think about that.

Once again, thank you very much for encouraging our behavior, and we will talk to you next time. Take care.

Use the insights you learn from these articles to enhance your designs in 2013. Now, without any further ado and in no particular order here are the 6 article excerpts and their links.

The Magical Short-Form Creative Brief
Jared M. Spool

Something this simple shouldn’t have such wide–spread, long–term effects on the quality of a team’s work. Yet surprisingly, it does.

We first saw it with one of our clients. It was this weird ritual at the start of every meeting that discussed one of their designs.

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three–quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review.

Typically, this little pledge–of–allegiance–like ritual took about two minutes to complete. Not much really. However, it completely changed the tenor of the meeting.

Read the rest of Jared’s article.

Device Experience and Responsive Design
Luke Wroblewski

While the task of designing Web applications and sites for multiple devices can be daunting, two techniques can make the process more manageable: classifying device experiences and designing/building responsively. Here’s how these two approaches can work together to optimize interface designs across a wide range of connected devices.

Read the rest of Luke’s article.

Unleashing the Power of a UX KPI
Jared M. Spool

The Eight-Minute # Field

It took the customer-service representative what seemed like forever to explain this one field. In fact, it was just eight minutes – we timed it. He explained what the field did, how it worked, but most importantly, that the customer should never, ever, under any circumstances, change the value of this field in his customer profile to any value other than what it was currently set to. The field’s label was a very uninformative pound sign (‘#’) and the value that should never change was 1.

The customer on the other end of the phone will never get those eight minutes back. Nor will the customer-service representative. Nor will the three developers watching the recording.

But that eight-minute description of the # field and its never-to-change value was critical to the success of the product. It helped the team identify something that could easily be fixed and have ripple effects through the entire product.

Read the rest of Jared’s article.

Designing What’s Never Been Done Before
Jared M. Spool

For today’s designer, much of the work we do focuses on improving designs that already exist. Whether what we’re working on is something we’ve built or we’re improving on a competitor’s idea, we can look to what users do today to figure out where we can make the design better. We understand how to identify the improvements by using time-proven methods and processes.

However, with greater frequency than ever before, we now get opportunities to work on design solutions that don’t have existing models to work from. We’re working in the world of the “never been done before.”

Maybe we’re integrating a new technology into a workflow that’s never had something like that before, much like what’s been happening with handheld devices in medicine? Maybe we’re providing new data and insights to people because we can now combine data in a way we never could before, like what’s happening in the world of big data? Or maybe we have a way for users to take advantage of each other’s experience and knowledge, like some of the emerging crowd-sourcing applications?

Read the rest of Jared’s article.

In Defense of Lorem Ipsum
Karen McGrane

Lorem Ipsum is one of those things like silicone breast implants or orange spray cheese in a can that just seems wrong. It’s fake. It’s unabashedly fake. It calls attention to itself by being so fake, making you look at it in wonder, asking: “What is that? Can that be real?”

We don’t like fake, right? We like organic cheeses, and, well, organic breasts, and we’re 100% in favor of real content in our designs.

What you put in your mouth or have surgically inserted into your body is your business. What you put in your wireframes or your design comps? Well, that’s a heated public debate. With respected thought leaders asking us to pinky-swear that we’ll never, ever use Lorem Ipsum ever again, I want to say a few words in support of greek text.

Read the rest of Karen’s article.

Prototyping’s Resurgence: Communicating the Designer’s Intent
Jared M. Spool

Interaction design is facing a paradox because of two seemingly conflicting truths. The first truth, “Great design is done in the designer’s head.” Design is a thoughtful activity. We sit and consider what we’re designing very carefully. If we don’t have time and a place to think, the odds are we’ll arrive at a poor design.

However, that seems to be in direct conflict with another truth: “Design is a team sport.” Today’s interaction design is so involved, so complex, that it can’t be done by one person alone. Great designs come from teams of designers working together.

Yet we can’t shove the entire team into our head (or even part of the team, for that matter). So how do we reconcile these two truths? How can we do the design in our head while working as a team?

This is why prototyping is seeing a resurgence amongst interaction designers. I say resurgence because for the last ten or so years, prototyping hasn’t been a popular design activity.

Read the rest of Jared’s article.

See these authors in person

All three authors will be presenting at next spring’s UX Immersion Mobile Conference in Seattle, WA. Three days that delivers in-depth full-day workshops on every important topic for mobile UX designers.

Which articles did you find most valuable, or share with others this year? Tell us about it.

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2013 Winter/Spring Business Intern. You started with a thorough analysis of the purchasing patterns in our UIE Virtual Seminar series, as compared to registrations for our live events. You also helped us get our breakthrough All You Can Learn subscription program off the ground.

You put together a marvelous weekly social media outreach strategy. Once you started executing it, we saw a real lift in the conversations we’ve had with our customers, which has had a direct affect on our bottom line.

You also created a database of our marketing partnerships, to help us know who to contact and what they’re interested in. This makes it easy for us to make our partners aware of our latest offerings.

To top it off, you’ve even helped us document our business development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant business accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 48 hours if you have what it takes to achieve something special.

You might even want to check out our web site—www.uie.com—for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: BusinessInternJob@uie.com

This is a sample of Kevin’s featured talk from the User Interface 17 conference.

We’ve all sat through terrible meetings before. Part of what makes those meetings so bad is poor communication. Being present in a meeting doesn’t guarantee that your attendees will retain the important information from the meeting, or feel like they played any role in it. Improving the way that things are heard, seen, and discussed will go a long way to improving your meetings overall.

Kevin Hoffman is a proponent of approaching meetings as a design problem. In his talk at UI17, he discussed six frameworks to help design better meetings. The first was focused on the hearing aspect of designing meetings. Much of this has to do with making your content easier to understand. Kevin suggests covering five to seven points, and then reviewing before moving on to the next set of content.

Roles are another important aspect to meetings. One of the roles is that of a recorder. Kevin says that having the recorder use a whiteboard for “public recording” provides clearer communication. People can use the board to recall forgotten information. It also turns one way meetings into more of a dialogue.

If you weren’t able to join us this past November in Boston, we actually recorded Tuesday’s entire day of presentations. We’re making this available for OnDemand access. Learn more about this 13-hour audio and video bundle of goodness at UIConf.com.

As always, we love to hear what you’re thinking. Share your thoughts in our comments section.

Recorded: November, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Kevin Hoffman: I’m going to talk about six frameworks today that are going to help you design better meetings. They’re very simple things to keep in mind, and I’m going to show a number of really easy agendas that you can try yourself, and I’ve shared a lot of those agendas with you via the slides to make your design meetings, as Jared likes to say, “more stellar,” OK?

And the first one has to do with improving what people need to hear, focusing on the hearing aspect of designing meetings. When you’re deciding whether or not you’re going to have a meeting there are two things you want to think about. How much content can we fit in this meeting? And there’s a really great rule of thumb for doing that. And how much meeting do we need to have? How long is that meeting going to be, right? So it’s a question of scale.

And scaling meetings to people’s needs and relationships to the work has really helped me to eliminate all those meetings that are so frustrating. When I first started teaching — I used to teach at a number of schools — and when I first started teaching I asked teachers, “How do I teach?” because I didn’t know anything about teaching.

And they said, well, one thing you can do is you can put about five to seven things at a time in your talks, and every five to seven things you should review, because after about five or seven things people start to have a hard time keeping everything in their head at once.

So at five — five is a nice number to start with. Structure your content in your presentations or in your meetings in five concepts at a time. And do that in about 10 minutes. And after those 10 minutes review those five concepts before you move on to the next one.

And it’s a really easy way to very quickly scale the content that you’ve got to get across to have people do the kinds of activities you want them to do, that you’re going to facilitate in your meetings, OK?

Now the second aspect of meetings is length, and length is one where we really have a lot of problems, right? So everybody here does their work in the form of projects. We break it into projects, and we all have different relationships with those projects. At the bottom is the simplest relationship you can have with a project, right?

You may be in a large organization. There are so many projects that are going on, many of which you many not even be aware of, but at a minimum there might be a project that you want to be aware of. You might not be able to participate in it, but you just want to know that it’s going on.

Above that there are projects that you perceive have an effect on you so you won’t have the ability to participate in that project, but it’s going to affect your priorities in some way. And maybe above that it’s going to affect it in such a way that you do want to be able to collaborate on that project and have an effect on the way that project affects your work.

Above that you may want to contribute so much that you change the direction of the project fundamentally, and that would be where you might want to have that work recognized. And finally, at the top, the deepest relationship you can have with any project that you do is a project that you own, that you are responsible for the results for that project.

You can map two dimensions of all of your meetings along these relationships to help make decisions about what kind of meeting you need to have for a project. Meetings at the bottom where people just need awareness should be shorter and very simple agendas, and by shorter I mean less than 10 minutes, you know? And meetings at the top should be more time, and have more complex agendas, and that’s where you should start to introduce more workshops into things.

So at the bottom, if you think about even traditional agile process, that’s where people are doing these things like scrums. That’s why those meetings are so short, because they’re just about quick awareness. Now at Foursquare, they’ve eliminated those meetings entirely.

I’m actually tweeting links as I speak using some sort of black magic, and there’s an article on how Foursquare has eliminated check-ins entirely using asynchronous reading. I highly encourage you to check that out. That’s where we want to eliminate those meetings, meetings where we’re doing one-way communication, because we can do that asynchronously.

Now in the middle where people need to collaborate, but they’re not in charge of projects or they don’t want to be in charge, that’s where we have those traditional half hour to one hour meetings. But then above that we have the opportunity to do workshops, and the best time to do those kinds of things is at the beginning of projects when a lot of people feel like they have a lot of stake in something. All right?

So that’s the first. The second framework has to do with the roles that we play in meetings. Now meetings are not a new problem. Meetings have been around for a long time, so long, in fact, that they were around before the Web.

In the seventies there was this book that came out by Michael Doyle and David Straus called, “How to Make Meetings Work,” and they put forth this very simple role-based methodology for improving the value we get out of meetings. And it’s a methodology that I’ve incorporated into a lot of my design process. So these are the roles that are involved.

The first role — and this is the one that’s probably the most critical — is the role of a facilitator. A facilitator is one who runs a process during a meeting. And this is where designers often get frustrated. Facilitators shouldn’t contribute ideas to discussions.

They shouldn’t be evaluating the things that people say or contributing any of their own ideas. They should simple coordinate and manage a process, get it from beginning to end, make sure everybody knows what they need to do, right?

The second role is that of a recorder, and everybody thinks, “Oh, yeah, I know in meetings we’re supposed to have somebody taking notes. That’s the secretary or the court stenographer of the meeting.” But what’s different about this role, and what I do in almost all my meetings is that I do what’s called, “public recording.”

So you’re recording on something called a whiteboard, and you’re writing at a size that people can actually read from anywhere in the room what the notes of the meeting are. You want to capture just the essence of what people are talking about. And they’re not contributing. They’re focused on that recording. And then afterwards they distribute that stuff, and people can kind of say, “OK, that’s what I meant,” or they can add to it.

The third role and everybody else in the meeting is a group member, and those are the people responsibility for the content of the meeting, but as Adam and Aaron talked about earlier, they need to come prepared. That’s why we have agendas in advance of meetings. This is no-nonsense stuff, right? This is obvious.

Ideally, they need to stay positive and not be defensive. They should check and balance the facilitator and the reporter. If you’re in a meeting and someone’s supposed to be facilitating that meeting and they’re actually biasing the process by contributing ideas, group members will start not to trust them because they’re not actually running the process, they’re actually steering it in a direction.

They’re able to say wait a minute, you’re biasing the process or wait a minute, that’s not what I said. I need you to correct what you wrote down to the recorder. The last role is the role of a leader. A leader is somebody in an organization who’s at a level that they’re responsible for deciding whether or not you’re going to have a meeting and who should attend that meeting and what the goals of that meeting should be. It’s not necessarily somebody that attends the meeting, but if they do attend the meeting it should be an agreed upon rule that leaders in meetings play the role of group members during meetings.

In an organization that has reporting structure, it goes flat during discussion. That goes a long way toward improving people feeling like they can say what they need to say during a meeting, it feeling like a safe place. Every time I talk about these four roles, every time I do a workshop or present on this stuff, I always hear the same thing from everybody. It’s the first question I get.

Hold on a minute, Kevin. I’m not in charge of any of these meetings. I’m getting called into meetings that I don’t have any say over all the time and I’m in all of these meetings that I didn’t know who was invited, I don’t know why we’re there, nobody sent me an agenda. What am I going to do about those meetings eating into my time, the time that I want to use to produce stuff?

There’s one thing that you can do in that meeting that will always make that meeting better, that will turn the tone of that meeting from that one way sitting through things into a dialogue, and that’s public recording. The recording role. If you’re at a meeting that’s going off the rails, just get up out of your seat, walk over to the write board, and just start writing down the key ideas of what people are saying.

Keep capturing those key ideas. It’s the thing that we usually think is obvious but a lot of us forget to do that. We rely on that secretary to write those notes down and, if we’re lucky, that secretary will distribute those notes after the meeting and then nobody will read them again and they’re lost forever.

Public recording is something entirely different. Public recording is about giving people the ability, because they can’t remember everything they hear, to use their eyes to look up and recall information. It makes meetings much more effective. I’ve taught this at a lot of agencies.

At first, there’s always a moment of awkwardness like why are you getting up and walking over there in the middle of our meeting? I’ve heard people spontaneously applauding at the end of meetings because they were able to recall much more of the content and made the discussion much more effective. If you’re somebody who might feel uncomfortable doing this, before the meeting just say to the person who’s calling the meeting would you mind if I got up and wrote some of this down? It’s going to help me to remember it later. Actually, you’re going to be helping everybody in the room.

Attend daylong workshops from today’s best mobile UX experts at the UX Immersion Mobile Conference in Seattle, WA, April 22-24, 2013.

• Mobile Input Design – Luke Wroblewski
  When to use gestures, sensors, and geolocation as user inputs.
• Adaptive Content Design – Karen McGrane
  What content strategy means to multi-channel publishing.
• Mobile User Research Strategy – Cyd Harrell
  Who is involved in remote usability testing and mobile user research.
• Responsive Design Strategy – Jason Grigsby
  Where to insert responsive design work into your existing process.
• Putting Mobile into CX Design – Chris Risdon
  Why exploring the entire customer experience is essential to design.
• Multi-device Prototyping – Kelly Goto
  How to create prototypes for native and mobile web experiences.

Explore the conference.

Bonus item – Designer’s toolkit
Every designer needs a toolkit loaded with the essential tools to make great designs. When you register for the full conference, you’ll receive a toolkit on the first day of the conference.

Here’s an excerpt from the article

As web craftspeople, we touch almost all aspects of a project. It can easily become overwhelming to think of everything that we need to take into account for accessibility. So much so, that it can become a complete bottleneck to actually making any progress with accessibility.

Many of us are soloists. Generalists. Others are specialists or one of many other-ists. You leave your mark on whatever it is that you do. It could be writing and content strategy, visual design, information architecture, mapping out process flows, or even just getting stuck up to the elbows in code.

Read the article: One Step at a Time.

Learn more from Derek

On Thursday, 12/13 Derek is presenting a UIE Virtual Seminar, Accessibility as a Design Tool. You’ll see why accessibility amplifies design problems that currently affect the users’ ability to complete objectives.

How are you and your team integrating accessibility into your processes? We want to hear your experiences.

This is a sample of Jared’s keynote presentation from the User Interface 17 conference.

Websites are full of links. How useful these links are in helping users complete tasks is another story. Links have to guide users as they follow the scent of information. A vague or confusing link often leads users down a wrong path and in turn increases their rate of failure.

There are warning signs, however, that users are losing the scent. Using the back button — the “button of doom” as Jared refers to it — and pogo-sticking are indications that your users are having difficulty finding what they are looking for. (As Jared explains, pogo-sticking is when a user moves up and down in the hierarchy of your site, much like being on a pogo stick. )

Ultimately, users are looking for trigger words on your site. If they don’t find the words that will compel them to click, they often turn to search. Jared points out that your search logs are a treasure trove of trigger words. The very links that your users are searching and scanning your site for are what they enter into the search field.

The User Interface 17 conference was a huge success. If you weren’t able to join us this past November in Boston, we actually recorded Tuesday’s entire day of presentations. We’re making this available for OnDemand access. Learn more about this 13-hour audio and video bundle of goodness at UIConf.com.

As always, we love to hear what you’re thinking. Share your thoughts in our comments section.

Recorded: November, 2012
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared: The back button predicts failure. When I say predicts failure it means when we see the user hit the back button it means they’ve probably lost the scent. It doesn’t cause failure. Don’t do what the guy did. He went and removed the back button from the browser so people couldn’t hit it anymore thinking that somehow solved this problem and then he pointed his users to me. Don’t do that. It doesn’t work.

The big brother of the back button is pogo sticking. Pogo sticking is what happens when the user jumps up and down in the hierarchy of the site like you’re on a pogo stick. Pogo sticking is this up and down movement. It’s a very Goldilocks type thing. When we hear designers talking about it, developers talk about it, they often talk about it in this very Goldilocks type of way.

Yeah, our users, they’re going to go to this page that has all the links, we call those gallery pages but they say the page with all the links, and they’re going to click on the link that seems the best. When they click on that, they’re going to get to the content but that content’s going to be too hot so they’re going to hit the back button and they’re going to go back to the page with all the links, the gallery page, and they’re going to click on the next best link and they’ll go to that one.

Unfortunately, that one will be too cold so they’ll go back and hopefully that third one will be just right. We have this real Goldilocks thing, too hot, too cold, just right thing going on. That’s how they talk about it, but that’s not how it works. When we look at all the links, all the click streams, and we pull out the ones where there was no pogo sticking whatever, just straight through from start to finish, what we see is 55 percent success rate.

If we look at the links that have pogo sticking in them we see an 11 percent success rate. That’s a dramatic difference. This is this up and down motion through the site.

In fact, on e-commerce sites two-thirds of all purchases happen with no pogo sticking whatsoever. No pogo sticking when they’re making the purchase. Think about that for a second. Everybody who works in e-commerce tells me that customers love to compare their products and they want to go to from one product page to another but that would involve pogo sticking. They’re not doing that.

Instead, what they’re doing is they’re choosing the right product from that list of products, that gallery page. They’re choosing it directly from there and then they’re only going into the product page to make sure they made the right choice. Two-thirds of all purchases happen that way. It’s happening at the gallery page is where the decision is being made, not comparing product pages.

In fact, the more pogo sticking we see in e-commerce the less likely that person is to make a purchase. You don’t want your customers to pogo stick on an e-commerce site. On non e-commerce, the exact same pattern happens. The more we see pogo sticking, the less likely that person is going to actually get to the content they’re seeking on the site.

If your goal is all about getting to the content, you don’t want pogo sticking. The last one of these, the last predictor, has to do with the fact that there are only three ways to get from the home page to that target content page. Either you use whatever search capability is on the site, you go through whatever category navigation you have on the site, or that big ass featured content that the marketing people want there, there’s a chance they’ll click on that.

That’s it. We’ve only got those three ways. That’s our limit. When we look at search, we see a pattern that happens over and over. On every site we’ve ever studied, and we’re talking hundreds of sites, we see the exact same patterns. This is true for every single site except for one site. The way this pattern works is someone comes to this site. Let’s say they’re looking for a license for their dog.

They scan the page to find that license. What happens is the user scans the page for the trigger words, studying every possible place the trigger words could be. If they find the trigger word, they click on it. That’s what people do when they find the trigger word. If they don’t find the trigger word, that’s the case we’re interested in. When they don’t find the trigger word what do they do? They go up to search and type in a keyword.

That’s the pattern we see on every single site, on every page of every site whenever we watch users except for one site. That one site? It happens to be Amazon. On Amazon, when someone comes here instead of scanning the page for keywords their eyes go straight to the search box. Why? Because Amazon has carefully trained every single one of its customers that they never put anything useful on the home page.

Every time you’re sitting in a meeting and someone says we should be like Amazon. Amazon I just go to search. Yeah, we could train everybody that our page is useless. Let’s do that. But that’s not what we do. We put useful stuff on the page so people have to scan it.

What’s interesting are those keywords that they type in. Those aren’t just any keywords. A person scans the page looking for their trigger words. Then they don’t find them, they go up, what do they type into that box? Trigger words. We’ve named this wrong. We shouldn’t call it the search box. We should call it bring your own link. That’s what it is.

These people are creating a link. Every time someone types a search keyword into your page, they’re telling you what link they wanted to find on that page. Which means that your search logs are completely filled with the trigger words that users are trying to find but can’t. You want to go through your search logs and look for those trigger words. In fact, if you can figure out what pages they’re searching from they’re telling you which page you needed to pull the trigger words and put them on right there.

Your users are telling you the stuff all the time. I’m hoping you’re catching this stuff because it’s critical. They’re telling you this.

When we watch people in our click streams use search we see some really interesting patterns. If we pull out click streams where there’s no search at all users succeed about 52 percent of the time. If we pull out all the click streams where users actually did use search, we see success about 30 percent of the time. You’re actually 50 percent more likely to find what you’re looking for if you don’t use the search facility than if you do use the search facility on most sites.

The search facility, which is designed to help you find what you’re looking for, is actually not helping you find what you’re looking for because they’re creating links, crossing their fingers hoping the site brings them to that content, and chances are it’s not matched up very well. You can sit here and you can improve the results of your search or you can take every clue the users are giving you and put those links on the page.

This little company IBM, back when they were in the laptop business, discovered 80 keywords that users kept looking for that weren’t on the pages. They went into their search logs, figured out what pages they were on, put the pages in. This was on the part of the site where people bought laptop computers. Within a month they saw sales increase 300 percent just by adding those trigger words to those pages that people were searching from. 300 percent increase. How’s that for an ROI?

You can sit there and make search better or you can sit there and say we’ve lost scent. That’s what’s going on.

We’ve earned that over the 17 years we’ve been putting on our UIE conferences, masters tours, and workshops. It’s because of the hard work we put into every event we do that people know it’s going to rock.

Like our events, the concept for the UX Immersion Mobile Conference started almost a year ago. We wanted this year’s conference to be a deep dive into an important hot UX topic. Mobile was the obvious choice, because of how it affects every aspect of how teams work.

We decided to start with the full-day workshops. We love the full-day workshop approach because you get a deep, intensive look at the program. It’s perfect for people who want to learn to tackle their hardest challenges. In a full-day, you have time to ask questions and practice the methods. You can see where the subtlety and nuance plays a role. It’s a total immersion, which is what we’re all about.

Because this conference is focused on mobile UX, we needed to find six presenters who can cover all the different areas. Some were obvious choices, like Luke and Kelly. Others, we needed to find more details on.

Nobody gets on our program until I’ve had a chance to see them present. Just because you’re smart or have written a great book doesn’t automatically make you a great presenter. With full-day workshops, it’s a long time to sit in a room with someone who is hard to listen to.

Fortunately, I go to enough conferences every year to these folks. For example, I saw Chris at the IA Summit and Cyd at UX Friday. I knew they had the dynamic presentation style and depth of knowledge we needed to make it work.

We’ve been working with each speaker to custom design their workshops. It’s critical that each one get into the depth they need, but they can’t overlap with the other presenters. This way, hardly a moment is wasted on duplicate information and techniques. All that coordination takes work, and that’s what we’ve been doing.

We’re so confident we’ve put together a great program, that we can offer our 100% guarantee. We promise you’ll get what you need. When we get the full-session descriptions up in January, you’ll know exactly what the presenters will cover in their workshops. If that sounds awesome to you, then sign up, because we know you’ll get what you need to create great designs. Or we’ll give you your money back.

The early bird registrations are going fast. We’ll have seats at the $1,689 regular price once the initial 125 seats are sold, but if you trust us like all these other folks, you can save yourself a little money by registering now. (Don’t delay, though. As you can see, these early bird seats are going fast.)

Go explore the conference, and we’ll see you in Seattle in April.

Here’s an excerpt from the article

It’s a big deal. A really big deal.

The pebble of the mobile phone hitting the market has grown into a massive, earth-moving force of nature that is fundamentally changing how we look at our design work. If your design team isn’t preparing for this change, you’ll be washed away when it makes land in your part of the world.

It touches every part of our UX work, from how we design our interactions, to how we integrate the devices. It affects how we figure out what to build and how we interact with the rest of our organizations. Who would’ve thought that something as small as a smartphone would have such a tsunami-sized ripple effect through our work?

Read the article: Mobile UX’s Tsunami-Sized Ripple Effects.

Boost your mobile UX skills

It was just this realization of how important mobile UX is that put our team in motion to create next spring’s UX Immersion Mobile Conference. Three days that delivers in-depth full-day workshops on every important to topic to mobile UX designers. Get the details at http://www.uxim.co/

How are you and your team adapting to the ever changing sea of mobile design? We want to hear your experiences.

Here’s an excerpt from the article

Within any device experience, there’s still a lot of variation -especially in display sizes. Connected TVs, laptops, desktops, tablets, smart phones, and feature phones all come in a variety of screen resolutions, densities, and aspect ratios. But don’t worry…responsive design can help.

Responsive design allows you to fill in the blanks within device experiences through the application of fluid grids, flexible images, and media queries. So once you have an optimized tablet solution, the difference between a 10 inch screen and a 7 inch screen is covered by responsive design and a few simple rules of adaptation like adding additional rows, increasing image sizes, and the like.

Read the article: Device Experience & Responsive Design.

Learn more on responsive design

From desktop monitors and TV’s to mobile phones and tablets, how does each affect users’ expectations, what influences users’ device purchase in the first place, and why is responsive design the way forward? On November 29, 2012, Peter-Paul Koch will answer these questions and more in his webinar, Solutions for A World of Countless Devices.

What techniques are you using to reduce the costs of iteration for your team? We want to hear your experiences.

We’ve got the best mobile UX experts rocking this year’s UX Immersion Mobile Conference:

• Luke Wroblewski – Mobile Input Design

  When to use gestures, censors, and geolocation as user inputs.

• Jason Grigsby – Responsive Design Strategy

  Where to insert responsive design work in your existing process.

• Cyd Harrell – Mobile User Research Strategy

  Who is involved in remote usability testing and mobile user research.

• Karen McGrane – Adaptive Content Design for Mobile

  What content strategy means to multi-channel publishing.

• Chris Risdon – Putting Mobile into CX Design

  Why exploring the entire customer experience is essential to design.

• Kelly Goto – Multi-device Prototyping

  How to create prototypes for native and mobile web experiences.

Registration Opens Tuesday, December 4—Get First Dibs

There are only 125 spots available at the $1,349 price. Get a jump start on saving your spot when you sign up for the UXIM VIP list. While you register on 12/4, everyone else needs to wait until 12/6.

There are other perks besides being first to register when you’re a VIP. You’ll get special UXIM discounts, guaranteed workshop choices until 2/8 (even if you didn’t get to grab one of the 125 spots), a designer’s toolkit, and a free virtual seminar.

Explore the workshops, get your boss’s approval now, and sign up for the VIP list today.

(Originally posted at the IA Summit Library)

Most interactions have an underlying rhythm. For example, an application may ask you to scan a list of items, then click one, leading to another list to scan and click. Scan, click, scan, click. You can get into a groove. Systems increasingly have rhythm too: animated transitions, hover responses, and digital physics. Static is so last year.

But sometimes it’s wise to break rhythm. And besides, rhythm alone isn’t enough. The best experiences induce a state of “flow,” during which users get into such a groove that mechanics disappear, time falls away, and the experience itself becomes intrinsically rewarding. (Wouldn’t that be awesome?) Designers own rhythm. Yet our work practice lacks appropriate tools and vocabulary. How do you portray a groove in a wireframe or PowerPoint deck? Examples from other fields can help. We’ll see how it’s done in animation and movies, game systems, music and choreography.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Peter Stahl: Good morning, everybody. How are you?

Audience: Good. How are you?

Peter: I’m doing great. My name is Peter Stahl, and I want to thank you all for coming to my talk on rhythm and flow. While we’re waiting for people to filter in, I’ll tell you a little bit about myself. This is my resume, on a slide.

I have worked in everything from eBay, e-commerce to Cisco doing specialized technical applications for Cisco Services. I started, actually, in local area networking at NetStar, and I’ve come full circle at Cisco.

If you want to know what I do when I’m not working, I’m into California ballot propositions. You can engage me in a lunchtime conversation about that. Also, I’m a musician, and I support a chorale academy, and I play in Redwood Symphony.

This is my second presentation at IA Summit. Four years ago, with Josh Damon Williams, I talked about checking the feel of your user interface with an interaction audit. It attempted to delve into the little-explored second component of look and feel, the feel part, which we think is neglected and deserves much more attention than it gets.

Here, we have the risky blank slide.

Here’s where I talk about what we’re up to today. I believe we’re at a crossroads in our profession. Our disciplines have evolved tools and processes for static screens, information displays, forms and so on, all the things that made the worldwide web… I’m sorry? This is intended to be a blank slide.

The idea with this is that maybe you’ll pay attention to the speaker instead of the visual.

We, as a profession, are really good at designing static screens, and that’s understandable if you look at the evolution of our discipline. Many of them came out of print media and others out of architecture, and those, primarily, deal with static information displays or static experiences.

There are two problems. First of all, user experiences do not stand still anymore. Secondly, it’s no longer good enough simply to provide functionality. We have got to engage and delight our users, and that’s hard to do with user experiences that sit still.

Our profession has to adopt vocabulary, artifacts and methods that recognize experience over time and across screens, from end to end. If we don’t, we risk obsolescence or worse, irrelevance, the same way that the designers of early mobile phones are now irrelevant in the face of Android and iPhone and the like.

Today, I hope to kick off a conversation about how to approach this issue that’s so vital for our profession.

All right, now you’ve got a visual again. I’m going to be talking about interactive rhythm, flow, artifacts and deliverables, motivic rhythm, which is distinct from interactive rhythm, and finally, how to capture timing, in other words, ways for us actually to incorporate these into our work practice.

Interactive rhythm. You usually think of rhythm in terms of music. There is definitely an interactive component to playing the drums. You hit it. You get immediate feedback. You hit it rhythmically, you can get into a rhythm. But there are other experiences that have a rhythm to them, too.

Channel surfing. Lots of people go to their televisions, and they sit on the channel up button. They’ve got a period of maybe half a second to a full second after the new channel comes on to decide whether they like it, and then, they hit channel up if they don’t. In the 500-channel universe, chances are that they don’t. The rhythm is channel up, channel up, channel up, [laughs] channel up. It’s a very simple rhythm but a very popular one.

Driving a car, particularly a manual transmission as you see here, has a very distinctive rhythm to it. Drive, push in the clutch, shift, let the out the clutch, over and over again, as you accelerate, as you decelerate. Even if you’ve got an automatic transmission, there’s a great rhythm to driving. Speed up, slow down, that thing.

Video games have a great rhythm to them. That, in large part, has led to their popularity. You’re able to learn the rhythm of each game and then sublimate it so that you can focus on the higher-scale things, like strategy and looking around for monsters.

Browsing the web has phenomenal rhythm. Read a page, find a link, and click it. Read the next page, find a link, click it, and so on.

I would argue that the worldwide popularity of the worldwide web back in the ’90s, among not just geeks like the people in this room, not that everybody in this room qualifies as a geek, is, in large part, due to the simplicity of the web. It was so simple back then because all that you had were hyperlinks and maybe the occasional image map. Anybody could use it, so everybody did. Fabulous rhythm on the web.

Forms have a great rhythm. Fill in a field, go to the next field. Fill that in, go to the next one. Fill that in, go to the next one.

Desktop games have rhythm. I don’t know how many of you have ever gotten lost in solitaire, but part of its appeal is that you get into a groove. You get into a rhythm, and you can’t stop. There are lots of other games that have irresistible rhythms to them, as well.

Twitter, of course has great rhythm.

YouTube has a rhythm on a larger scale. When you get to the end of a video, it offers you a series of additional videos to watch next. You click on one of those, and, at the end of the next one, you get more. One of my kids is actually addicted to YouTube in this way, following a chain of recommendations, much like one would do when surfing the web.

This feature of Netflix is tremendously addictive, and part of its appeal is its fabulous rhythm. In this movie rating feature, you click a star, and, as soon as you’ve clicked a star, that movie goes away and another one pops up in its place. You can just keep clicking stars, in a steady rhythm, all day long, and I’m sure some of us have. I certainly have.

You might not think of a word processor or a desktop application as having rhythm, but Microsoft Word does. This user interface that you see, if you ignore that rhythm of complicated controls at the top, which are way too complicated for the people in this room, what you’ve got is something that was revolutionary when it first came out. It was the plain paper user interface, a direct metaphor for inserting a sheet of paper into a typewriter.

Now, typewriters have fabulous rhythm. My orchestra recently performed a pops piece by Leroy Anderson called “The Typewriter.” Chika, chicka, chika, chika, chika, chika, chik. Chika, chicka, chika, chika, chika, ding, whoop, and so on and so forth. How many of you are not quite sure what the ding at the end of that was?

I’ll explain it to you at lunch. It has to do with a warning bell telling you how many characters are left before you have to do a manual carriage return. Anyway, in that way, the typewriter has rhythm, and so, a word processor has rhythm. And, of course, PowerPoint has a powerful rhythm. Maybe that’s why it’s called PowerPoint.

When you’re composing PowerPoint, new slide, title, bullet, bullet, bullet. New slide, title, bullet, bullet, bullet. New slide, title, bullet, bullet, bullet. Pretty soon you start to think like PowerPoint. By the way, we’ve just composed the PowerPoint song.

Given those examples, let’s maybe draw a few generalizations. What makes rhythm? Well, it’s got to be simple enough that you can repeat it, and it has to be repeatable, obviously. The tempo has to be relatively steady. Now, we saw, with YouTube, that it doesn’t have to be exactly steady, but the sequence of action needs to be predictable, and you need to give people reason to continue, because if it only goes a couple of repetitions, that’s not much of a rhythm.

Should we always try to strive to incorporate rhythm in our user experiences? I don’t think so. It’s only appropriate in certain circumstances. If you’ve got one overall job with repeatable interactions, you want to make sure that people don’t get sidetracked or taken off track, so errors and exceptions should be rare and easy to recover from so you can get back into the rhythm.

Should rhythm ever be interrupted? I think it ought to, if you need the users to think, because once you get into a rhythm, it can be amazingly hard to get out of it.

Imagine an e-commerce site. You’ve got your users into this great rhythm. Browse, add to cart. Browse, maybe decide not to add to cart. Browse, add to cart. Now it comes time for the user to pay.

Should you set up your user experience, so that it’s easy to pay and you just fall right into it? Well, you might get people making purchases that they didn’t intend to. I know that some of you are thinking, “Great! I’ll be a lot more successful. I’ll make tons of money that people didn’t intend to give me.”

I have news for those of you who think that way. You’re going to be really, really unsuccessful and probably only in business for a very short time. So, this is a great chance to interrupt the rhythm.

Finally, not all experiences got rhythm. Here’s Photoshop. Photoshop is very complex. Now, Photoshop can have rhythm in certain, temporary circumstances when you’ve got 27 layers and you have to do the same two operations on all 27 of them. Then it’s rhythmic, but the rest of the time, Photoshop is really on the outside of the rhythm.

A settings screen that only gets used once, occasionally. No rhythm there.

Here, we’ve got TurboTax. Now, TurboTax is a form, and I said earlier that forms have rhythm. But it takes me one second to recall my social security number. It might take me one hour to collect all the information I need for schedule D. The steadiness of the rhythm is missing there.

Finally, rhythm isn’t enough. I said at the beginning that we need to engage and delight our users. Well, we’ve all been subject to rhythms that are boring, that are trivial, that are tedious, painful, unsatisfying, and pointless. Rhythm doesn’t guarantee a satisfying user experience. Oh, and I forgot annoying and insulting. Let’s never forget those.

What we need, instead of rhythm, is flow. Flow is a concept that was developed by this fellow, Mihaly Csikszentmihalyi, who is a psychologist at University of Chicago, was previously at Claremont Colleges, and I’m now going to teach you how to pronounce his name.

Ready? Repeat after me. Chick.

Audience: Chick.

Peter: Sent me.

Audience: Sent me.

Peter: High E.

Audience: High E.

Peter: Put them together. Chick sent me high E.

Audience: Chick sent me high E.

Peter: Very good. Now, the next time you drop his name in conversation, people are going to be very impressed.

His seminal work is “Flow,” where he describes the phenomenon. It’s available both in paperback and in Kindle version. I have a secret for you. Kindle edition is more expensive. I don’t know why.

He describes this flow as “the state in which people are so involved in an activity that nothing else seems to matter. The experience itself is so enjoyable that people will do it, even at great cost, for the sheer sake of doing it. Flow is being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement and thought follows, inevitably from the previous one, like playing jazz.” Let’s see, like Diana Krall here. “Your whole being is involved, and you’re using your skills to the utmost.”

Now, wouldn’t that be amazing, to have the user experiences that we create induce that kind of feeling in our users? When was the last time you truly felt as one with the user experience?

Ah, this is, perhaps, a little bit more modern version of that. When was the last time, time completely fell away? You looked up at the clock two hours later and were wondering what happened?

Or even here. The dimensions of flow that Csikszentmihalyi defines are clear goals and progress tracking. These are elements of the experience that need to be present in order for flow to exist. There needs to be a balance of challenge and skill. I’ll get into these a little bit more in detail in a second. The user has to have a sense of control. There needs to be focused concentration. This will all lead to a loss of self-consciousness and time distortion.

We’ve all experienced time distortion. You have such a great time that you forget that you have something else to do. Ultimately, the experience itself becomes rewarding. You look forward to seeing the logo of your favorite social website, just because you love to see it, and you know what it leads to. You want to do it not because of some external outcome. You want the experience itself.

Now, Csikszentmihalyi has a critique of web design. He says that “Site designers assume that the visitor already knows what to choose,” but that’s not true. People enter a website hoping to be led somewhere, hoping for a payoff.

On feedback, most websites don’t very much care what you do. It would be much better if they said, “You’ve made some interesting choices.”

Challenge. A flow experience has got to be challenging. Anything that is not a part of it is going to be irritating or ignored.

Finally, progression. You need clear goals that are in a hierarchy that builds.

How can we induce flow in what we design? By the way, on that last slide, you notice the date, here? This critique of web design is from over 15 years ago. How many of you think it might still apply today? I thought so. Good. What this means is that there is an enormous opportunity for those of us in this room and at this conference to take the next leap ahead in user experience.

In order to induce flow, basically what we want to do is fill the gaps that Csikszentmihalyi points out, meaning, to create clear goals, achievable challenges, progress tracking and obvious next steps.

Here’s one example of a way of doing it. LinkedIn tells you what percent your profile is complete, and it tells you what to do next.

Mint, which is now part of Intuit, does largely the same thing. It tells you your score and gives you ideas on how to bump it up.

Even more technical things, like wizards, can have stepped progress. If they’re designed properly, they can even have hierarchically graded challenges.

Nevertheless, not all experiences get to have flow. Here’s a registration page, and the registration page, even though it’s a form and it has great rhythm, will never have flow because once you’re done, you’re done. It also has a sense of humor, by the way. It says down here, “Please prove that you’re not a robot.”

Tic-tac-toe. Sorry, no grading of challenges here. You can see, this person who tried to see if it’s more challenging after the eight thousandth try, but… Sorry.

Some video games for some people don’t have flow. When I play Mario Kart against my teenage son, he gets into flow, but I don’t because he completely creams me every time we play. As far as I’m concerned, there’s no flow here.

A dispatch page, such as the front page of a complex website, or maybe the Yahoo home page, no flow there because the idea is to get you off of this page as quickly as possible.

Let me shift gears here and talk about artifacts and deliverables, the kinds of things that we can do, starting soon, to induce flow and to create rhythm in our user experiences.

Here is a wireframe. How many of you have created a wireframe in the last six months? OK, lots and lots, so it’s a popular artifact. It inherits a great deal of what it does from blueprints. It’s an architectural diagram.

The architectural diagram tells you a lot about the structure, but it also hides a lot. It doesn’t tell you about the materials. It doesn’t tell you about the furniture. You have to be a specialist to be able to imagine, from this, what it’s like to move through the space.

It’s also got certain symbols that are very technical in nature. Things like where the electrical outlets or overhead light fixtures are. It’s got some of the same problems associated with a wireframe. You really need to know the language of wireframes to understand what this represents.

Now, wireframes were great in the days of 1996, when this was taken, when the worldwide web consisted of only a few possible controls. Here, we’ve got hyperlinks. We’ve got an image map. We’ve got a form field. By today’s standards, this is a wireframe.

There’s a problem with wireframes. They are used to describe interaction, but they leave something out. Today’s user interfaces don’t stand still.

Here’s the same Yahoo home page from about 12 months ago, and it’s got all kinds of motion. Some of it is instantaneous, and some of it is in response to hovers. I’ll do one or two clicks here, but it’s got mouse-over responses. It’s got tool tips. It’s got these things. You click on them and completely redefine the page. How do you represent that in a wireframe? It’s a web page.

There is, however, I think, a much deeper problem with wireframes and with their brethren, flow charts and mock-ups and even prototypes.

The field that I’m in is originally named computer-human interaction. Some of you might be aware of a conference that is largely the same as this one in terms of the subject matter that it covers. I think that’s being held in a month. Where is that going to be held this year?

Audience: Austin.

Peter: Austin. Oh, excellent!

The artifacts that we’ve been looking at, wireframes, mock-ups, prototypes, what part of this do they show? They show the computer.

Now, we’ve just discussed flow. Flow is not a property of the computer. Flow happens in people. How are we going to induce flow in people if we leave them out of our designs? Our friends in the research community have a few ideas.

Look, here we have the mock-up or the actual computer in the main screen, and then, we’ve got the user down in the corner.

Here’s another one that actually shows all three components. You’ve got computer, human and interaction. The computer is on the lower left. The human’s on the upper right, and then, the actual interaction is here, on the lower right.

You might think to yourself, “Well, OK. How do I do this if I’m just designing and I don’t have anything to test yet?” Well, you can go with this comic book approach.

As a matter of fact, our friend Kevin Chang, who is now at Twitter, has been advocating this for many years. You certainly don’t have to be able to draw as well as he can. Any fans of Xkcd know that. You can get a lot across with just stick figures.

If you think that that kind of representation has to be dull, this is a counter example. This is a gesture system. You can see that this artifact is very compelling.

That leads us to motivic rhythm. We’ve already talked about interactive rhythm, things like remote controls. Motivic rhythm, rather than being a property of the user, is a property of the web page or the user experience. It happens on the computer.

Let me give you an example. This is the beginning of the Sony website. You can see that as mouse goes over each element, the response of the system is not instant. There is an animation that comes along with it.

Well, somebody had to decide whether that animation would take 250 milliseconds, 750 milliseconds, and a second and a half. And that is the motivic rhythm of this site. It’s the responsiveness of the site to the mouse over.

I’ve got another example that I’ll get to at the end if there’s time. But that’s what motivic rhythm is, and you’re seeing it more and more in websites that give you more details on an object as you hover over it. Or some kind of new experience. You can see, in this case, the entire page changed.

Since the web experience no longer stands still, somebody has to design the timing. That person is probably someone in this room.

How are we going to do this? Well, let’s see if we can take some cues from our colleagues in other industries. In motion pictures, there’s a storyboard and you can see in the upper right there is some timing.

Actually, I don’t know where the timing is indicated on these, but here’s a storyboard for a television commercial from the ’60s, for Hai Karate aftershave. Here’s a storyboard adapted for web browsing.

The world of gaming is one where timing is critical. What they use is something called animatics. Animatics is, in essence, a rough cut or a sketch that has been animated. Here’s an example from some game. You can see that it is just sketches and maybe two or three of them a second, maybe a few more. It’s used to get the timing right for the interaction. It’s also used to hand to the composer for the background score, if that’s going to be coordinated with the action.

I believe the hero wins this one. Yeah, that’s right. The spear grows back.

Another discipline that has motion and timing associated with it is dance. There are a couple of major notations that are used to establish timing in dance. One of them is Benesh Movement Notation. Each one of these lines in the staff corresponds to a part of the body, and each one of the squiggles represents a kind of movement. You can see, here, the positions that are associated with each of these notations.

A competing notation in dance is called Laban notation. You can see, this one actually has the music running up the side, and the notation doodads go in amongst the piano score, there.

Finally, music, of course, has a strong sense of timing and motivic rhythm. Maybe we can borrow something from that.

Let’s imagine that this is the user experience that you want to engender, and actually, this is the real user experience. What I showed you before was the stimulus, but, of course, we want to induce flow. I don’t know, would you say she’s in a state of flow?

Here’s the delivery method. It’s a 45 rpm record that plays on this thing, which is called a hi-fi, or if you’re my little sister, a lo-fi. I just noticed, in this photograph she’s playing a 45 rpm single at 33 and one third, which might explain why she became a Pink Floyd fan later in life.

How do you specify something like that? Well, if you’re a pianist, this is probably the right specification for that experience. If you’re a guitar player, maybe this is the right tablature. If you are a musician who plays this bizarre meat grinder instrument that they invented at the MIT Media Lab, this is probably the correct specification. If you are the singer, you want the lyrics. Maybe this is your specification, although, that’s hard to read. Perhaps you’d prefer your specification nicely typeset.

If you are an engineer, you might look at this and go, “Gosh, that’s awfully repetitive. Can’t we do something about that?”

As I mentioned before, you really want to present something that shows the experience over time, and so, a video is probably your best bet for demonstrating what the user experience will be like. In keeping with what I said earlier about including the users in your artifacts, we need to make sure we have that photo, down there. This might be the best picture.

Finally, let’s talk a little bit about what tools we can use today to generate these artifacts to help us design rhythm into our user experiences and create flow in the users, the lucky users who will love us as much as we love them.

Adobe Director is the traditional tool for people who are doing movies. It’s very old. I’m sorry. It’s very mature and has a rich, rich history to it, which means that it’s not necessarily simple for everybody to use, but it’s great at what it does. Adobe Flash is somewhat easier to get started on, and Flash Catalyst is still easier.

Microsoft has its own tool, its Expression Blend, and I’ve heard good things about it. I’ve never used it myself. Has anybody here used Expression? OK, one or two.

Axure is a fine prototyping tool.

Let’s not forget tools like Keynote and PowerPoint. Those have primitive animation capabilities, and I’ve seen them used to great effect, especially when you’re using simple watt diagrams.

You can just take a wireframe, very similar to what is used in the animatics that we saw earlier that the gamers use, pop it in and adjust the timing using the PowerPoint or Keynote animation tools. You’ll be surprised at how effective it is in conveying the experience over time and the responsiveness of the system.

Now, I think it’s time for your ideas, so we’ll pause here, and I think I’ve got five or ten minutes for questions.

[applause]

Man 1: When you started talking about the tools that we would use, Expression Blend or the Expression Suite, Axure RP and stuff like that, you were talking about a video might be the best bet for us to get there and including the users. It seems like we would maybe even have that actor or that character in there to some extent.

I wanted to know whether you meant that a video, or approximating that in a deliverable, would actually include a character, and, if so, how you see that happening?

Peter: Thanks. That’s a great question. Well, one of the things that you can do is include a stick figure down in the corner, very similar to what you see in usability tests.

Most of us have used the services of professional researchers, and what they deliver, very frequently, is something like what I showed earlier. The user experience is in the large part of the screen. Down in the corner is the user’s response. Well, how do you interpret that unless you know what you want?

You can have the user’s desired response down in the corner as a stick figure, or maybe you can take a photograph of yourself with various facial expressions. That’s always a fun thing to do. That way, you can be overly dramatic and go, “Huh?” Or, “Wow!” Or something like that, and make that part of your prototype or your specification, say, “Here’s where we really rope in the user.” Or, “Here’s where the user gets his question answered.” Or, “Here’s where the user runs into problems.”

Yes.

Man 1: I find this really useful. I’m wondering if I should do the evil, play devil’s advocate thing. Isn’t this all maybe just marking out the limitations of deliverables as a whole, and, really, what we’re talking about is needing to go more towards prototypes. The deliverable is the prototype, and you develop the interaction by looking at it. The deliverable piece is actually, well, the user test that shows that’s the user in it. Throwing that out as a…

Peter: Yeah. Well, one of my main points is that the deliverables that we are using today, in many cases, are the same deliverables that we used 15 years ago, and that’s no longer appropriate. I don’t know, exactly, what the correct deliverable is for us today.

If all interaction designers were to become animators, it would seriously affect the amount of time they have to put into their primary role. Maybe we need to start hiring animators, I don’t know. It’s an open question, but I think we need to move forward.

Man 3: I love your Beatles metaphor, especially since I’m a huge fan of the Beatles. Having said that, don’t you think the metaphor is more like a jam session or an improvisational comedy show? There is not actually an audience that can take part. It’s almost like a karaoke version of the Beatles. You can’t interact. You can’t change stuff on the presentation.

Peter: Well, you need to choose different artifacts for different parts of the design process. The Beatles thing, I think, is correct for an early stage where you’re trying to design the overall experience, and it’s important to describe, graphically if you can, what this is going to do for the users.

Later on, you need to be very, very detailed in specifications that you pass along to engineers, and so, that probably calls for a very different level of granularity in the artifact. Instead of delivering a prototype, you might deliver a table that has timings laid out in milliseconds. It’s not a one-size-fits all kind of thing.

Man 4: This question’s related to that one. You touched on duration. I’m wondering, to extend your metaphor, experience, should we be thinking about it as classically played or improvised in terms of how long somebody should be engaged, or how long to engage someone?

Peter: Nancy Dickinson, whom I worked for at eBay, liked to say, and I don’t know if she made this up herself or if she’s quoting someone else, she said that, “We don’t design user experiences. Instead, we design the opportunities for those user experiences.”

There are always going to be meticulously designed user experiences that are not on rails, and people will go down different paths. Sometimes usability testing will reveal this. Sometimes you’ll create a rich system, and people will focus on some aspect that you didn’t intend. And so, you didn’t fully design it. Those are always surprises.

We’ve got to work with people, unfortunately or fortunately. I actually, tend towards the latter. And there are always surprises. I’m afraid I can’t get any more specific than that.

Woman 3: We work with Kevin’s approach of doing the user storyboards and making the comic strips. And we design wire frames for the screens that would help that story unfold.

We did this a couple years ago, and I forgot about it. It’s called protocasting, where you take your design deliverables, even if they’re not animated with Flash or with Axure, you take them and put them up on your screen and do a video and walk through the story. I would be narrating the wire frames or designs on my screen as I’m recording a video telling that story from the comic book.

I didn’t come up with the term protocasting, but I can’t remember the name of the guy who did. But then, that video is your deliverable to the developers. Even our offshore developers got it. They’re like, “Oh, I see what we’re doing now.” But you could also send it to management, or your client or whoever.

Peter: That’s great. What’s it called? Protocasting?

Woman 1: Protocasting.

Peter: Good. If somebody wants to look up where that came from, we can do some instant research, here. That sounds like a terrific technique.

One more. This is all that’s standing between you and lunch, so. I will try hard not to go over.

Man 5: Very quick. What do you recommend as a rhythm and flow for compiling databases? You talk very bad of the engineers and databases, all those things. But this is important activity, and many people need to do. Maybe you have some suggestions about that.

Peter: Well, I don’t know if it relates to rhythm and flow, but in my experience, particularly with engineering driven product organizations, the design of database oriented programs seems to be completely oriented towards fulfilling the needs of the database, as opposed to fulfilling the needs of the users.

What I would do when designing a form to fulfill the needs of the database is insert the user. Show the user getting more and more frustrated with information, that they don’t believe is important, but the database has to have. Use that as a lever to try and convince other parts of the product team to work on ways where the user isn’t subjected to that kind of agony.

Even though it doesn’t necessarily have to do with rhythm or flow, it is a way of making the user’s needs paramount, where in so many cases, it’s the needs of the system that are paramount, by default. That’s where we can insert value.

Good. Well, I want to thank you all for attending. The summary is that interactions can have rhythm, and that flow is a great thing. Flow happens in people, not computers, remember that. Include people in your artifacts. Motivic rhythm is on the rise, and maybe we can use existing animation tools.

Here’s my contact information. If you tweet, #RhythmAndFlow. Thank you very much.

[applause]

(Originally posted at the IA Summit Library)

E pluribus unum? Better yet, out of one, create many—many channels within a multifaceted but unified experience. That’s the challenge of experience design among constrained budgets, tight timelines, and unlimited interaction expectations. Content strategy’s communication foundation, the message architecture, can help you answer that challenge.

First, we’ll discuss how to prioritize communication goals and develop a message architecture with a hands-on exercise—ideal whether you’re designing for the web, a mobile app, social media, or an offline experience. Then learn how to create consistency between long-form web copy, action-oriented forms, and pointed Tweets. Discover how to prioritize features and content types across platforms by looking at examples that do this well, and those that don’t. Finally, respond to responsive design with a strategy to adapt content across platforms but still stay true to the brand.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Moderator: OK. We’re ready to get started. And I want to introduce you to Margot Bloomstein, who’s going to be talking about driving multichannel experiences through a single message.

[applause]

Margot Bloomstein: Thank you, guys. This is awesome. It’s so nice to have people clap when I haven’t even done anything. So I think maybe we can just leave it that, and let’s go get drinks, because it’s lovely out.

[applause]

Margot: Yay! Yay drinks! Yay! [laughs]

Thanks very much for coming to this session. My goals for this are to tell you guys about what a message architecture is, how it can drive your content strategy, and then, beyond all that, how it fits into information architecture and the decisions you’re making about what channels you choose when you’re trying to execute on a brand and then how you really convey that message through those different channels. So, does that sound good? Awesome.

Why are we even talking about content strategy at an information-architecture conference? In part because I’m a content strategist and I’m here, so yay, time to talk content strategy. But it’s really because we all want the same things, whether you’re a content strategist or a copywriter or a project manager or an IA, a designer, whatever.

And it’s usually content that screws those things up. It’s the content that really gets in the way when you’re trying to deliver on time and on budget, or if you’re just trying to make sure that you’re maintaining consistency across the experience, whether it’s a website, a more multichannel effort involving Twitter and Facebook, or even a more offline experience, like say a museum exhibit or print collateral, which also certainly involves thinking as an IA and thinking about the overall user experience.

So we want those same things. We want to make sure that we’re supporting that holistic user experience, even down into the details, even down into the weeds around micro-copy, instructional copy, et cetera, all those little things. And then, as you get into those other channels, you also want to have consistency there as well.

And it gets more and more complex, certainly, as we add on those different channels, as well as the different people that maybe own those different channels. You want to make sure that you’re being relevant across all those different experiences so that you really understand what you need to communicate.

So before we get into that, before we start discussing those different channels, I think we need to take a step back, first figure out, OK, what are our communication goals? And this seems like such a basic and obvious question, but think of all the initiatives that we begin.

And certainly, if you work in a consulting engagement, you may be facing this. Or if you’re more in-house, as part of a marketing team, you might get requests like, “Oh, we want to start redesigning the website,” or “The CEO wants to start blogging,” so of course that’s what you end up doing, maybe without even asking why along the way.

There’s just a lot of different paths that you can possibly go down, without really even understanding the purpose for them. And it’s content strategy that can help with that, because if you don’t know what you need to communicate, you don’t know why you’re going down those paths, you run into a lot of problems.

If you don’t know what you need to communicate, you’re not going to know if you’re doing it well. You won’t have any measurements for success if you don’t have clear goals in mind, whether it’s attracting more people to a brand, converting more customers, getting more people to sign up for a blog or to fan a Facebook page or whatever.

Obviously, you need those goals in order to create metrics of success, and in order to keep doing more of the things you’re doing well, to keep doing them again and again. And you’re also not going to know the right channels in which to execute on your brand.

So this is where message architecture comes in. This is kind of like the rainbows-and-puppies part of the talk. So, rainbows if you’re into that, puppies if you need that. If you need something beyond rainbows and puppies, I have something very special for you.

It’s Obama on a unicorn, and I think those are some of the little bunnies from “Cinderella,” and there’s glitter shooting out its butt there. That is happiness, and that is a message architecture, glitter shooting out a unicorn’s butt.

So, a more concrete definition of a message architecture, if you will. It’s simply a hierarchy of communication goals that reflect a common vocabulary. And we can unpack that a little bit and figure out how to get at it and why it matters.

So this is really my process. Content strategy is a broad umbrella, and there are folks within it that focus maybe more on more metadata-driven content strategy, more enterprise content strategy. I focus more on brand-driven content strategy, or brand-and-user-balanced content strategy, where we’re really trying to execute on the communication goals of a brand.

So that usually means team of stakeholders who have different ideas about where maybe a product needs to go or where a company needs to go. And they use crazy words to describe it, some of which are like using leverage as a verb, and we’re cool with that. But I want to try to get them to a common language so that both they understand each other and I understand them.

So, we talk about using a really shared terminology, shared vocabulary. It’s to counter things like this. When I hear from clients stuff like, “Make us look innovative but not risky,” I’m like, “What do you really mean by that?” Or when they say, “It should look traditional but edgy.”

And I live in Massachusetts, so to me I always think that’s like a pilgrim with a crew cut. Warby Parker gets this across really well. You’ve got traditional but edgy, he’s a hipster. That matters to a lot of brands, really capturing what they mean when they say that. And I tell them, “OK, well, your words are valuable, but we really need to contextualize them and understand them in order of priority.”

It’s very similar to the conversation you might have where everybody wants to have their personal thing on a home page. Whether they’re representing the HR department or maybe different product divisions within a company, their thing is most important so it should have home-page real estate.

I hear that from a messaging perspective as well, when people say, “Well, we need to look innovative and experienced and traditional, but also different and emerging and maybe more entrepreneurial.” These things are all great, but they’re not all at the same order of priority.

You cannot communicate multiple things at once that are really in contrast to each other. So instead, we have to figure out a way to really play out that message over the course of an experience.

So here’s how we do that. I really favor an approach that is hands-on, because it’s very easy to talk about a brand in a very abstract way, where nobody really takes ownership, nobody really commits to it, because they’re just using words and they’re kind of throwaway words. So I want it to be more hands-on, more tangible, so that people are really invested in that process.

I also want to make sure that everybody involved in an engagement is really there and present, in sort of the Buddhist sense, that they are involved in the process from the get-to and committing to what we all need to communicate through this project. So to put that in more concrete terms, I want to prevent seagulling. Does everybody know what that is?

It’s basically the idea that the project kicks off. Maybe I’m working with a team of stakeholders, and we’re working along our merry way. We’re going through wire-frames, home-page comps. We’re maybe six weeks away from launch, and then some vice president comes in and says, “Why is it not purple? Why do we not have goats on the home page?”

And they basically come in and seagull, or swoop-and-poop, all over your wonderful work. I want them involved from the get-go and really buying into this. So far, I’ve already talked about glitter shooting out of a unicorn’s butt and mild poop jokes. This is awesome, and it’s only going to get better.

So, we want to prevent seagulling. We want to make sure that there’s that hands-on investment in their brand and in their communication goals and make sure that we can really prioritize what those communication goals are.

The way that I really like to do that is through card sorting. And I know many of you go through card-sorting exercises with your clients and with your companies in order to figure out how information should be organized in different sections of an experience or maybe giving labels to those sections. This is similar, but instead I’m dealing with a lot of adjectives. And it’s a three-step process.

So, to begin with, I’ll usually put out 100 to 150 index cards, each with a different adjective on them. And it’s a set that I’ve kind of evolved over time. These are most of them. But it’s a set that I’ve evolved over time to say, “OK, these are the terms that I’m hearing a lot from brands in different industries when they’re talking about their companies.”

I love that everybody thinks their company is unique. But certainly, if you work in consulting you know, no, they’re not all unique. Not every company is its own special little flower. But what is unique about them, what is unique about those brands, is how they tell their stories. And that’s where we can really dig in here.

So we go through a process where, first, I’ll give them all these adjectives, all these index cards, starts looking like this. And I’ll say, “OK, here are your words. I want you to lay them out for me in three different columns: who you are, maybe the qualities that best describe how your brand is seen now; who you’re not, maybe the qualities that better describe a competitor or just aren’t really appropriate for your industry; and then who you’d like to be, how you’d like to be seen in the hearts and minds of your target audience.”

Because, really, what we do, it isn’t science fiction, but in a lot of ways we deal in the art of time travel. We help take brands from how they’re currently seen to how they’d like to be seen, oftentimes through content marketing, through re-branding, repositioning. That takes a lot of skill. So we want to make sure that we have a good sense of where we’re going. We can only get them to the future if we know what that looks like.

So we go through that process of how they’d like to be seen, how they are now, and just how they’re not. And I’ll usually balance that with work that’s being done around user research, to take the fact of what users are saying and balance that against what the company is telling me as well.

We get those three columns, and I ask them to take a step back. Usually people at this point will say, “Hey, who threw down ‘innovative’ here? We’re not innovative.” So I’ll get to hear that little bit of debate and internal discourse, or people might all rally around a term like “savvy,” and I’ll be able to ask, “OK, what does that term really mean here?” Or there are terms that you don’t like to use, which can help me influence copywriting, nomenclature, et cetera, later on.

So we’ll go through that process. I’ll usually give them 15 minutes or so. And then we’ll move into step two. I usually shuffle all the “who we’re not” cards off the table, and we just focus on the current state, who we are, and how we’d like to be, that future state.

And I’ll ask them to physically move over the terms that they want to hold onto moving forward, that they really are invested in or are core to their brand and they want to make sure that they’re retaining in the future. They go through that process and then start making some tough decisions, because they’ll say, “OK. How we’d like to be,” we might have 50 or so different terms there.

That’s OK, because we can start to sort through them a little bit more and maybe those terms, maybe some of them, will all describe how they’d like to be seen by recruits and perspective hires. We’ll put those all in a column. Maybe other terms all describe how they’d like to be seen around their product marketing strategy or something.

Then finally, I’ll ask them to prioritize those little clumps. We usually get three to five buckets of terms that say, “Here’s what gets us in the door. Here’s how we need to be seen first, then this is what supports it.” Then finally, “This is what we use to bolster our efforts around messaging.” They’re really coming up with the terminology, the shared vocabulary, and the order of priority of those terms.

As I said, in that step three we’re really prioritizing those communication goals and I’ll have them then tell the story of how they all connect. What’s the story of those aspirations? Why do we even do this? Well, we talked about the how, the why is pretty simple. In a lot of ways, it helps them save money through the process.

Probably about ten-ish years ago or so, you probably remember it was common to usually start out, maybe after a client kickoff or whatever, oftentimes the first deliverables that they would be seeing back from a team, whether it was internal or a consulting team, were Photoshop comps of designers coming in and saying, “We’ve got three different ideas for how this could proceed, let’s say, through a website. If we hear you right is this what you meant?”

That’s expensive. That takes a lot of creativity and time and budget to sit down and start thinking visually from the get go. Now, of course, things have evolved and now usually we’ll come back and say, “Is this what you meant?” Maybe be figuring it out with a site map, starting something a little bit more low-fi like that.

By starting out with content strategy and letting the content and the communication goals lead the process, it saves money, even earlier on. If I’m putting together a message architecture it’s usually just a Word doc. The client is doing a lot of the thinking and the prioritization for me, so when I’m coming back in with that Word doc to say, “Is this what you meant?” the feedback is usually pretty easy.

We can easily move around those terms and say, “Well, it’s really most important, maybe, for us to look experienced first.” Or, “It’s most important for us to look established and traditional first,” and reorder the priority in that way.

As you see, words can really be cheaper than comps. It’s way cheaper to work in Microsoft Word or something than in Photoshop, at least from the get go. It really helps the designers then later on because we’re shoveling a lot of that budget more later in the project so that they can use it to invest in refining the details, not figuring out those initial concepts.

This process also gives us standards by which to conduct a content audit later on. Qualitative things like, “Is this content good? Can I use it in the new site architecture?” You can’t measure good unless you know how to define good. That message architecture gives you the vocabulary to say, “OK. Well, good content is content that in the future maybe upholds values of innovation, creativity and other things that the company wants to be known for.”

We’ll see how that plays out in a few different examples. That also helps, then, if you get more prescriptive in developing the site and in developing the wire frames to say, “Well, OK. These are the content types that we need to execute on this message architecture.”

We shouldn’t just be choosing content types like, maybe, video interviews because, again, somebody’s president is like, “Oh, our competitor has video interviews. We should, too,” but rather because they articulate the right communication goals and what that company is trying to tell.

I think one way to remember this is if you think of The Eagles, “Life in the Fast Lane.” It’s for rock stars. It doesn’t really work so well in our industry, that idea of everything all the time. This is totally what my project meetings look like, by the way, and I don’t play any of those instruments, but it’s still what they look like.

That idea of executing on lots of different channels, launching in Facebook, launching on Twitter, maybe maintaining a YouTube channel, that’s great, but it is not sustainable. Especially if a team isn’t big enough or doesn’t have the right skill sets or if you’re putting a lot of that stuff on a marketing intern that goes away at the end of the summer.

You can’t do all those things at once when you’re dealing with constraints. And almost every project team, whether internal or external, deals with constraints. So, how we do that is by being very judicious and choosing those channels well.

Another way to look at this and content strategy itself. John Eckman last year, at WordCamp Boston, in the course of his presentation, I thought this was really great. He said, “Strategy is just using limited resources to accomplish a goal.”

So if we know now that our communication goals are documented in the message architecture, we can now use content strategy to figure out how to pick and choose what are the right channels and how do we maintain consistency through those channels to execute on that goal.

So the message architecture, it’s a very little thing with big impact. Something else that is a little thing with big impact is a small car that launched over here almost 10 years ago now. It was well-known in Europe. It was around since the 1950s, much-loved in Europe. It was the first consumer-grade front-wheel-drive car.

But it didn’t have a big following over here. It was a premium car, but Americans didn’t really know it. And as their creative director said, “We need to give people content to give them the history of this product.” That little thing with big impact was the Mini Cooper. And despite what the quote said, it doesn’t really have a Porsche 911 ride, but it is fun.

This is what their message architecture looked like. So you can see, it’s a pretty simple outline. There’s not a lot of bullets up there, but this is the story of how they communicate their brand. There’s three basic buckets to it. They want to communicate the sense of premium technology; also, the classic design; and also, because they’re a British brand–and this is getting at their vocabulary–this sense of cheekiness, that it’s smart and punny and gleeful.

Also, they have this element of spontaneity in here. This message architecture helped them figure out, “OK, we don’t have an enormous budget.” Even though they were an automotive brand when they first came to the US, their advertising, marketing, web presence, et cetera, it wasn’t backed by an enormous budget, so they had to make some tough decisions.

These are some of the channels that they chose to go into. They had their basic web presence, where you could construct a car and whatnot. Then, when they launched the Cooper Convertible, there in the background…it’s kind of tough to see in this light, they launched this little micro-site called “Open 24 Hours,” kind of playing on the pun that it’s a convertible, so “open,” da-da-da-da.

And the copy here also pulls on that message architecture. It says, “Open 24 hours.” It’s a big, open world out there, and experiencing it all might require motoring deep into the night. Hopefully this guide will help.

And you could find a place, like here, Primanti Brothers. It’s open 24 hours, serves the fries in the sandwich, which is quite the culinary tour de force. And it supports that kind of driver, it supports the brand and their target audience.

Another channel that they went into, again, they weren’t going after the conventional social media channels. They felt, OK, that’s already crowded. Also, maintaining a Twitter presence, maintaining a Facebook presence means that we need somebody that can be monitoring comments all the time, engaging in those comments, constantly producing new content. We can’t fund that yet.

But what we could do that was right for their target audience, right for their brand and message architecture, was something like this, the Mini custom paint shop. It allowed you, the user, to kind of play with different ideas for hood graphics, graphics on the car. None of them were real, because when it launched, you couldn’t actually get a car up done however you wanted to.

But over time, this kind of went viral within their community, within their target audience. Because you could save your design, you would save it to a garage, not just to your saved files or to your folder, but to your garage. You could post it across other social media platforms, so other people could see it.

And as other people were seeing it and commenting on it, a lot of different independent garages started approaching Mini to say, “Actually, we can make custom vinyl graphics that make good on what your audience is already producing online. Let us get involved with that so that these things can be real.” So, it kind of got legs of its own that way.

Another, I guess you could call it a channel, that we often times overlook that is a wealth of opportunity for error messaging and microcopy is basic email marketing. For many, this fell within their budget, so it fit their strategy when they were trying to pick channels. And they’re great emails, including the opt out messaging at the bottom. It’s just the basic stuff. It does what it needs to do in terms of communication goals with the content and the functional needs.

But then, they add on to it in a way that’s appropriate for their brand, appropriate for their target audience. If you don’t mind missing out on all the lip smacking stuff we’ll be sending in the future, here’s how you unsubscribe. Include unsubscribe and your favorite fruit in the subject line. So, something a little bit different, little bit quirky, little bit cheeky.

So, you can see that how message architecture really helps to drive the user experience. From the content side and the actual copy writing that they were choosing, it influenced their diction or word choice, the calls to action, things like instructional copy, error messaging, nomenclature, across those different channels to help really unify it as well as the main web presence itself.

Also, in the design, in terms of their typography, the styled imagery that they choose. Usually Minis are shown on a black background from a low angle that makes them seem a little bit larger than life.

The typography that they associate with it is always sans serif bold, a little bit aggressive, that really fits the styling of the car, as well. And goes back to that message architecture of communicating this performance kind of thing that isn’t just mired in little details or anything like that. Never fussy. And also, obviously, it plays out, then, in their choice of channels and content types that they were using.

I want to walk you through one other example, a little bit faster. Also a British brand that uses the word cheeky. This is one that a lot of us probably know well. They sell print collateral online. A lot of us probably have business cards from there. Again, three basic buckets to their message architecture. They’re very helpful and accessible, customer oriented and responsive, and again, cheeky.

That brand is Moo. They sell print collateral online. Everything from business cards and postcards and stickers and all. And as they’re maintaining their brand across those different channels, they’re a really great example of how that message architecture plays out even in 140 characters or fewer.

So, on Twitter, they could’ve easily said, “We now have sticker books.” But instead it’s, “Psst, sticker books are stateside.” So “stateside” kind of underscores the fact that “We’re British and proud of it.” And that “psst,” it’s kind of cute. It’s an adorable brand, which certainly helps humanize a printer for their target audience.

A little bit of copy from the website, as well: “We love the web, but you can’t put it in your pocket. The Internet. Yay, Internet! You can’t touch it, write on it, or stick it on the fridge. You can’t pop it in the post–again, the post, not the mail–with a gift or hand it to a client. The web is great, but it’s still just ones and zeros.”

So it’s a nice way that they’re starting to establish rapport with their target audience to position their brand, but not in a very basic way at all but in a way that really sticks true to their message architecture. And then you can start to see how that plays out, even across their category nomenclature. They don’t have an “About Us.” It’s “Hello, we’re MOO,” within the “About MOO” section.

And then here’s a little snippet. If you have ordered products from them, you get the confirmation email. Now, a confirmation email basically only has to say, “Yes, we got your order. Here’s about when you should receive it. Don’t reply to this because it’s automated, you moron.” Here’s what they do.

So it comes from Little MOO, the print robot. So they’ve even paid attention to what that address is that’s sending it out. It says, “Hello, I’m Little MOO, the bit of software that will be managing your order with MOO.com. It will shortly be sent to Big MOO, our print machine, who will print it for you in the next few days. I’ll let you know when it’s done and on its way to you. Remember, I’m just a bit of software, so if you have any questions regarding your order, please first read our frequently asked questions or contact Customer Services, who are real people. Thanks, Little MOO, the print robot.”

Again, it’s adorable. It does exactly what it needs to do. It’s functionally correct and brand-appropriate. So again, their message architecture, it really just has to achieve those three things in order of priority. And they’re able to do it in their central web presence. If you’ve ever received an order from them, in the little bits of copy that are in there on paper and whatnot as well, in supplemental cards and all, on Twitter, in email, every touch point with their target audience is consistent.

So, where do you go from here with all of this? After you start out with that message architecture, as I mentioned earlier, that then becomes the standards that you can use for a content audit. As you’re starting to figure out, “OK, where do we go from here?”

Say, if it’s a site redesign, maybe you’re bringing that content into a new platform, you need to know what you have to work with in order to know, “Is it any good? What do we need more of? Where do we need to translate it maybe for the new message architecture?” before you can go forward with an accurate sense of scope and just how much work you need to do and how long it’s going to take. So you need to really measure it against the message architecture.

That’s also where you can start figuring out, “OK, what are the new content types that we need, that we’re not going to decide just by some arbitrary fiat or what’s hot and trendy right now, but rather by what really fits our communication goals?” In other words, if you need to communicate maybe the experience of a small agency, you can’t really do that without showing it in a portfolio.

If you need to communicate that a brand is very trusted and responsive and engaged with its target audience, testimonials from that audience, from representative members there, are a great way to do that. But if those aren’t the communication goals, and again, you’re probably dealing with a limited budget, a constrained time line, and other priorities that you’ve got to take care of, then probably take some of those things off the table and don’t need to waste your time at.

As a content strategist, I will typically go through this process and then move into something like editorial style guidelines and say, “OK. We know the big picture, what we need to communicate, then we know in greater detail exactly what we need to communicate through our content audit and our prescriptive content matrix or content model. Now, how are we going to communicate that?”

Again, I’ll go back to the message architecture and say, “OK. These are our communication goals. That’s going to, for me, dictate certain things in the editorial style guidelines as far as how I should be punctuating things, what the sentence structure should be like. Do we want to have really long sentences with Latinate forms of the verbs because we want to be communicating, maybe, that a brand is more conservative or more academic?”

“Or do we want to communicate that a brand is very punchy and aggressive and, maybe, fun and young, in which case we’ll be choosing more dramatic forms of verbs?” It’s that level of detail in the editorial style guidelines that I’m going all the way back to the message architecture to really get that kind of insight.

For all of that stuff, though, all of those deliverables and whatnot along the way and that whole process, the message architecture is really what comes first and what guides it. That’s what I wanted to share with you guys today. Thank you very much.

[applause]

Margot: I would be remiss and my butt gets kicked by my publisher if I don’t mention, too, if you’re interested in learning more, “Content Strategy at Work” – yay – just came out the beginning of this month. You can find it there at Amazon, and also I have some cards up here with a discount code for Morgan Kaufmann who right now, I think, has it for 30 percent off, and they’re also selling it in the bookstore out front. What questions can I answer?

Audience Member: That was great. Thank you. I think it’s really good for IAs and content strategists to be doing this kind of work, but very often you’ll find that companies might have established, maybe just calling it messaging from a marketing agency or working with someone who developed their original brand. Have you had experience integrating something that someone else did who maybe wasn’t thinking in an interactive or web sense and bringing that to the table, and how would you handle that?

Margot: Yeah. I actually hear that a lot from companies that will talk through a process and I’ll say, “Well, I want to start by digging into your message architecture.” They’ll say, “Oh. We have these brand values,” or, “We have our company credo.” Those things are great. For MOO, I think, their company vision is something like, “Accessible print for everyone.” It’s great. It’s heartwarming.

It’s the stuff of Lifetime Television’s specials involving Meredith Baxter Birney at a printer or something, but it’s not actionable. I can’t make anything from that, that is concrete and speaks to what channels we should go into then, and how should we be communicating in those channels.

Really, if they want a practical project that will be producing something for them, it needs to be actionable. I’ll take what they already have, whether it’s a vision statement or maybe research they’ve already done on their brand or on their competitors. That’s always great stuff as a starting point. Just the fact that they’ve been thinking about it is huge.

A lot of companies haven’t always been thinking a