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:

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.

What’s the Minimum Viable Product to Design for Success?

September 23rd, 2015 by Jared Spool

Lean UX focuses on research and the minimum viable product. Getting your product in front of customers early in the process lets you test any hypotheses you have about both the product and your customer base. Uncovering misconceptions up front allows you to iterate and pivot to arrive not just at the best design, but the right one.

Recently, I interviewed one of the folks on the forefront of Lean UX, Jeff Gothelf. Here’s an excerpt from our conversation:

If I had to list one of the biggest challenges in winning teams over, and providing concrete insight about how to make this work with everybody on the team, visual design is, by far, the biggest obstacle. There’s a subjectivity there to the level of fidelity that’s necessary to learn what you need to learn.

I think that [the definition of MVP] has been where some of the biggest challenges have been. One of my favorite exercises to do in workshops is to go around the room, and have half a dozen people define “MVP.” You’ll get half a dozen definitions. I always come back with, “It’s the smallest thing that you need to make or do to learn the next most important thing.”

Listen to the podcast interview or read the transcript.

Jeff Gothelf has conducted dozens of workshops all around Lean UX. In his workshop at UI20, Lean UX: Agility Through Cross-functional Collaboration, you’ll learn how to deconstruct business problems into assumptions that drive product direction. You’ll then understand how to prioritize the best product ideas and test these assumptions so that you’re building the right product.

Enjoy the podcast and we hope to see you at UI20.

UI20: You Need to Solve Problems, Not Build Features

September 21st, 2015 by Jared Spool

Recently, I published an article on a novel concept that Bruce McCarthy shared with me: Themes. Themes are an alternative for features. Instead of promising to build a specific feature, the team commits to solving a specific customer problem.

Here’s an excerpt:

Part of solving a customer’s problem is making sure you don’t make it worse. By having the problem as the starting point for the project, the development team has an instant baseline to measure against.

Given a customer problem, the team will come up with multiple solutions. Picking the best solution becomes a trade off of effort against the improvement they can deliver. Determining these factors is easier when they start with a clearly defined problem. Without a commitment to specific solutions, the team has flexibility.

It’s worth reading the full article.

You can also hear Bruce’s interview with me on UX and product roadmaps where we discuss how the importance of good user experience shifts the product-management world thinking.

Without a doubt, UX can influence a product road map. Bruce McCarthy covers exactly this in his full-day workshop, Collaborative Product Strategy: How UX Can Influence Product Decisions.

UIE Newsletter: Themes – A Small Change to Product Roadmaps with Large Effects

September 16th, 2015 by Jared Spool

In this week’s article, I investigate Themes, in which instead of promising to build a specific feature, the team commits to solving a specific customer problem.

Here’s an excerpt from the article:

Part of solving a customer’s problem is making sure you don’t make it worse. By having the problem as the starting point for the project, the development team has an instant baseline to measure against.

Given a customer problem, the team will come up with multiple solutions. Picking the best solution becomes a trade off of effort against the improvement they can deliver. Determining these factors is easier when they start with a clearly defined problem. Without a commitment to specific solutions, the team has flexibility.

Read the article: Themes: A Small Change to Product Roadmaps with Large Effects.

How could Themes improve your customers’ experience? Leave us a note below.

UIE Newsletter: The Dirty Dozen Roadmap Roadblocks

September 9th, 2015 by Jared Spool

In this week’s article, Bruce defines the product roadmap and offers twelve areas where organizations break down when developing roadmaps. Best of all, he shares ideas on how to put all twelve roadblocks in your rearview mirror.

Here’s an excerpt from the article:

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

Read the article: The Dirty Dozen Roadmap Roadblocks.

What roadblocks have challenged your organization in creating product roadmaps?  Leave us a note below.