UI23 is happening in just over a week and you should be a part of it

October 31, 2018

The agenda is pretty awesome. The food is incredible. There are abundant chances to meet new and interesting people.

If you’re coming for just one day, then come Tuesday, our Featured Talks Day. Take in the expertise of each of our incredible UX design masters. Hear 7 great presentations that will change the way you approach your design practice:

Tuesday’s Featured Talks

Kim Goodwin

Bringing Back “Human-Centered” Design with Kim Goodwin

Define relevant metrics and bring human-centered design principles back into the conversation to support business and user experience goals.

Jeff Gothelf

Lean vs. Agile vs. Design Thinking with Jeff Gothelf

Learn how teams can work across methodologies—from Agile to Design Thinking— and collaborate to build better products.

Brian Suda

The Language of Data with Brian Suda

Learn how to navigate the language and tools of data visualization and find the right solutions for your audience.

Kim Goodwin

Advancing Your UX Career with Cyd Harrell

Take the next step from mid-level UX professional to a senior-level position with tips from mentoring to building a solid resume and portfolio that will get you there.

Jeff Gothelf

Democracy is a Design Problem with Dana Chisnell

Hear a behind-the-scenes tour of five years of slogging through research-based adjacent possibles that revealed a view of voters no one had seen before.

Brian Suda

Documenting Components with Nathan Curtis

Build and architect an effective component page in your library with this primer on how to address your audience, content, and organization.

Kim Goodwin

The Evolution of a New UX Design Revolution with Jared Spool

Pull back to an organization level, working to connect applications and other services together.

There’s never been a better time to be a designer so attend UI23 and celebrate our industry with us. Join us for our 23rd and final UI Conference Featured Talks day.

See you in November at UI23,

Our featured talks are shaping up to be our best yet. Don’t miss these 7 talks focused on exploring the different touchpoints of design. Use the promo code JOINUS and save 10% off a single, two-day, or three-day registration. Register today.

A Design System isn’t a Project. It’s a Product, Serving Products.

October 26, 2018

Shifting Focus from Design and Development to Managing and Marketing a System

Design systems result in tangible, often gorgeous outputs like a living style guide or array of design assets. When getting started, it feels like a project, evolving from early concepts to a celebrated (first) release of those assets for other people to use.

“We did it! We launched a guide. Mission accomplished.”

Celebration is justified, no doubt. You did achieve something, and making useful things for others feels great. However, be careful, because you’ve not yet realized actual business value. An enterprise realizes that value—actual cohesive experiences, realized efficiencies in development—when other teams pick up the system and ship it in their product.

A design system’s value is realized when products ship features using parts from the system.

In those quieting days following a system launch, a systems team starts to realize “What do we do now?” Worse, they (and those managing their time) think “Now we can go back to doing what we were doing before.” There’s no funded persistence. No ongoing commitment. Questions of “Will it last?” start to emerge in thoughts and conversations.

Changing from a Project to Product Mindset

Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.


Thinking as a product changes perspective: it’s now not about us, it’s about serving our customers. How do we do that? Applying well-established approaches for product management and product marketing is a great start. Once recognized, a system team can adopt familiar and predictable tools and terminology to help them succeed.

Additionally, the “system=product” model also helps a team composed of product designers and developers to recognize:

A Design system isn’t just product design and development. There’s product management and marketing too. We’re not good at that, nor do we want to be.

They may lack the talent for “product management stuff” and may not have the taste for it. Now self aware, they can choose to learn and apply such skills to fill the gap or find someone else who can.

When I meet a design system team for the first time, I don’t start with “Can you show me your awesome living style guide?” It is awesome, they are very proud of it, and I love learning about it. But such demos rest in the shadow of a more essential understanding of their system’s - their PRODUCT’s - marketing and management approach.

Spreading Your System to Their Products = Product Marketing

To have a product means knowing and serving your market:

  • What products use or may use your system? Regardless of your system’s reach, know your target market. You need a strong sense who you serve, their relative priority in influencing your work, and where each is headed.
  • When will they ship using the system? It’s very rare for an entire enterprise to pause individual work in order to launch together using a system. Instead, discussing how a design system fits is a product-by-product endeavor that seeps into their roadmaps, sprint planning, and story requirements.
  • How will you align with them? You may get to know product managers just as much or more than developers. A system’s product manager (if you have one by name or responsibility) is knowledgeable of or even participates in strategic activities like quarterly release planning across a portfolio. That said, effective alignment with product managers usually results in “alignment” meetings as well as coffees, lunches, and hallway conversations.
  • How do you promote and sell to them? Your marketing, which often involves compelling demos and presentations, effective documentation, regular communications (such as email updates and blogs), onboarding activity, and training.
  • What will each type of customer need from your system? There’s a way to disarm the tension adopters feel when intimidated by the system’s vast scale or imperfect goodness-of-fit. Most systems contain areas like color palettes, icons sets, certain UI patterns, and more (I call ’em subsystems) that aren’t universally relevant. Everything isn’t always meant for everybody. So how can you succinctly tell each what’s most helpful for them?

Sustaining Your System = Product Management

Imagine what your VP thinks: “Should I fund 2.5 full-time resources to work on a style guide full time if they can’t tell me what they’ll do in the next three months? They can barely muster a coherent definition of what they’ll do in the next two weeks. It seems everyone is doing everything and nobody is responsible for anything.”

For a design system to thrive and survive, it needs a sufficient level of management.

  • Who’s making the decisions? Modern design systems have a product manager who’s driving decisions, assertively aligning with partners, and serving as the go-to person.
  • Who’s doing the work? Sustaining a design system can involve a significant amount of design, development, writing, and other work done by people committed (at least partially, > 4hr/week) to the endeavor.
  • Who’s paying for it? It’s near impossible for a system to survive long-term without a sponsor deliberately providing a budget in the form of properly allocated time.
  • What are each of you working on right now and where do you record and prioritize things you might work on later? Yup, time for task management, which many high-performing teams increasingly formalize into a backlog over sprints using tools like Github and Jira.
  • What can your customers (products using the system) expect over the next 6–12 months? Don’t discount the power of an effective, concisely communicated system roadmap. It generates awareness, discussion, faith that you’ve got your act together, and trust that what you do provides for what they need.

Enterprises are waking up to this, forming permanent positions, with titles at Salesforce and hiring product managers specifically for systems teams at companies like Etsy and Google. If you don’t have thoughtful, reasoned answers for the questions above, how can you expect someone to fund your effort?

Learn to build a cross-product experience with defined standards and workflows. Establish processes to set up and maintain your design system during Nathan Curtis’s full-day workshop Building Scalable Design Systems.

We’re getting down to the last few weeks to register for Nathan’s workshop and our six other presenters’ workshops. Register today before the price goes up $300 and the workshops sell out. Register for UI23 today.

Prioritizing Opportunities Across the Customer’s Experience

October 25, 2018

Imagine an airline now has a way to board using a QR-code-like thing on your phone. (Ok, you don’t have to work too hard to imagine it, because practically every airline has a mobile app now.)

Making that QR-code-like thing work for boarding took a lot of work. The airline had to potentially update its scanners, because the barcodes on paper boarding passes (which they’ve had for years) are a different format. They had to create the software on various models of phones to display the QR-code-like thing. They needed to integrate all of this into their massive reservation system that tracks all passengers traveling on all flights.

For the most part, it works. Hold out your phone under the scanner and, boop-boop, you’re checked in and ready to get on the plane.

Now, imagine sometimes a flight gets cancelled while you’re at the gate. (Ok, you don’t have to work too hard to imagine that either, because: airlines.)

The gate agent now needs to re-book you onto a new flight using the re-booking module of the massive reservation system. First that gate agent needs to find your reservation. You know what would make that easy? Just scan the QR-code-like thing in and bring up the record. You know, make the boop-boop noise.

Yet the re-booking module doesn’t read mobile boarding passes. It’s been planned, but hasn’t been important enough to work on.

Identifying Cross-Experience Priorities

Breaking large efforts into small teams makes sense. However, it also creates silos of effort. The outcome is a disjointed user experience, such as what the gate agent experienced when trying to re-book your flight.

Employing a service design approach helps feed information into the project prioritization process, to ensure a better experience. It gets the teams into the field to see how the experience fits together.

A team watching the gate activity would quickly see that the mobile boarding passes create friction in the customer’s experience for activities beyond just checking in. The re-booking team could re-prioritize their efforts integrating reservation lookup with the mobile passes. The mobile team could make sure the text accompanying the QR-code-like thing has a nice fallback to find records easily.

Service design helps teams get on the same page about the context of their work. Its practices expand the user experience professional’s toolkit to bring new insights to the team and give them tools for prioritizing a better overall user experience.

Look at every touch point of your users’ experience, not just the obvious ones. Join Dana and me for our workshop Design for Delight: Transforming Your Designs From Good To Great and inspire your organization to go beyond shiny features, with products and services that deliver remarkable delight.

The Hard Truths Of Not Doing User Research

October 24, 2018

It’s true. User research takes time, effort, and often a bit of money to do well.

It’s also true that not doing user research takes time, effort, and money:

  • Having the team be constantly mired down by opinion wars takes time. When teams aren’t aligned because there’s no foundation for a common truth, they spin their wheels without making forward progress.
  • Building functionality only to have the users complain that it doesn’t work for them is wasted effort. Effort is wasted further when the team builds functions customers do not want or need.
  • Driving users to customer support because the design is too hard to figure out costs the organization money. Support is an expensive alternative to building something that’s easy to use.

When we don’t do smart user research, our teams aren’t aligned around the design our customers and users truly need. Our developers build things without the assurance they’re building the right things, or building those things right. And our organization pushes the costs of good design into the support and sales departments, where they become an ongoing expense to resolve.

It’s true. User research takes time, effort, and often a bit of money to do well.

It’s also true that not doing the research at all can often be more time consuming, take more effort, and be more expensive in the long run. Choosing to spend resources on user research is the better alternative.

There are techniques to get the benefits of user research without needing that much time, effort, or money. Guerilla user research techniques deliver insights that give teams solid alignment.

Because they are quick, guerilla techniques don’t take much effort and can save time and money. They get the job done, often as well as more rigorous methods, without sacrificing the benefits we see from higher cost approaches.

The lower time, effort, and cost of guerilla techniques make them highly advantageous to teams looking to avoid the costs of not doing any research. That’s the truth.

Fortunately, we have an expert in guerilla user research techniques, Cyd Harrell, giving a full-day workshop at UI23. During her workshop, you’ll see first hand how these techniques work, as you’ll be sent out into the city of Boston to research transportation improvements. By the end of the day, you’ll see exactly how to bring these techniques back to your organization to avoid the hard truths and costs of not doing user research.

Learn about Cyd’s workshop, Low Cost Guerilla User Research and sign up today.

What The Karate Kid Can Teach Us About Agile and UX

October 23, 2018

In the Karate Kid (the first one, aka the good one) the seemingly innocuous Mr. Miyagi takes on wayward Daniel-san and teaches him to totally kick-ass in karate. While the movie is a prized trinket of 80’s pop culture, heartwarming and by all measures a classic at this point in time (it came out in 1984!!) there are some terrific lessons to be learned from the way Mr. Miyagi taught Daniel-san how to fight. These lessons translate directly to learning any skill but, for the purposes of this post, I want to apply them to Agile and user experience design.

“Show Me, Paint the Fence!”

This is what Daniel-san heard the first day he came to learn karate. He arrived ready to learn how to punch, kick, block and defend himself. Instead, he found himself painting a fence. Confused but determined, Daniel painted the fence—day in and day out. It was exhausting, humiliating, and ultimately very frustrating as the weeks went on and it appeared that he was not learning a thing about karate. Instead, it seemed to him that he was essentially providing free labor for the old man. Finally, Daniel had enough and complained to Mr. Miyagi who, through a series of task-based commands, illustrated to Daniel how the motions of painting the fence and waxing the car were actually the same motions used in karate. Unbeknownst to Daniel, he was learning the craft all along—initially through ritual—but as he got better the ritual melted away into unconscious practice.

A Very Powerful Lesson

There is a strong correlation between rote repetition of exercises and the mastering of a process or skill. In other words, what initially looks simply like “going through the motions” can ultimately translate into process mastery and success. Initially, the calisthenics approach seems meaningless. In Daniel’s case he was painting a fence in a very specific fashion. In a designer’s case, one might take on drawing the same elements every day for a month. In an agile team’s world, this could translate into any one of the standard Scrum practices like the daily stand-up, story gathering or estimating. But by going through the motions, the ritual becomes inculcated as learned behavior. After enough practice, the purpose of the ritual starts to make sense (even if it didn’t in the beginning and seemed like a waste of time). In the designer’s case, it’s an understanding of how to render a particular form or communication. In the Agile team’s case, it’s an understanding that the daily stand-up not only allows the team to catch up on current events related to their project but also begins the bonding process for the team, which paves the way for greater trust and transparency.

What’s even more amazing is that, as process mastery progresses, again through repetition, it begins to bury itself into the teams collective unconscious to the point where, in essence, there is no explicit process—just visceral reactions to inbound stimuli from the work, the team, and forces beyond the team. Daniel found this level of mastery in the final tournament where he anticipated his opponent’s moves and ultimately defeated him. An Agile team achieves this when they trust each other implicitly, react as a cohesive unit to change and manage that change as well as any conflict with little impact to productivity or quality of work.

This approach is even more impactful when integrating user experience design into an Agile process. Initially, the designer may not understand why they’re going through the rituals of Agile every day. They may seem useless and time-consuming; removing the designer from their element and core competencies. In essence, in the early days, the designer is literally “painting the fence”—she is going through the motions because that’s what’s expected of her. As time wears on, the benefits start to manifest simply from the designer spending time with the team.

Camaraderie and joking around are the initial signs of inclusion. That inclusion begins to grow into trust as the rituals force the team to interact regularly. Trust develops into transparency where the designer is now including developers in her process and developers are seeking out the designer as they code the experience. The final step is integration, driven heavily by this trust and transparency. It’s at this point that the “process” has melted away. The designer no longer hides behind their screen incanting secret spells made manifest in documentation. Now, they sketch in the open, pair design with developers, and invite developers into the co-design process itself. The team is working on an unconscious level, reacting to input, solving problems collaboratively without consideration for “what’s next” in the Agile playbook.

It takes time to achieve this stage of process enlightenment. It requires the team to spend time together, struggle together, go through conflict together, fail together and ultimately win together. Designing a schedule of ritual practices provides a framework for the team to start working together. Teams that go through this process begin to evolve beyond the textbook practices and evolve into high-functioning teams. By initially “painting the fence,” the team can achieve a level of process mastery that pushes the boundaries of their productivity, quality, and responsibility.

Strengthen your team’s collaborative Agile process at Jeff Gothelf’s full-day UI23 workshop Leveraging Lean UX to Lead Successful Agile Design Teams. Bring the whole team and together evolve beyond the textbook practices and evolve into a high-functioning team.

UI23 - Our 23rd and Final UI Conference

October 16, 2018

Every year, for the past 23 years, the UIE team and I have said, “We’ll keep doing this until we get it right.” Well, UI23 is the closest we think we’ll ever get to perfection. And we’ve decided that we’ll make it our last UI Conference.

Don’t worry. UIE and Center Centre aren't going anywhere, but we’ll be focusing our efforts differently to help you drive better design.

If you’ve wanted to attend the UI Conference, now is your last chance.

With the JOINUS promotion code, you’ll get 10% off your registration price.

23 years for a conference is a long time. In that time, our industry has grown tremendously. In those years, UX professionals everywhere have come to the UI Conference to learn the latest and most important techniques.

In the early days, the conference was an introduction to most of the techniques we use today: user research, information architecture, and content strategy. Now at the conference, UX professionals, like you, learn advanced methods: using data visualization for complex storytelling, building scalable design systems, and guerrilla user research techniques.

The full-day, intensive, deep dive workshop format is the center of the conference. Over the years, our full-day workshops and featured talks have helped thousands of UX designers, product managers, and developers gain a deeper understanding of how to deliver great products and services.

This year, our final year, will be no different. It is indeed our best event yet. We’ve carefully selected an all-star lineup. Jeff Gothelf, Cyd Harrell, Kim Goodwin, Brian Suda, and Nathan Curtis are UX Rockstars.

I’m even giving a workshop, with the ever-brilliant Dana Chisnell. I’ve been putting this conference together for 23 years, and this is the first time I’ve taught a workshop. We’re pulling out all the stops.

That’s why you can’t pass this opportunity up. You need to be a part of the celebration of 23 years of incredible growth in our industry. You need to learn from the best experts so you can go back to your organization and deliver better design.

Our world needs you to have all of the best resources and tools. You are the future of UX. We would be honored to celebrate our industry together, with you.

Use the JOINUS discount code. Get 10% off your registration. (Works for any registration, whether it’s 1 day or all 3 days of the event.)

Chair of the UI Conference for 23 years.


If you’re thinking about attending UI23, you’ll want to sign up before October 27, when the price goes up by $300. Use the promo code JOINUS and save 10%. Register today.

A Fantastically Visual Approach for Supporting Complex Decisions

October 11, 2018

When it comes to retirement investing, do you know your volatility tolerance? Most people don’t.

However, if Guidance, a retirement investment application, knew your volatility tolerance, along with a handful of other important, yet equally obscure investment preferences, it could pick an ideal financial plan for you. That’s the challenge that Guidance’s designers faced. How do they learn this key information about their users’ preferences?

They could describe volatility the way seasoned investors think about it: as an increasing frequency and amplitude of variation in the worth of an investment instrument. But that definition won’t work for most of Guidance’s users, many of whom are not seasoned investors but hard-working employees who just want to save for their retirement.

Guidance’s designers could describe volatility visually, as a series of peaks and valleys in how much their retirement money is worth. Low volatility is a smooth, steady increase in value. High volatility shows larger increases, but also sudden decreases. The peaks and valleys happen more frequently and the differences get larger as volatility increases. Again, that’s a lot of words to help Guidance’s users get a picture in their head.

Guidance’s designers arrived at a great solution. They provided a series of pictures of the employee’s retirement savings over time. The lowest volatility was a nice smooth increase over the years left before retirement. The highest volatility showed a larger increase rate, but there were many huge peaks and valleys in between. The designers provided 5 such pictures, in increasing amounts of volatility.

Guidance’s chart showing medium-high volatility risk.

Guidance’s chart showing medium-high volatility risk.

Users could switch between pictures with a single slider. The picture they chose would indicate to Guidance that user’s volatility tolerance. An elegant solution to visually explain a complex concept.

The Guidance team used the users’ data to tell a series of stories. Stories about what that investor’s financial life could be like upon their retirement. The Guidance user could choose which story they were most comfortable with, and Guidance would set to work to make that story happen.

Data visualization is an essential storytelling tool. Designers, equipped with solid data visualization skills, can take complex concepts and make them real for the users. That’s what helps designers deliver the best products and services, especially when it comes to complex decision making.

Which complex decisions do your users face? Can you up your data visualization game to make you a better designer? At UI23, you’ll want to spend an entire day in Brian Suda’s full-day workshop, Successful Storytelling Through Data Visualization. There are still seats left. Register Today

The Secret To Innovation: Solid User Research

September 18, 2018

If you ask someone where they imagine product innovation comes, they’re likely to imagine a sterile laboratory. A place where scientists, wearing goggles and lab coats with pocket protectors, stare pensively into liquid-filled beakers.

Yet, that’s not how fantastic innovations come about. Here are a few great innovations that caught our recent attention that didn’t get cooked up in a lab:

  • When the Apple Store opened, they installed a customer appointment system to schedule time with their “Geniuses.” Apple’s customers didn’t wait in line like at other stores.
  • When weather causes flight delays and cancellations, American Airlines offers customers the option to be called back instead of having to wait on hold for by a reservations agent. Every other airline makes you wait and listen to their horrible music, interrupted by a repeated message telling you how important you are.
  • When a Chipotle customer wants to order for a group, Chipotle’s online order system lets customers invite group members to enter their own orders. Other restaurant order systems require each party member to relay their order to a single person and hope it won’t get screwed up.

No Technical Wizardry Necessary

Nothing was invented to implement these features. They are not technically complicated or remarkable.

However, their customers see it as an innovation. It separates their business from their competitors. The design teams exceeded the customer’s expectations with simple, straightforward solutions.

Those teams didn’t get to these innovations by donning their goggles and staring into their beakers. They got there by getting out of the building and learning what was most frustrating in their customers’ lives.

It’s All In The Research

The science behind these innovations was simple: pure observational research. Yogi Berra once said, “You can observe a lot just by watching.” Yogi had it right.

The teams watched and listened to their users and customers. They saw things their users wouldn’t see because standing in line or taking orders for your friends seem normal.

The teams could see which things created frustration and friction. Once they understood their customers’ problem, the potential solutions were obvious. All that was left was to pick a solution and implement it.

The crazy thing is many teams shortcut their research efforts, because “they can’t afford the expense.” The truth is they’re shortcutting their innovation efforts by skipping the research.

Great research doesn’t have to be expensive. It only needs to be insightful. That’s what helps teams deliver innovative products and services.



You need to do research. You need to get out of the office. You need to bring your team with you. And we know just the person to help you learn the simple, inexpensive techniques to do just that: Cyd Harrell.

At Cyd’s UI23 full-day workshop, Low Cost Guerrilla User Research, you’ll learn how to get the most out of your research efforts. Spend a little time reviewing her detailed workshop description to see exactly what you’ll learn.

Pleasure, Flow, and Meaning – The 3 Approaches to Designing for Delight

September 13, 2018


That’s the big, black, all upper-case message dominating the top of the online purchase email receipt from the sporting goods retailer, Moosejaw. It’s hard to miss and it’s even harder to avoid smiling when you read it.

An email receipt has very important functions. It tells the shopper what they’ve ordered and how much they’ve spent. It tells them when it’ll be shipped and where the company thinks it’s going. It often gives the shopper a tracking number for the shipment. If there were no other words but these details in the email, the receipt would fulfill its function.

Yet, for years, retailers have co-opted the receipt as a touchpoint. They put in solicitations, offers, and pleas to encourage future business. The customer doesn’t ask for this additional marketing copy. In most cases, the shopper learns to ignore the extra stuff.

Sorry For Being So Mean About It

Moosejaw’s ironic anti-plea is delightful. And it matches the copy throughout the experience of using the site.

For example, the solicitation to sign up for their email newsletter says “We’ll send you great discounts, contests and a list of the best mimes in Portland.” In the rules for their loyalty program, they’ve rewritten the usual fine print about expirations to say:

Your points expire two years after they are earned so be sure to spend all your points before then. After two years are up, the expiring points will automatically be removed from your balance by our Rewards Points Overlord (RPO). The RPO is extremely cranky and insists that once the points are gone, they are gone. Sorry for being so mean about it.

Imagine trying to get your organization’s legal counsel to approve an apology for being mean. Yet, Moosejaw’s copy says things like this all the time.

Moosejaw’s trick is they insert these funny little bits into all those pieces of text we never pay any attention to. The user is rewarded for paying attention to the bits of the design that every other site trains them to ignore. It’s a brilliant strategy.

Intentional Delight

If you agree that design is the rendering of intent, it’s easy to see how the thoughtfully humorous copy at Moosejaw is intentionally designed. It’s a great example of how we, as designers, can integrate delight into what might be an otherwise plain experience.

We can measure a design on a scale from frustration to delight. The middle of this scale is a neutral point, where the design is neither frustrating nor delightful. It doesn’t suck, but it’s not remarkable, either. It’s just a neutral experience.

When improving a bad design, we first must remove the frustrating bits to get to that neutral point. Observation of the users’ experience, followed by a careful rethinking of the design can remove everything that’s introducing frustration.

Improving the design from the neutral point to introduce delight is a different process. It’s additive, whereas getting to the neutral point is reductive. We have to know what to add to make the experience become delightful.

Dana Chisnell’s Three Approaches to Delight

Back in 2012, noted author and UX expert, Dana Chisnell, introduced us to her framework about how to design delightful experiences. (She did a fabulous webinar on it called Three Levels of Happy Design which you can find in our All You Can Learn library.) It outlines approaches that teams can take to start thinking about how they add delight for their users.

At the center of Dana’s framework are three different approaches to making an experience delightful: pleasure, flow, and meaning. Teams can pick which of these they’d like to tackle. For most teams, pleasure is the easiest while meaning will provide the most challenges.

Delight Approach #1: Pleasure

The Moosejaw strategy of embedding clever copy into the corners of the design people normally ignore is a great example of pleasure. It’s almost like the Moosejaw copy has adopted a strong personality – one that uses humor (with a tinge of sarcasm and hyperbole) to make for a distinctively pleasant shopping experience.

Humor isn’t the only way to make a design pleasurable. Something as seemingly simple as providing solid, informative content can also do it.

The electronics retailer, Crutchfield, uses great content to design delight into their site. Where many electronics retailers just republish the manufacturer specifications, Crutchfield has their enthusiastic support staff provide the product descriptions. The Crutchfield support team includes simply-made videos demonstrating what the staff person thinks of the product, detailed product research that explains the ins and out of the technology, and thoughtful comparison data, to see how different products line up.

Because Crutchfield’s front-line support people write the content, it’s written from the perspective of answering customers’ questions. Readers emerge feeling confident about their product choices. That confidence is delightful for many customers.

We could describe Moosejaw’s personality as mildly snarky and anti-bureaucratic. In contrast, we could describe Crutchfield’s personality as confidence inspiring and empowering to make smart decisions.

Both are different, yet both deliver pleasure to their customers. Pleasure is one way Dana describes how we graft delight into our designs.

Removing the Unnecessary

Few things have had a bigger effect on how we look at e-commerce user experience than Amazon’s 1-Click. In 1999, Amazon put a button on a product’s page that automatically shipped the product to a previously entered address and charged a previously entered credit card. This changed the world.

For the frequent purchaser, 1-Click removed six screens of the checkout process from their shopping experience. No longer did they need to review the shopping cart, enter their authentication credentials, provide shipping information, provide billing information, provide payment information, and confirm their order. Press one button and the product is on its way.

Before 1-Click’s introduction, every site had those six steps. They were a required part of the shopping experience, yet they offered very little value to the frequent shopper. At best, the forms might be pre-filled by logging into an account, but the shopper still had to visit each page of information and click to continue.

1-Click removed these steps, allowing the frequent shopper to focus on the part they loved most: selecting each product they wanted to own. Removing parts of the shopping process that aren’t about selecting products kept the user focused on their objective. That focus increased their delight.

Delight Approach #2: Flow

Doing one’s taxes is another user experience with a lot of steps. Throughout the process, users enter data printed by one computer into a form that’ll be read by another computer, often using their own computer.

That’s why Intuit developed the mobile app, SnapTax. SnapTax takes a picture of the employer-supplied W-2 form. It scans the text off the form and plugs it into the requisite spaces in the 1040A or 1040EZ tax form.

Once the taxpayer has reviewed for errors, the application then files electronically on their behalf. The entire operation reduces filing taxes to just a few minutes. The user never re-enters computer-supplied information. For these users, the speed makes filing taxes much more delightful than spending hours filling out forms.

Both SnapTax and 1-Click remove steps that computers can do just fine. Removing unnecessary steps improves the flow of the design. Dana’s framework shows us that improving the flow makes the design more delightful.

Delight Approach #3: Meaning

Of everyone who’s worked in our office, my former colleague Brian is probably the most proud of the products he purchases. Ask him about any product he uses, from the tea he drinks to the bicycle he rides, and he can give you a story about the company. He can tell you exactly how the tea is made and which special sporting events the bicycle manufacturer supports. The stories are compelling. They make me want to run out and buy the products myself.

Brian finds meaning in the products he purchases. Actually, I think ‘find’ is the wrong word. He ‘hunts’ for meaning behind the businesses that make the products. When he discovers it, he soaks it in and wears it proudly. You can hear the delight he has, not just with the product, but with the deep pride he has in being an active customer of those businesses.

It would be easy to brand Brian as a zealot or a fanboy. It’s not hard to find people like him – people who are proud of the companies they support. Yet, this kind of passion is hard won for those companies. Building a devoted fan base is the hardest of the approaches for delight, but probably the most long-lasting.

Delight Only Works When Basic Expectations Are Met

Similarly, I fly United Airlines almost every week. I thought it was cool when I learned United’s staff took special care of the Olympic athletes on their way to the Sochi Games.

However, you won’t hear me singing United’s praises because they don’t give me anywhere near the care they claimed to have given the athletes. They treat me like cattle, despite the volume of money I throw their way every year.

Meaning can only work to delight if it’s authentic. It’s got to be reflected in every touchpoint of the service delivered. Brian’s passion for the bicycle manufacturer is not just because of their event support, but because they make a solid product and deliver great service. My lack of passion for United comes because of the poor service I regularly receive.

Whether we aim for any of the three approaches in Dana’s framework – pleasure, flow, or meaning – the design will only be delightful if it meets the users’ basic expectations. Our work has to start by understanding what users expect the entry stakes to be. Then we can consider how we’ll infuse delight into our designs.

Learn how to apply Dana’s approaches to delight to your team’s UX design process. Dana Chisnell and I will show you how during our full-day UI23 workshop, Design for Delight: Transforming Your Designs From Good To Great. Read through the detailed workshop description to see how you can infuse pleasure, flow, and meaning into your work.

When It Comes To Personas, The Real Value Is In The Scenarios

September 12, 2018

Personas without scenarios are like characters with no plot. — Kim Goodwin

I’ve seen it happen many times. A team launches a project to identify user personas with all the best of intentions. They'll define three, four, sometimes as many ten or fifteen different personas. Then, when they’re all done, the personas become lifeless mannequins on a closet shelf that are rarely referenced.

That’s because the team doesn’t work on the parts that matter: the scenarios that define why the personas are important.

And here’s the kicker: Too many times, what the team required for their personas was far less than what they created. Had they put the resources into creating great scenarios, the effort would have played a bigger role in a better-designed product.

First, Identify A Dominant Story Through Research

An airline’s UX team is working on how the passenger check-in process can reduce stress for their passengers. The team starts with user research, conducting deep hanging out time with dozens of airline passengers.

They study the passengers while they prepare for an upcoming trip and while they’re in transit. They detected several repeating sources of stress from the research, some of which they capture in the story of a fictional passenger, Taré (pronounced like Terry).

Taré’s Current Situation

Today, Taré is flying on two flights with a tight connection through Charlotte airport. Taré has taken this trip dozens of times before.

Like usual, it takes Taré more than an hour to get from home to the departure airport. The first leg of Taré’s journey is a 90-minute flight. The second leg, leaving Charlotte, is a 3-hour flight. After the two flights, Taré will have to drive for another hour before reaching the hotel. Today, the entire journey, from leaving home to reaching the hotel, will take Taré upwards of 7 hours.

Because the connection in Charlotte is very short, Taré will have to hurry to make the connection. There’s no time to stop for any food, especially if the incoming flight is the least bit delayed (which it often is).

That means Taré will have to bring any food from home. Taré prefers not to check bags and the amount of carry-on space for extra food is limited. Taré is worried about bringing the food through security. The second leg has in-flight meals, but they don’t match Taré’s dietary preferences. On many previous trips like this, Taré went without eating the entire time, which is stressful and uncomfortable.

While Taré is a made-up character, the story isn’t. The UX team met many travelers in exactly this situation, having to scurry through a layover airport without time to get food. It was an easy story to craft out of the research.

A Great Story Immediately Lends To A Great Design Scenario

Once the UX team had this story, it was easy for them to craft a scenario that would help people in the same situation as Taré:

Taré’s Future Scenario

Taré is checking in for tomorrow’s flight on the mobile app. During the process, the app points out the short connection and offers Taré the option to pre-order lunch from one of Charlotte airport’s fine restaurants.

Taré selects a salad and some sides from 1897 Market’s menu, making a few dietary customizations. The app confirms the choice with Taré and charges Taré’s credit card.

The meal is ready to pick up at the departing gate, just as Taré boarding. Taré loves the convenience of having a ready-to-eat lunch during the second leg of the trip.

We Can Create A Great Scenario Without A Detailed Persona

What fascinates me about these stories is how little we know about Taré. We don’t know if this is a business trip or maybe visiting some family. We don’t know why Taré makes this trip so frequently. (Maybe Taré is dating someone long distance?)

We don’t know where Taré is coming from nor where they’re going. We don’t know their age or what nationality or race they are. We don’t even know Taré’s gender identity.

We know nothing about all the things we’d normally put into a persona. And yet, the story of Taré’s current stressful journey led to an excellent design solution. (Editors note: American Airlines announced last week they are conducting a trial at select airports where passengers can use their app to order food for gate-side delivery.)

The facts we know about Taré are quite boring. Taré lives an hour away from a regional airport, has to fly through Charlotte a lot, and often travels to places 3 hours away. That’s it.

Taré is not an interesting persona. Yet, the story has everything we need to make passengers in Taré’s situation much less stressful.

A Second Story Gives Us Contrast

In their research, the UX team saw another pattern around family travel. From this, they crafted a story of a fictional traveler Neshar.

Neshar’s Current Situation

Today, the entire household is traveling: Neshar, Neshar’s spouse, their infant, and Neshar’s mobility-challenged in-law. Neshar and Neshar’s spouse has traveled several times before. However, it’s their first time traveling with their baby. Neshar has many questions.

The baby doesn’t have its own ticket. What papers will Neshar need to get the baby through security? Can they bring baby wipes and breast milk through security? Can they bring the baby’s stroller and car seat?

When the airline says you can bring “2 carry-on items per person,” is the baby included as one of the people? (Or is the baby considered one of the carry-on items?) They’ve got 8 carry-on bags, so this will be tricky. Where might they stock up on diapers or wipes during their layover in Charlotte airport?

It’s also Neshar’s first time traveling with their in-law. While Neshar’s in-law can walk short distances with a walker, the airports seem daunting. Neshar has seen other passengers get wheelchairs and assistance in the airport, but doesn’t know how to arrange that.

The last time Neshar was in the Charlotte airport, the passengers got off the plane by walking downstairs onto the tarmac. That will be very difficult for Neshar’s in-law.

They’ll have a tight connection in Charlotte. How do they navigate with the baby and Neshar’s in-law across the huge airport? Neshar remembers electric carts, but doesn’t know how they get a ride in one.

All these questions and concerns prove stressful for Neshar. Making the seven-hour journey seem quite daunting.

The detail in Neshar’s story is enough for the UX team to craft a future scenario. The team could design something to address all of Neshar’s questions and concerns. They could create check-in functionality that arranges for assistive transportation in Charlotte and provides the baby with identifying documentation to take through security.

The Stories Are Different. The Personas Are Not.

Neshar’s story is very different from Taré’s. The details we know about the personas of Neshar and Taré are not. And those details don’t matter.

The stories are all that we required. Had we constructed user persona descriptions for Taré and Neshar, we would’ve wasted our time.

The stories themselves are very contextual. In other parts of their journeys, knowing the differences between Neshar and Taré wouldn’t matter.

Context for example, would be needed for how we should design their in-flight entertainment system. Because Taré‘s situation, as we understand it, isn’t different from Neshar’s when it comes to them how they entertain themselves during their flight. To understand more about their in-flight entertainment needs, we’d need to continue researching, looking for patterns, and creating new stories based on what we find.

Personas Are Useful, But Scenarios Are More Useful

Taré and Neshar’s stories didn’t require personas. The difference in the stories was between the activities, not the people. In fact, it’s possible Taré and Neshar are the same people, just with different types of travel. One day, traveling by themselves on a regular trip like Taré. Another day, traveling with their family in an unfamiliar way, like Neshar.

There are occasions when differences can come from people, not an activity. We see this in public policy, where two people might need a government service, but they have completely different economic situations.

For example, in the United States, Social Security benefits change based on age and how much you’ve previously paid into the system. The task of applying for benefits might be identical for two people, but their persona attributes would dictate the need for different designs.

Personas and scenarios work together to accomplish a single goal: for the team to understand how the design should adapt to the needs of different users. But whether those differences warrant a persona or not will depend on the stories involved. By starting with stories, we can get to the shared understanding we need to delivering great products and services.

Scenarios are one of the designer’s most powerful tools. Sending your team to Kim Goodwin’s full-day UI23 workshop, Using Scenarios to Solve Problems, will ensure your products push beyond your competitors by solving customer problems nobody else in your industry is tackling.

We’re making a huge promise. Here’s how we’ll keep it.

September 10, 2018

When you attend UI23, we make a promise no other conference makes. We promise to send you home a better UX professional. We guarantee it.

This promise presents a challenge: How do we design a conference that will send each person home a better UX professional than when they arrived? For 22 years, we’ve found the secret is in our full-day workshops.

Start With Critical UX Topics…

A conference like UI23 takes more than 18 months to plan. As principal curator for UI23, I spend this time talking with UX design leaders about challenges they and their team members face.

For example, many managers tell me that designing for Agile is more difficult than they anticipated. Other design leaders say they struggle to conduct enough user research for their projects.

...Then Find Seasoned Industry Experts...

With our list of critically important challenges at hand, I search for experts to lead the workshops. These experts can’t be just anyone. They need to be folks who can answer all the hard questions.

Jeff Gothelf

For example, for the topic of integrating UX design into Agile processes, Jeff Gothelf is a great choice. By working with dozens of teams over the last decade or so, Jeff has developed world-class expertise in Lean UX design practices.

For low-cost user research techniques, I sought out Cyd Harrell. At Bolt Peters, she was known for inventing clever, effective guerrilla research methods. Her recent work at 18F and Code for America scaled research in civic design.

Cyd Harrell

I continued searching for experts in 4 more critical topics. When I had our 6 experts, it was time for the hard work.

...And Build A Workshop Together...

Before the conference, I sit down with each expert presenter and we work through their workshop agenda. (That’s how we know exactly what they’ll cover in their workshop descriptions.)

I explain the questions we’re hearing from design teams. We work together to focus each full-day workshop on the hot issues and big challenges today’s UX designers face every day.

...With Lots of Opportunities For Practice...

You don’t learn something by theory alone. You’ve got to practice it. I work with each expert to craft workshop exercises that will give everyone solid practice.

For example, we’ll send Cyd’s Guerrilla Research workshop attendees to nearby South Station to conduct informal, ad-hoc interviews with travelers heading through the station. Everyone in the workshop will spend the morning preparing for those interviews, and they’ll spend the afternoon synthesizing their findings.

The best way to learn something is to do it. Practice is so critical to success.

...In A Room Full Of Others With Similar Challenges.

Our presenters aren’t the only experts in the room. Everyone who chooses a workshop does so because they’re facing similar tough challenges.

You’ll hear great questions and ideas from people who have already overcome the obstacles you’re facing. And you can help other people by sharing your experience. Each workshop forms a small community of dedicated UX practitioners that support each other, even after the workshop has ended.

We guarantee you’ll become a better UX professional. After 23 years, we’ve done it for more than 8,000 UX professionals. That makes the UI23 a conference like none other.

Don’t wait. Register today and reserve the workshops that are most critical for your work and career.

Prepare to return home a better UX professional. See you at UI23!



Here’s our guarantee: You’ll return to your work a better UX professional or we’ll refund your money 100%. That’s how confident we are. Don’t wait to register. Workshops are filling up. Register for UI23 today.

Agile Isn’t Supposed To Be UX Hostile

September 4, 2018

Design teams frequently struggle when their development organizations adopt an Agile process like Scrum. These processes seem to leave no opening for design to influence the product, creating poor user experiences when the team delivers its products.

It’s easy to blame the way Agile works. Yet, if we look back at Agile’s roots, we see that it embodies design’s core philosophies.

In 2001, 17 leaders of what became the Agile movement met in Utah and produced what is now known as the Agile Manifesto. The Manifesto boiled down the essence of good software development practice.

What we see is a strong influence of good design practice here, too. Everything in the Agile Manifesto applies to smart design.

Individuals and interactions over processes and tools.

Design leaders know the way they interact with their teams that affect the designs their teams produce. Everyone, including developers and product managers, work best when they collectively understand what the user needs and how the design can meet those needs.

As designers, we’re guilty when we’re mired in tools and processes. We forget real design happens when we work and share together. We must focus on our interactions with each other, instead of insisting our tools dictate our work.

Working software over comprehensive documentation.

This Manifesto principle embodies the show, don’t tell ethic behind great design collaboration. Sitting together and demonstrating a working idea can push a design forward much faster than any amount of specifications or non-interactive diagrams.

Having something that works is essential to getting feedback from our users. All too often we see that showing the user a screenshot doesn’t come close to learning what happens when they have a product to use, even in prototype form.

Customer collaboration over contract negotiation.

The pressure to deliver on time focuses our efforts into the negotiation of what-by-when. Delivering something our customers will use and get value from can take second priority if we let those negotiations push the wrong priorities.

Design leaders bring customers to the forefront by employing smart design research practices throughout the project. When everyone views the users and customers as a partner in the design and delivery process, everybody wins.

Responding to change over following a plan.

As we put our thinking in front of our users, we learn where we made the wrong assumptions. Solid design practice teaches us to respond to an improved understanding, keeping our practice flexible.

As the old saying goes, planning is essential, but plans are useless. We must be ready to adapt to change.

Agile and Design are Kindred Spirits

We share common principles. Agile processes and the way we design don’t need to be adversaries. We can work together.

Integrated practices, like Lean UX, can help us drive the Agile process, fulfilling the manifesto while producing products that our customers love. We can use these practices to deliver better designs throughout our organization.

Jeff Gothelf

Make Agile and Design work together in your organization. In Jeff Gothelf’s full-day UI23 workshop, Leveraging Lean UX to Lead Successful Agile Design Teams, you’ll get a deep dive in the techniques and practices for making your design team Agile. Read through the detailed workshop description to see how you’ll deliver better products.

UI23 • November 12-14 • Boston

August 29, 2018

The only UX conference to send you home a better UX professional, guaranteed.

I’ll admit it. We’ve outdone ourselves this year. We’ve created a fantastic environment for you to learn.

Look at the amazing lineup we’ve put together. Our master-level workshops are the core of our conference. You’ll have the very difficult job of choosing only 2 of our full-day workshops during the Conference. On the first day of the conference, you’ll choose from 1 of these full-day workshops.

Monday, November 12

Kim Goodwin

Kim Goodwin

Using Scenarios to Solve Problems

Our most popular workshop ever. Kim will show you how to ensure you’re building the right product. You’ll leave with a full toolbox of the most effective scenarios and persona techniques.

Jeff Gothelf

Jeff Gothelf

Leveraging Lean UX to Lead Successful Agile Design Teams

Ready to change the way Agile is done at your organization? You’ll leave this workshop with the latest Lean UX design methods.

Brian Suda

Brian Suda

Successful Storytelling Through Data Visualization

Move beyond boring words and numbers. Brian will show you how to bring out your data’s deeper meaning and insights by applying great storytelling visualization skills.

Tuesday, November 13

We don’t want you to miss hearing wisdom from any of our 6 incredible world-class experts. We’ve assembled a Featured Talks day so you can hear from all of them.

You’ll expand your design knowledge as each expert shares their experiences tackling hard challenges. Come away inspired, empowered, and confident to lead better design efforts inside your organization.

Plus, I’m delivering a brand new keynote about a new way to look at the field of UX design and the work we do. You’ll see where you are today, where you’ve been, and the great adventure you have ahead of you. Forever change how you think about your career, for the better.

Wednesday, November 14

On the last day of the conference, you’ll once again get deep into 1 of these full-day workshops:

Nathan Curtis

Nathan Curtis

Building Scalable Design Systems

Last year’s highest-rated workshop. Nathan will show you how to develop a cohesive cross-product experience with defined standards and workflows throughout your organization.

Cyd Harrell

Cyd Harrell

Low Cost Guerilla User Research

You can get the research answers you need, quickly and inexpensively. Cyd will show you how to build a team-wide deep understanding of what’s best for your customers.

Jared Spool & Dana Chisnell

Jared Spool & Dana Chisnell

Designing for Delight: Transforming Your Designs from Good To Great

Delight your users with a great design. Explore Jared and Dana’s framework and solid techniques to deliver your users and customers pleasure, flow, and meaning.

Go Home A Better UX Professional, Guaranteed

For 23 years, our annual UI Conference has been the place seasoned designers, researchers, product managers, and content strategists have gathered to become even better UX professionals. More than 8,000 professionals have returned from this conference ready to tackle their organizations’ biggest UX design challenges.

Every past attendee went on to deliver products and services their users loved and customers raved about. You can, too.

We guarantee it. If you don’t go home with better skills and new techniques, we’ll refund your money, no questions asked. How’s that for confidence that you’ll become a better UX professional?

Don’t Wait! This conference always fills up.