By The Quick

Home

What is a Friction Log?

What is a Friction Log?

What is a Friction Log

A Friction Log is a write-up of the complete user experience while executing a target workflow. The log captures the user's thought processes including what they intended to do, why they clicked or took whatever action they did, anything that delighted them, and most certainly any pain points or confusion. Imagine the user does these tasks live and talks out loud while doing them...some of the points may seem minor but they are authentic and provide insight into how developers think.

Important: Friction logs are part of a continuous improvement philosophy that we can always make anything better than it is today.

What it's NOT

  • ❌ A friction log is not meant to list out just warts and rough edges.

    ✅ it's meant to also highlight awesome parts of the workflow.

  • ❌ A friction log is not meant to be a whiner's rant of problems.

    ✅ it's meant to be constructive.

  • ❌ A friction log is not meant to be a dump of Jira or Linear issues.

    ✅ it's meant to provide context as a developer tries to complete a specific workflow.

  • ❌ A friction log is not meant to be competitive.

    ✅ it's meant to teach developer empathy.

Who cares

SaaS companies care

...because the DevX (Developer Experience) team knows that developers are allergic to marketing and adore authentic and delightful products.

...because the leadership team cares about customer acquisition cost, conversion rate, and customer funnels.

...because the marketing team knows that amazing user experience helps drive adoption and fuels product-led growth.

...because the community knows that the best platforms are those that are developer-friendly, frictionless, and fun.

In the age of data analytics, a company may be using Amplitude, Mixpanel, Google Analytics, or Heap.

analytics src: https://userguiding.com/wp-content/uploads/2020/09/product-analytics-tools.jpg

These products enable them to track high-level metrics like completion rates, where users drop in the funnel, etc., and there's probably a data analytics team looking at the data to make forecasts and identify trends.

But those metrics don't answer the why: Why aren't developers completing the quickstart? Why don't they love the product? Why are they dropping off and not coming back? Why does it appear to take them 5 hours to complete instead of 5 minutes? Understanding the answers to those why questions is precisely the motivation behind a friction log: it should get very specific to describe the developer mindset, what is working well, and where the rough edges are. The friction log is meant to provide insight into how a developer experiences every step of the getting started experience.

Whoever is taking action on the friction log should not dismiss any of them as just working as designed or user error. Every comment should be tracked in a discrete issue so it can be critically assessed to determine what actions to take. Those actions may include:

  • Enhance the product, e.g., it took 3 steps to do something but it really should be 1.
  • Add explanations into the product, e.g., instead of displaying just a textbox, handhold a bit and explain what kind of value is expected.
  • Extend the documentation, e.g., offer supporting explanations and screenshots. (pssst, developers don't read the concepts guide when they are doing a quickstart)

How I choose a topic

For this blog, I write friction logs about the "Getting Started" experience of various products in the early phase of a user's adoption lifecycle. Some of the criteria I use for for choosing a topic/technology to write on:

  1. The SaaS is free to try, whether it's a free tier or trial period, as long as no credit card is required to get started
  2. There is a quickstart or in-product tutorial

If you have a suggestion on a tech I should tackle, please reach out via Twitter @bythequick.

Writing your own

A friction log can be written on any topic by anyone: someone in-house, a member from another team (field, support, etc), any focus group, a community member, a customer, a friend, or whoever. I'd even suggest that managers within the SaaS company should take advantage of new employees joining their teams, and make it part of the employee's 30-day onboarding plan to write a friction log from their fresh perspective.

Friction logs are only useful if they are good, whereby "good" means "actionable". They should highlight all the things that make or break the developer workflow. There are no strict rules for it, but there are some attributes to take into consideration.

👎 A less actionable friction log:

  • is too vague ("It didn't work")
  • nit-picks too much ("This button would look better as 'crimson' red instead of 'candy' red")
  • highlights just problems (constant whining isn't helpful)
  • praises just good things (green path doesn't help identify or improve rough spots)
  • skips steps in the workflow
  • doesn't identify what was expected ("Not what I wanted to see")

👍 A more actionable friction log:

  • captures all observations: the awesome, the good, the bad, the ugly
  • stays focused on a target workflow that is driven by a specific use case
  • explains the thought process and intention behind each step ("The screen went to X but I expected Y")
  • includes errors, both product errors and user errors
  • requires humility on the author's part, e.g., to be able say "I don't understand the intention behind this button...", or "I'm lost"

And yes, I hope this site encourages more people to write friction logs on their own!

Resources