Jared M. Spool

Jared SpoolJared is Founding Principal of User Interface Engineering. He's been working in the field of usability and design since 1978, before the term "usability" was ever associated with computers. Jared has guided the research agenda and built UIE into the largest research organization of its kind in the world.

Jared is a top-rated speaker at more than 20 conferences every year. He is also the conference chair and keynote speaker at the annual User Interface Conference, and is on the faculty of the Tufts University Gordon Institute.

Jared's posts:

UIEtips: UX & Mobile Design – 2012′s Challenges and Opportunities

January 31st, 2012 by Jared Spool

New can be very scary. It’s easy to get comfortable with what we know, only to have everything turned topsy-turvy when we encounter major changes.

The world of mobile design is new, and therefore, scary for many. The comforts of designing for the desktop disappear when we have to deal with these portable, tiny devices. Even the way we design – the processes and techniques we’ve honed over many years of practice – suddenly doesn’t work the same. We need to think about our work in new ways. Very scary.

Yet this scary new world also brings tremendous opportunity. Thanks to the pioneers in this space, there’s a new appreciation for the value of design. That new appreciation gives us room to rejigger the broken parts of how we’ve designed in the past. And that’s really exciting.

In this week’s UIEtips, I explore both the scary and the exciting that comes with mobile design. Join me as I look at four areas where designers will face challenges and opportunities in the coming year.

Read the article: UX & Mobile Design – 2012′s Challenges and Opportunities.

If you’re facing these mobile design challenges and opportunities, then you’re in for a real treat. We’ve just announced our new spring conference: UX Immersion 2012, which has a focus on creating great mobile designs. You’ll want to consider one or two of the in-depth, full-day workshops by Rachel Hinman, Luke Wroblewski, or James Robertson. These folks will help you overcome the challenges and take advantage of the opportunities. See the entire UX Immersion program.

How are you dealing with the challenges of mobile design? How have you taken advantage of the opportunities? Leave your thoughts below.

Presenting the UX Immersion 2012 Conference

January 27th, 2012 by Jared Spool

Peer into Your Future

You’re about to see a project we’ve been working on for several months. A brand new conference bringing the newest, most critical thinking around two separate and important topics: mobile design and Agile development.

These experts will dive deep and get to the nitty-gritty details that will make you a stronger and more valuable UX Pro.

Agile Process

Mobile Design

Get First Dibs on a Seat When You Become a VIP

There are only 100 specially priced $1,349 spots available for the 3-day UX Immersion Conference. One of them can be yours.

VIPs will receive a special link to access registration on Monday, January 30. Everyone else will have to wait until Tuesday night to save their spot.

So be sure to get on the VIP list and start exploring the UX Immersion Conference.

UX Immersion 2012 - Agile/Mobile

Why Agile and Mobile Design Is the Focus at UX Immersion

January 24th, 2012 by Jared Spool

In the last two years, the UX world has seen some drastic changes. Our designs, and the processes to get to them, are undergoing a transformation that forces UX designers to rethink what they do.

Users’ behaviors change based on how they view digital content. The desktop computer is no longer the norm for reading content and conducting web interactions. As a designer you must think about designing for the plethora of mobile devices now available. It’s not a question of whether to consider mobile design, it’s a matter of actually planning and implementing it now.

And how we communicate our designs is shifting. Agile threw a wrench into wireframes and the solid set of deliverables that would serve as a contract. More and more, design teams are testing out the idea of a collaborative journey where design and development are working together in short sprints.

However, one major core UX principle has not changed: put the user first, think about who they are and what they need, and build to their tasks.

3 Intense Days to Make You a Stronger UX Pro

We thought about all of this when we were putting together the UX Immersion Conference 2012 – Agile/Mobile happening in Portland, OR, April 23-25, 2012. Our vision for this event is to bring the newest, most critical thinking around two separate and important topics: mobile design and the Agile process. We’re not presenting brief introductions and sending everyone on their way. We want UX pros to get an in-depth understanding of what’s new and what’s changing.

We’ve carefully designed the UX Immersion program to get you completely up to speed on where we are in these new worlds. You’ll learn the latest techniques for dealing with a UX process in an Agile environment. You’ll discover what it takes to build usable, useful, and delightful mobile apps that work within the ever-changing standards.

We’ve assembled an amazing team of leading-edge thinkers on these new forces. These folks have been pioneering these areas. They are the thought-leaders that everyone goes to for the tough problems. And, importantly, they are excellent teachers who can make a day of this material really fun and engaging. Who are they? You’ll find out really soon.

Get on the VIP List

Later this week, the UX Immersion 2012 – Agile/Mobile web site will launch. On January 30, registration will open exclusively to those on the VIP list (believe me, you want to be be on the VIP list). These folks will get the first shot at the 100 seats available at the lowest conference price. Starting at 5:00 pm, January 31, we open registration to everyone.

Become a VIP by signing up for the UX Immersion email list. As a VIP you’re guaranteed the lowest conference price, a conference gift, and other special perks. You can also follow us on Twitter for the latest conference updates and news.

We’ll see you in Portland in April.

UX Immersion 2012 - Agile/Mobile

UIEtips: Why Visualization

January 23rd, 2012 by Jared Spool

There’s definitely an advantage to having your users understand data and messages through a picture versus reading a series of sentences. Information visualization, when done right, can have a greater impact.

In many ways, data visualization will take a message and make it more succinct. A good visualization can simplify the most complicated data, and often provide an interactive component with the user that a string of words can’t accomplish. The right data visualization will save the user time and provide a better experience.

In today’s UIEtips, Noah Iliinsky explores what makes data visualization so interesting. You might be surprised that biology has something to do with it.

Read the article, Why Visualization.

If you’re looking to tell a story through visualization, you’ll want to join us for Noah’s upcoming UIE Virtual Seminar on Thursday, February 2. Noah will show you how to choose an appropriate story for visualization then how to tell it. Learn more about his seminar.

UIEtips: Attaining a Collaborative Shared Understanding

January 18th, 2012 by Jared Spool

Sometimes, it’s easy to brand what we do as the “science of the obvious.” Here we are, doing all this research, and come up with something that is painfully obvious.

The latest of the obviously obvious findings we’ve come up with? That teams who don’t have a shared understanding of their design rarely succeed at producing a great product. See? It’s obvious.

Yet it surprises me that quite frequently the obvious is not what people do. Many teams that we’ve studied don’t pay attention to whether they have a shared understanding or not. They don’t create a process to ensure everyone is on the same page. Then they wonder why their results aren’t what they want.

In today’s UIEtips, I describe the two types of shared understanding we uncovered and how one of them is far more likely to end with a successful design. I’m betting this is an article that will create some interesting discussions amongst your team.

Read the article: Attaining a Collaborative Shared Understanding.

A collaborative shared understanding is a key component of successful Agile projects. Fortunately, on January 24, Anders Ramsay will be sharing his techniques for helping teams collaborate in his UIE Virtual Seminar, Designing with Agile. Bring your team and learn the best techniques.

Have you transitioned from a contractual approach to a collaborative approach to attaining shared understanding? We’d love to hear how it went (or is going). Leave us a note below.

Should You Be Hands or Brains?

January 14th, 2012 by Jared Spool

[This is part 2 of a two-part post. For this article to make sense, you probably want to read part 1. This article was originally published on JohnnyHolland.org.]

In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The Role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

All in a Name: Fun Times with a Weighted Matrix

January 12th, 2012 by Jared Spool

Producing a brand new event is exciting. Lots to think about: the speakers, the topics, and the locations. Yet what immediately separates one conference from another is its name.

Back December 2011, we asked your help in naming our brand new conference. There weren’t a lot of details other than it’s a 3-day consisting of full-day workshops and one day of short talks all focusing on two separate themes – mobile design and Agile. Like all the UIE events, we’re loading this conference with field-leading, edge-defining, top-caliber speakers providing you with techniques to immediately make a difference with your designs and inspiring insights.

We certainly weren’t disappointed with the response. We received over 450 entries.

Many of the suggestions consisted of creating a new word. Mogility, MoAgile, Magile, and Magility were popular entries.

Some folks went the acronym route. Magic: The Mobile – Agile Conference, MAID: Mobile Agile Insight & Design, MAX: Mobile Agile Experience, and MoMMA:Masters of Mobile Media and Agile.

All these submissions provided ammo for another round of name brain storming in our office. These names (some submitted, some we thought of) made the final cut.

  • Be Agile, Go Mobile Conference 2012
  • Adaptation: The Mobile & Agile Conference
  • Adapt UX: The Mobile & Agile Conference
  • BAM – Best Practices for Agile and Mobile
  • UIE Trends: The UX Conference for Mobile & Agile
  • Scrums and Thumbs: UX Conference for Agile and Mobile
  • POP UX 2012: UX in Agile and Mobile
  • UX Immersion 2012: Agile and Mobile

So how do you choose the right name, one that’ll be the forefront of the event’s brand? To make our decision, we turned to the same techniques we use for prioritizing large amounts of user data.

The Process

As with any good process, we first needed to figure out how we’d know if we did a good job. We needed success criteria. So we went about identifying the qualities of a good UIE event name.

As we looked at names we sorta liked and ones we didn’t like as much, we started discussing how they were different from each other. That gave us some perspectives: we wanted the name to be remarkable, but not too cute. It needed to be easy for someone to sell to their boss, since many folks will need to ask to come.

We knew that it had to convey the theme of the conference. A name that was easy to use in promotional materials. And that it conveyed it was associated with UX. In all, we ended up with a list of 8 attributes. But it would be impossible to find a name that matched all of those. So we needed a way to figure out which attributes were most important.

(Coming up with attributes like this is the same way we figure out what makes one study participant different from another, when we’re creating personas. We make playing cards for each participant, pull out two cards, and ask “What’s different between them?” and “What’s the same?”)

We used another technique from our client work: we gave each attribute a weight. Every person on the team assigned a number from 1 to 5, where 5 is a must-have quality and 1 is a nice-to-have.

To come up with a group consensus, we used a two-step voting process. First, everyone gives a number. Then we discussed any differences. (Why did Brian give that one a 2? Why did I give the same thing a 4?) Finally, everyone voted again (because the discussion changes people’s minds) and we chose the mode average. (Some people use median average, but that creates crazy precision that I don’t think is necessary.)

We then put our final cut of names through the criteria to see how they scored. Three names all scored pretty high. Our next step was to see how a designer would use the name in the logo. After seeing some initial sketches, it became clear what to name this new conference.

And the name is…

Are you ready? Here it is: UX Immersion 2012 Conference—Mobile/Agile.

UX Immersion 2012 - Agile/Mobile

It fit all our top criteria and we liked how we can easily shorten it to UX Immersion. (In the office we’ve already shortened it to IMUX or if you want to be Yoda like – UXIM.)

The web site will be up soon. In the meantime, if you want to get updates about the conference, sign up on our email list.

The Winners of the Contest

No one submitted this name directly, however four people submitted names that started with UX. No entries had immersion in the name. Since we can only have one winner, we decided to do a drawing among submissions from these 4 individuals. Congratulations to Gary Anderson. The other three people will receive runner-up prizes of the newly released UI16 OnDemand.

Finally, as promised, we drew three email addresses at random for the virtual seminar give away: Carol Roberts, Marci Kenneda, Chris Eklud.

Thanks to everyone who participated. Be sure to follow us on Twitter for the latest updates on the UX Immersion 2012 Conference—Mobile/Agile.

Putting An End To An Opinion War

January 11th, 2012 by Jared Spool

Opinion wars kill design projects. An opinion war happens when two or more people hold strongly held opinions that are in opposition of each other.

Opinion wars can get messy. They can stop a team in its tracks. And the worst thing about them is they can’t be won. There is never a winner in an opinion war.

The problem with opinion wars is their foundation. Let’s say you and I are in an opinion war. You strongly think that we should do some thing and I strongly think that thing absolutely the wrong thing to do.

For you to swing me over to agreeing with you that we should do that thing, you’d need to sway my opinion. And, if I’m going to convince you it’s wrong, I’ll need to sway yours.

However, swaying opinions is practically impossible. I’d like to think I’m a smart dude and my opinion is not just some random, unconsidered thought. Instead, I’ve based my opinion on my life’s experiences, which you haven’t had. Similarly, you’re a smart dude or dudette and your opinion is based on your life’s experiences, which I haven’t had.

To sway my opinion, you’d have to convince me to put aside everything my life’s experiences are telling me about this situation and take, completely on faith, your opinions. These are based on your life’s experiences, which I didn’t have. That’s really, really hard for me to do. It’s hard for anyone to do.

Opinion wars can’t be won. The only way to move past them is to subvert them.

Using Data to Subvert Opinion Wars

One way to subvert an opinion war is with data. In a design process, the data usually comes from user research.

If I believe there a right way to design something and your experience tells you that would be a sucky design, we have an opinion war. However, if we can get a prototype of that design in front of users, we’ll get real data to make the decision. We’ll no longer be working off our own opinions and experiences.

In almost every case where I’ve seen an opinion war, data about the users has completely dissipated it. Quite frequently, the data proves that neither side was completely right and that there was a completely different way to think about the problem.

All Hail The Arbitrator

Another approach to solving opinion wars is to appoint an final arbitrator. This person is chartered by the team to make decisions and every decision they make is final, no matter what others think about it.

We use this at UIE a lot. Each project has an owner. The owner makes all the final decisions for their project.

Often the project owner isn’t senior in the organization. In fact, they can be the person with the least seniority. They are not expected to ask permission. However, when they aren’t sure, they should ask advice.

Often the advice is conflicting and, occasionally, it’s strongly held. It’s this arbitrator’s responsibility to listen to all the advice and give it serious consideration. More importantly, it’s their responsibility to make the decision.

We’ve established a culture that says it’s the right thing to do make a decision, even if that decision turns out not to go the way people wanted. Even if that decision turns out, in the long run, to have not been the best approach. This is because a decision that moves us forward is better than getting stalled.

Opinion wars can kill a great project. Care needs to be taken to ensure they don’t get in the way.

UIEtips: Mobile Design – Content and the Great Web-based vs. Native Debate

January 10th, 2012 by Jared Spool

“Thinking mobile” goes beyond scaling down an existing app to fit a smaller screen or making decisions about what content to include. The ability of an app to delight its users is largely dependent on the context in which it is being used. People are using their devices seemingly everywhere to do almost everything these days. So there’s much more than just aesthetics to consider.

Back in March 2011, Josh Clark presented a virtual seminar on mobile design where he discussed the importance of designing tapworthy mobile apps. In this article, we look at two of the questions addressed in the podcast follow up: Should content on mobile website differ from their big screen counterparts, and Josh’s opinion on native web apps versus mobile web apps. The follow up podcast covered even more material so you may want to give it a listen or read the transcript.

Read the article: Mobile Design- Content and the great Web-based vs. Native Debate

Josh’s virtual seminar on Designing Tapworthy Mobile Apps (which you can view a recording of) was so well received, we asked him to do another one. This Thursday, January 12, Josh is presenting Button Are a Hack, The New Rules of Designing for Touch. Learn more about this seminar.

The Models We Use

January 9th, 2012 by Jared Spool

Bet you didn’t know this: Cars in rush-hour traffic exhibit the same basic behaviors as a spring. As the cars get closer to each other, they slow down. After coming to near stop, the cars start to get farther apart and speed up. The cycle repeats, just like a spring expanding and contracting.

Physicists figured this out, creating a data model of the rush-hour traffic. They then compared the data points to that of the moving spring. The results looked practically identical. They can use this information to help design new systems to relieve traffic congestion.

Models like this help us know how to design better. They tell us why the same patterns keep forming before us and give us hints to take advantage of their predictive behaviors.

Here are some of the models we regularly use here at UIE:

The Kano Model

Made by Noriaka Kano, this model shows us the relationship of a customers satisfaction to the effort and investment we make our designs. We use this model to predict when a feature is something that will delight our users and when it’ll be a basic expectation, and the most important point: most delighters eventually become basic expectations.

Market Maturity

One of the first models we created, this shows the stages a technology goes through, with regard to how it’s market receives it. We’ve used this model to understand how an organization’s management perceives the importance of user experience. It also helps us prevent fatal timing mistakes, where competitors can overtake market leaders because they miss important cues.

The Four Stages of Competence

Noel Bursch’s model that describes how someone moves from incompetence to skill mastery. This model is a recent favorite of ours for explaining how to help our users master complex designs.

The Magic Escalator of Acquired Knowledge

We created this model to help teams understand how users perceive a design’s complexity. It shows us how to simplify designs and what happens when we introduce major changes.

The Scent of Information

This model shows us how users move through an information-rich web site. We can use it to predict when a design is easy to navigate and where it’s putting up obstacles to users getting into trouble.

Core vs. Ring

An old model that we’re finding useful in today’s world, as it explains how people behave differently when they’re doing something that’s core to their experience versus something that’s ancillary. It helps predict how much someone will stick with a bad design and when they’ll just give up.

Hands vs. Brains

This model talks about the people teams want to hire and how to best employ them. It predicts why some smart employees struggle in some jobs while others thrive.

Design Decision Styles

This model outlines five different styles for making design decisions. Using it, we can identify what a team needs to do to inform their decision making process. It also helps us tell when there’s a mismatch in the team’s composition or approach.

When we’re working with teams, we regularly mix and match the models. Complicated problems can usually be explained by combining several models, until we get new ideas for the solutions that move us forward.

What models have you been using? How are the useful?