Recently I subscribed to a Slack group called “Today’s Question”.

Every morning in this group, a new question is posted for Product Managers and UX Designers from all over the world to answer.

The questions are open ended and all over the map:

• Beyond the theory, how have you taught “story” splitting in a way that stuck?
• How has your team’s use of Slack changed communication patterns?
• Have you tried informal peer mentorship programs? What worked? What didn’t?
• How do you make sure your company is prepared for the upcoming release? Communication? Meetings? Rituals? Process?
• Etc…

These types of topics resonate with me. I love trying to figure out how I’d attempt to answer each one and reading over others responses. It’s inspired me to reach out to others, read more, and write about my own experiences – including this article 🙂

Just before the holidays, the following question came up:

“How have you sold skeptical team members on the value of usability testing?”

This topic was actually fresh on my mind from earlier that week.

You see.. My brother-in-law is currently building a team for an independent UX research agency (Skopos Nova) based out of Cologne, Germany.

From his experience, teams in Germany aren’t as bought in on the concept of “UX” as American companies. After most external presentations he gives, he is often approached with a question like the one above.

So, how did people answer it?

Most had the standard response:

“Show, Don’t Tell”.

It’s not wrong, but you know… it’s a UX canned response straight from the UX 101 textbook. …zzzzzzz…

Others answered:

“Show the team some clever observations, something they never realized and would have never encountered without usability testing”.

Ok. I guess that could work too.

My Answer:

Be the opposite of clever… show the obvious.

Allow me to explain with a story:

Imagine you work with an engineering team.

Both you and the team are very close to the product. You both know where the bugs lie.

The team has outlined each bug in a ticket. Time after time again, the bugs are de-prioritized in favor of a new feature or deadline to meet.

Now image that there are also multiple stakeholders that influence the product roadmap. These stakeholders are not as intimate with the product as the team who has built it.

Then enters a UX designer.

Instead of attempting to highlight clever insights, he or she does a listening tour throughout the company to gather a list of common customer pain points.

Chances are, after talking with multiple departments, patterns will emerge. Probably for good reason.

The UX designer seeks to validate the top pain points and in the process records videos of customers struggling with each one.

These video are then presented later as part of a presentation to the company.

A few things happen:

• Product managers and other stakeholders now attach a painful customer experience with a bug that the team has been wanting to fix. They had no idea the problem was so bad and decide “maybe we should fix this”.
• The engineering team is glowing. They finally get to fix bugs that have been weighing on them for quite some time. When asked about UX the answer is: “I love UX. We should usability test everything!”.
• The positive attitudes of the engineering team is noticed by upper management who thinks “Wow, these guys are really fired up. This is great! Maybe we should do this more regularly.”
• Other teams take notice and start asking “What is the plan to start testing our project?”

What about the skeptics?

They need to make a choice:

• Go against the grain
• Go along for the ride

I’ve personally seen this happen a number of times. The momentum and positive impact of user testing for a team is truly eye opening and exciting.

Building products fascinates me.

Everything about it:

• Validating that you’re solving the right problems
• Defining the “what” and “how”
• Working in the trenches with an engineering team
• The thousands of micro-decisions
• And most importantly… Seeing someone get value out of something you’ve poured your heart into

There are few things like it.

Working in an agile development environment, I always found it odd when designers don’t care to be part of the scrum team’s daily conversations.

It’s not that these designers are less dedicated, less talented, or less humble. They just feel their time is better spent elsewhere. That’s totally ok.

However, I’d argue that it could be a missed opportunity.

• • •

Does this sound familiar?

A user story gets accepted into a sprint. A few days pass before it’s picked up by the team. A front end developer starts working on his piece while the backend developer is working on hers. Once completed, the story gets passed over to QA. The QA engineer doesn’t want to pass the story because after talking to the UX designer, they expected the interface to behave slightly different. The developers push back because the work being discussed was never outlined in the original ticket. Frustrated, the team decides it’s too late to pivot to another solution and the card is bumped out to the next sprint.

This happens all the time and it’s a shame. It’s really easy to avoid.

• • •

Enter The 3 Amigos

A product owner, software engineer, and a QA engineer walk into a bar…

The 3 Amigos is an exercise born out of automated testing. A product owner, software engineer, and QA engineer sit down at the beginning of each sprint to outline a set of scenarios describing how a feature should work.

Because everyone is involved, the risk for miscommunication is low.

An example:

Let’s pretend we are working on an interface where users can apply a “Score” filter to their search results.

A scenario might look like this:

• I click on the Score filter and a dropdown appears showing a slider.
• “1” and “10” are selected by default. The submit button is disabled.
• I then drag the left slider to “6” making the score 6 to 10.
• The text input below updates to display “6” and submit button is now active.
• I click submit and the dropdown closes.
• My search results are now updated.

A Simple Exercise For Sharper Designs

Start Writing Scenarios

First, instead of 3 amigos, let’s make it 4 amigos.

The UX designer should be the one driving the conversations about interaction design.

Second, why wait for the work to be accepted into a sprint?

Writing out scenarios as I design interfaces has made me a better designer. It’s a quick way to test that the proper UI paradigms are being applied, things are flowing properly, and all states are being considered with minimal overhead.

Scenarios also help identify any specifics I’d like the developers to be aware of:

• When portions of the page should reload
• How form elements should act
• Notifications / visual queues to be used and when

• • •

Effectively communication is at the heart of any successful team and writing scenarios is an easy way to outline design intent. Ever since we’ve introduced them, the amount of stories failing QA during the sprint has been dramatically reduced. The team absolutely loves them. Everyone understands what they need to bring to the table and it promotes healthy conversation and team dynamics.

Recently I came across a document I created years ago. From a retrospective point of view, I thought it was worth sharing.

• • •

The Year is 2014

I just accepted my first remote role working at ThreatQuotient. It was an exciting time for the company. Ryan and Wayne, the two founders, had received seed funding and were finally able to build a team.

At that point it was five of us:

• Wayne and Ryan (the company founders)
• Two talented full stack developers
• A sales guy
• … and me (doing anything design related)

Working at ThreatQuotient was a significant opportunity in my eyes. It was my chance to influence the direction of a product in its early stages. In hopes of learning from the advice of others, in my spare time I was absorbing anything I could about UX and product design. I wanted (and still want) ThreatQuotient to be successful. Although not everything is in my control, I still to this day correlate my professional value with the ability to have a positive impact on the company.

Within my first few weeks of employment, I created a Product/UX space in Confluence. Inspired by one of my personal heroes (Des Traynor @ Intercom), I started by outlining and rallying behind a list of principles I hoped would guide me to making smart product decisions.

The content below is in no way my own, but, it is timeless and valuable advice.

Product Guiding Principles

When analyzing a feature within the ecosystem of a product, ask the following:

• Does this feature fit the end vision of the company?
• Is the reward of using this feature greater than the effort we’re asking our users to make?
• Does this benefit all of our customers?
• Will it grow our business?
• Will this feature matter in 5 years? (or are we just building today’s trend)
• Is this a forward step for us? (or is this leveraging yesterday’s technology)
• Will it generate new engagement?
• If it succeeds, can we support it?

These reasons alone do not justify shipping a feature:

• We’ve talked about this feature forever
• We’ve worked on this feature for so long
• We can do this pretty quickly
• Generating value for customers is the end goal.

When assessing the value a feature provides for customers, consider the following:

• A feature needs to be a solution to a real problem that exists today
• It needs to be easy to build, test and refine
• It needs to be easy to explain to a business
• It needs to be easy to adopt by companies of all sizes

When looking at existing features, ask the following questions:

• How many customers are currently using this feature?
• How often do they use it?

All things on the product roadmap should fall under one of these categories:

• Improving a feature
• Getting more people to use a feature
• Getting people to use a feature more
• This is a new feature to support a new workflow

• • •

Four Years Later

Yesterday, I rediscovered this document.

It makes me think about how the market has evolved and all of the product decisions we’ve made over the last four years. I think about the customers we’ve had and how they have influenced our roadmap. I think of the new faces on the team and how we’ve evolved our processes.

This post is a personal reminder to revisit these principles.

It doesn’t have to be every day, or every week. But every so often it’ll do me good to revisit these basic principles and challenge why I’m doing what I’m doing.

Motives, emotions, goals, and expectations are at the core of every customer experience. Meeting these needs is a sure fire way to create a positive experience. Exceeding those needs leads to creating something remarkable.

Lately I’ve been working on a series of iterative projects aimed at improving a customer’s first impression of AWeber. The ultimate hope is that through education and guidance customers will set up their accounts more thoroughly, gain more momentum, and therefore be happier with their purchase of our service. Not only do customers see the benefit of using email marketing for their business but they become invested. They want to help us build a better product.

Up to this point we’ve conducted numerous interviews diving into what it means to “set up” your account. We’ve worked hard to expose what our customers’ perceive as end goals combined with the actions they have actually taken to complete them. We then isolate this information into essential steps, best practices, and motivators based on the customers desired outcome. A very literal approach.

So what about the not so literal?

THE UNDERTONES OF EXPERIENCE

Motives

• What events led them to where they are today?
• What are they hoping to gain out of using your software?
• How can we fuel these motives to keep customers moving forward?

Emotions

• What events led them to where they are today?
• What are they hoping to gain out of using your software?
• How can we fuel these motives to keep customers moving forward?

We’ve found that a lot of customers pursue email marketing as part of a broader set of goals. Not only are they investing in our software, they are investing the commitment to better market their business.

Just like any major purchase in life, buyers actively seek to validate their purchasing decision. How as designers can we boost their confidence, reassure their commitments, and keep them engaged with that same vigor they had from day one?

Goals

• What events led them to where they are today?
• What are they hoping to gain out of using your software?
• How can we fuel these motives to keep customers moving forward?

Using a product has a lot of similarities to playing a game. The rush of winning is a powerful emotion that fuels motivation to play again. Everybody likes being good at something. A customers perceived success has a direct impact on how they feel about your product.

The Key Ingredient: Something Unexpected

Go the extra mile.

After understanding the core concepts behind what drives an experience the real question is: How can we take our designs a step further and exceed customers expectations?