Jared M. Spool

Jared SpoolJared M. Spool is the founder of User Interface Engineering and a co-founder of Center Centre.

If you’ve ever seen Jared speak about user experience design, you know that he’s probably the most effective and knowledgeable communicator on the subject today. He’s been working in the field of usability and experience design since 1978, before the term “usability” was ever associated with computers.

He is also the conference chair and keynote speaker at the annual UI Conference and UX Immersion Conference, and manages to squeeze in a fair amount of writing time. He is author of the book Web Usability: A Designer’s Guide and co-author of Web Anatomy: Interaction Design Frameworks that Work. You can find his writing at uie.com and follow his adventures on the twitters at @jmspool.

Jared's posts:

How Are You Getting Your Team on the Same Page?

October 8th, 2015 by Jared Spool

While developing the topics and workshop leaders for this year’s User Interface 20 Conference in Boston, November 2–4, I realized that a general theme was emerging—getting everyone on the same page about your designs. Here’s how each workshop at UI20 contributes to this theme:

If getting your team on the same page is critical for your design success, then you won’t want to miss this year’s UI20 conference. Go explore the full-day workshops and discover how they can make your team stronger and more in sync.

UIE Article: Prioritizing Opportunities Across the Customer’s Experience

October 7th, 2015 by Jared Spool

In today’s article, I discuss how service design helps teams get on the same page about the context of their work.

Here’s an excerpt from the article:

Breaking large efforts into small teams makes sense. However, it also creates silos of effort. The outcome is a disjointed user experience. Employing a service design approach helps feed information into the project prioritization process, to ensure a better experience.

Read the article: Prioritizing Opportunities Across the Customer’s Experience.

How could you re-prioritize to provide a better user experience? Leave us a note below.

Aligning Your Team with Design Systems and Style Guides

October 2nd, 2015 by Jared Spool

Nathan Curtis, co-founder of EightShapes, has worked with component libraries and style guides for years. He says that when you’re thinking about all the platforms that comprise the totality of an experience, these patterns (such as a sign-in form, or elements like buttons) need to be more broadly applicable. It’s one thing to create the structure and layout, then thread all the pieces together for a single app or web page, but when that app needs to scale across platforms, it suddenly becomes a very different animal.

Recently, I interviewed Nathan on design systems and style guides. Here’s an excerpt from our conversation:

Oftentimes, style guide refers to a core part, or a foundation of the library of parts that everybody has at their disposal. People have been building those for years. It’s been 10 years since I worked with the sun.com team, and they had a massive component library.

All these component libraries aren’t new, but they’re starting to get used by more and more people. When you start to think about all the people that participate in that, and all the products they apply these things to, suddenly you have to think more systematically, and that’s where the term “design system” comes from.

Listen to the full interview or read the transcript.

In Nathan Curtis’ workshop, Building Scalable Design Systems and Style Guides, you’ll learn how to:

  • Create a library to articulate standards across all product lines
  • Identify and prioritize patterns for product consistency
  • Use cross-product standards to design and build better products

See what else you’ll do during Nathan’s full day workshop at the User Interface Conference, November 2 in Boston.

Using Journey Maps to Visualize the Path a Customer Takes

October 1st, 2015 by Jared Spool

Communication is at the heart of service design and Marc Stickdorn knows the core of it is getting everyone on the same page. He says that the importance of this lies in the fact that customer experiences sometimes aren’t tangible—a user or customer could be experiencing an internal event. It’s important to understand how different customers come in contact with the design.

One way of determining that is with a customer journey map. Being able to visualize the path a customer takes while interacting with your product is a powerful thing.

A few weeks ago I interviewed Marc Stickdorn on this topic. Here’s an excerpt from our conversation:

The journey map is as good as the data we use to create it. When we talk about journey mapping and getting everybody on the same page, we also need to make sure that the customer has a word in there. That means that we either have data about the customer, solid data, not so much talking about content of data, but rather qualitative research methods, ethnographic research, to really understand, “What is their experience?” from a customer perspective, step-by-step throughout the whole journey. Then based on this data, we can start to redesign or improve it.

Listen to the full interview with Marc or read the transcript.

In Marc Stickdorn’s workshop, Service Design: Creating Delightful Cross-Channel Experiences, you’ll learn how to:

  • Redesign the service experience using journey maps as the starting point
  • Map customer satisfaction and engagement throughout the customer journey
  • Sketch possible solutions to improve on top-priority problem areas in the journey
  • Make cheap, fast prototypes to test in the context of the service situation

See what else you’ll do during Marc’s full day workshop at the User Interface Conference, November 2 in Boston.

UIE Article: Service Design – Pushing Us Beyond the Familiar

September 30th, 2015 by Jared Spool

In a conventional UX approach, we’d focus on the bits. With service design, we go beyond and think about the cross-channel experience. Today’s article discusses the intricacies of service design and why you need to pay attention to it.

Here’s an excerpt from the article:

User research isn’t the only aspect of digital UX practice that we need to change when we start doing service design work. We need to look at how we prototype services, how we think about the information organized in the service delivery, how the service looks, and what behaviors we want each party to have when interacting in our designed experience.

Read the article: Service Design: Pushing Us Beyond the Familiar.

How have you blended your digital and non-digital channels to create better user experiences? Leave us a note below.

It All Comes down to Aligning Your Organization

September 29th, 2015 by Jared Spool

If you don’t understand how users are interacting with your product or service, you don’t know what to design for. But how, as a team, do you come to that understanding? Telling the story of a user’s journey highlights areas where you’re right on point and where you’re missing the mark. And it’s a great way to get everyone on the same page.

A few weeks ago I got together with Kim Goodwin where we discussed how journey maps and storytelling plays into scenarios and the design process. Here’s an excerpt from our conversation:

If we focus on the story of what this particular human being that we’re envisioning is doing—what do they see and encounter—it doesn’t matter how the back end
does it.

It doesn’t matter what technology we use because we’re just getting at the gist [of the story]. That helps keep requirements at the right level instead of having teams that do requirements that are actual lists of solutions instead of lists of problems that must be solved.

Listen to the podcast interview or read the transcript.

In Kim Goodwin’s workshop, Using Scenarios to Solve Problems, you’ll learn how to:

  • Create journey maps to understand the users’ current experience
  • Dig into how scenario-driven design gets teams on the same page
  • Generate delightful design solutions using the power of storytelling

Help Designers and Developers Learn to Understand Each Other

September 29th, 2015 by Jared Spool

The notion of being a “designer who can code” has been a prevalent topic in recent years. One of the greatest benefits of using CSS is speaking the same language as your developers. Having this common language aids in creating a more collaborative feel to conversations with developers versus dictating to them what to do.

Being able to use just enough code to create an interface element that not only shows how it should look and work but actually displays it in action, is a powerful communication tool.

Recently I interviewed Jenn Lukas on this very topic. Here’s an excerpt from our conversation:

When we understand the tools that we work with we all become better at our jobs. The same way as a developer understanding design principles can make me develop better. I know what to QA for, I know how to keep a consistent grid, I know what goes into good typography. These are the rules that make you more well-rounded.

Going the other way, to be able to know what CSS and technology is capable of really helps people to create better, stronger designs. To know where you can push the limits of design, to know where things can be scaled back, to know what goes into the building blocks of creating something.

Listen to the podcast interview or read the transcript.

In Jenn Lukas’ UI20 conference workshop Mastering CSS to Build a Living Style Guide, you’ll learn how to:

  • Build style guidelines to communicate effectively with developers
  • Understand the most common styles, including fonts, colors, and background
  • Define your design’s look and feel with divs and flexible layouts
  • Get everyone on the same page about how your design should look and feel

Testing Versions of Your Content Might Be the Missing Link for a Useful Design.

September 25th, 2015 by Jared Spool

Usability in products and websites is what most organizations strive for. Through research and testing, you can root out many issues with clunky interactions that hinder the experience. What isn’t as immediately clear is if some perceived usability issues are actually understandability problems. If your content works, it goes a long way toward improving your entire experience. If it doesn’t, then it’s the culprit.

A few weeks ago, I interviewed Steph Hay about content-first, a method she promotes. Here’s an excerpt from our conversation:

What I actually learned is that they were testing usability and they were adding language where things were breaking down from a usability standpoint to try and help clarify the process. Adding to it wasn’t necessarily making it more understandable. It wasn’t even necessarily making it more usable.

There were a couple projects that had been in usability testing and the teams were saying “I know that there’s something here and we just can’t get at it.” What we ended up doing, taking a content-first mindset, is actually extracting the content from the interface, from the prototype that we were testing, and putting it in a Google Doc or in a Word doc and then going in and testing the language agnostic of the interface.

We would figure out where the ah-ha moments were and we would pay attention to the language that they were using, so that we could really understand what specifically were the compelling words that would make somebody want to move forward.

Listen to the podcast interview.

Steph Hay has conducted numerous workshops that focus on content-first design. In her workshop at UI20, Content-First UX Design: A Lean Approach, you’ll learn how to design conversations that engage and motivate your users, which in turn allow you to design fewer iterations overall.

UIE Article: Team Models for Scaling a Design System

September 24th, 2015 by Jared Spool

In this week’s article, Nathan Curtis investigates different variants of centralizing and federating decision making around a design system.

Here’s an excerpt from the article:

Now, more designers code. Now, more developers design. Product managers have their hands dirty with everything. They all work tribally in teams spread throughout an enterprise. You can’t legitimately tell them what to do anymore. No one is that omnipresent, omnipotent or omniscient. You have to work together to build something bigger and cohesive.

So, how do you form a team that best helps you stay cohesive with a system? It depends on who you are and what you are capable of.

Nevertheless, modern design organizations are making their way from solitary teams making a library available or a centralized team serving disconnected products towards a more federated approach.

Read the article: Team Models for Scaling a Design System.

How could your company benefit from a federated design system? Leave us a note below.

Stop Doing Survey Research

September 24th, 2015 by Jared Spool

Recently, Erika Hall published the article On Surveys where she emphasized the danger of using surveys as a research tool. She suggested that they’re often misunderstood and misused and frequently poorly done.

Here’s an excerpt from her article:

In my opinion it’s much much harder to write a good survey than to conduct good qualitative user research. Given a decently representative research participant, you could sit down, shut up, turn on the recorder, and get good data just by letting them talk. (The screening process that gets you that participant is a topic for another day.) But if you write bad survey questions, you get bad data at scale with no chance of recovery.

What makes a survey bad? If the data you get back isn’t actually useful input to the decision you need to make or if it doesn’t reflect reality, that is a bad survey. This could happen if respondents didn’t give true answers, or if the questions are impossible to answer truthfully, or if the questions don’t map to the information you need, or if you ask leading or confusing questions.

It’s worth reading the full article.

You can also hear Erika’s interview with me on team-based research and the need to shift away from an academic way of thinking about it.

Using a team-based research approach and skillfully analyzing the data is key to getting your team on the same page when trying to figure out who your users are and what problems you’re trying to solve for them. Erika Hall covers this in her full-day workshop at UI20 on Cultivating Shared Understanding from Collaborative User Research.