Hi, I'm Bob Ricca.Head of Product Design at ThreatQuotient.

UX mentor at DesignLab, ex-adjunct at Philadelphia University, ex-UX at AWeber.


Which design software should I use?

Design Leadership UX

Photo by Pietro Mattia on Unsplash

The battle to get your subscription dollars.

For the last 8 months, I’ve been spending evenings working as a UX mentor at DesignLab.

It’s a really fun gig. Talking about design comes easy and nothing makes me happier than helping someone conquer a new concept or rise to the next level in their career.

During my sessions, the same question pops up repeatedly…

A friend of mine told me everyone is switching to <insert brand> design software, do I need to switch?

It seems to be a source of stress for new designers.

• • •

You’re being sold to

If you subscribe to design newsletters, undoubtedly your inbox has been packed to the brim with everything related to design systems as the sales teams at Adobe, Sketch, Figma, and InVision (the big four) duke it out to get your subscription dollars.

Before that, you were flooded with tons of articles about design sprints, design thinking, and tons of workshops on how to facilitate these types of sessions.

It’s not a bad thing.

These companies are advancing the way we think about design. Both topics above are staples in a solid design practice. And to be frank, the tools we have at our disposal these days are pretty fun to use. It’s easy to get caught up in all the hype.

As a new designer, it might not be quite as apparent that a lot of these case studies are marketing campaigns targeted to sell you their products.

• • •

My Advice: Don’t stress over tools

It used to be that designers were forced to use an all encompassing graphics program such as Photoshop or Illustrator.

The biggest advantage of using these pieces of software was that they could cater to any number of use cases.

The downside was that because of they were so robust, learning them was intimidating and they fell short on specific workflows. Once realized, this created a boom in the design tool market where each company is trying to sell you their suite of software.

The reality is:

  • Each of “the big four” has a team of talented people continuously working to improve their software.
  • These pieces of software are very similar at a high level. After learning one, the learning curve is greatly reduced.
  • Right now you’re witnessing a race. If one tool offers something new of value, I’ll bet you dollars to donuts that the others will have an update soon thereafter.
  • There are more free resources online than ever before. In the case that you landed a job where a team uses a different tool, you can get up to speed quickly.
  • Although the tools are somewhat standardized, each team uses them differently. As part of the onboarding process of your new job, someone will likely be excited to show you how they use the software.

So with that, I’d say:

Pick whatever tool you enjoy using the most and shift your focus towards refining your craft. Software comes and goes, the underlying thought processes and design principles are timeless.

Roles and Expecations

Case Study Design Leadership

Recently I encountered a scenario between two frustrated colleagues.

In one corner, I have my boss — who runs all of engineering. He is super intelligent, he’s taught me a ton, and I have nothing but respect for him. For the sake of this article, we’ll call him Jim.

In the other corner— I have a direct report of mine. A product owner who is extremely talented, smart, and driven. For the sake of this article, we’ll call her Jane.

As in most start up environments, the lines between roles is often blurry. Most people are doing more than their fair share.

• • •

It’s a Wednesday afternoon. Jim and I are having our weekly sync, when the topic of Jane comes up. Jim is concerned that Jane is stretched too thin. His gut tells him that she may be having trouble focusing and has a problem saying “no” to others who are piling work on her plate.

During lunch that day, he had pulled her aside to share his concerns directly. He had nothing but good intentions and wanted me to know that the conversation took place.

• • •

It’s now Friday afternoon, time for Jane’s weekly sync. During our call, she mentions her meeting with Jim. She expressed frustration… not around getting direct feedback, but because she felt her work and intentions were misunderstood.

• • •

I personally take a bit of responsibility here. In the past, Jim had made comments to me about Jane’s focus. Knowing that Jane does a phenomenal job, I did my best to address his concerns… however, I guess it didn’t resonate.

I have an open and honest relationship with both of these people. I’m a straight shooter and I can definitely appreciate when other people are trusting enough to give me critical feedback as well. It’s a healthy dynamic.

I owe it to both of them to fix this…

At ThreatQuotient, one of our core values is “assume goodwill”.

Simply put… you’ll find that most people are trying to do what they feel is right with the information at hand.

In times of stress, it’s easy to fall into an unproductive spiral of negativity.

A lot of the time, this negativity comes from two root causes:

  • Lack of information
  • Misaligned expectations

In this particular situation both things were apparent.

• • •

How can we fix this?

I have a solid grasp on what Jane does. This doesn’t mean that others do.

I felt like it would be a good use of our time to tackle this head on…

Jane and I spent a half hour creating a document that outlines the following:

  • The high level goals of her position
  • Who she works with on a day to day basis and what she does

As we discussed each item, it became more and more apparent just how big her role was, how critical she was to the success of other teams, and how great of an asset she is to our company.

It illuminated the following things:

  • There are areas where, if she didn’t take action, nobody would
  • There are times where others would rope her into conversations or projects she didn’t need to be. She was generally a good sport about it, but the extra work was taxing and a source of stress. She also wasn’t thrilled that it would circumvent our process.
  • Her role isn’t cookie cutter. Because she works with third party vendors, she needs to take on a broader spectrum of tasks in order to be successful.

You see… it just so happens that a Product Manager, Jane’s counterpart in the product org, had recently left our team. This resulted in a bunch of orphaned work, things that still needed to be done, with no dedicated person to do it.

It also happens to be that our team structure is still maturing. We (I) haven’t pushed to refine the responsibilities within Jane’s role and therefore they are up for interpretation. Furthermore, the role of “Product Owner”, at our company, has a lot of overlap with the role of a “Product Manager”.

More thoughts on that at a different time 🙂

• • •

Resetting Expectations

The following week I set up a meeting between myself, Jane, and Jim. During this meeting we talked through each item on that document in detail.

At the end of the meeting we had reached a consensus:

  • Jane was happy that she was able to represent the true amount of work that went into her role. She was also able to shine a light on where she might need some help.
  • Jim was now privy to all of the hard work she put in on a daily basis. He was also able to provide some coaching on how to handle specific scenarios.
  • I was happy that the meeting went smoothly — (and didn’t backfire, haha). The air was cleared. Each party was able to empathize with each other’s perspective.

It was a win-win situation.

• • •

Summing it up

As I navigate what it means to build and lead a team, I find that the skills I’ve picked up from my background in design have helped me tremendously.

In this particular case, it was taking time to thoroughly understand the problem space (understanding perspectives, observing, and forming my own opinion), reflecting on my end goals (to alleviate my boss’ concerns and have an employee that feels valued), and systematically chipping away at the problem (taking small logical steps towards a collective understanding).

As we continue to mature our team, refining our roles and responsibilities is one step closer towards having alignment on what it means to be successful. If we can’t clearly articulate what our success looks like, then why should we expect others to know.

It’s another chance for misalignment.

Stop Being Clever – A UX Case Study

Case Study UX

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.

3 Amigos: a foolproof exercise for more thought out designs — a UX case study

Case Study Product Design UX

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.

Thanks Darren!

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.

North Star: Revisiting Guiding Principles In Product Design

Product Design

Photo by Bogomil Mihaylov on Unsplash

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.

Create Something Remarkable


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?



  • 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?


  • 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?


  • 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?