├── .gitignore ├── README.md ├── friction-log-template.md ├── friction-logging-the-dev-feedback-experience.pdf ├── how-we-use-friction-logs-at-stripe.md └── images ├── charlie-headshot.png ├── cover.webp ├── image-1.jpg ├── image-2.png ├── image-3.png ├── image-4.jpg └── mike-headshot.png /.gitignore: -------------------------------------------------------------------------------- 1 | # Created by https://www.toptal.com/developers/gitignore/api/macos,visualstudiocode,windows 2 | # Edit at https://www.toptal.com/developers/gitignore?templates=macos,visualstudiocode,windows 3 | 4 | ### macOS ### 5 | # General 6 | .DS_Store 7 | .AppleDouble 8 | .LSOverride 9 | 10 | # Icon must end with two \r 11 | Icon 12 | 13 | 14 | # Thumbnails 15 | ._* 16 | 17 | # Files that might appear in the root of a volume 18 | .DocumentRevisions-V100 19 | .fseventsd 20 | .Spotlight-V100 21 | .TemporaryItems 22 | .Trashes 23 | .VolumeIcon.icns 24 | .com.apple.timemachine.donotpresent 25 | 26 | # Directories potentially created on remote AFP share 27 | .AppleDB 28 | .AppleDesktop 29 | Network Trash Folder 30 | Temporary Items 31 | .apdisk 32 | 33 | ### macOS Patch ### 34 | # iCloud generated files 35 | *.icloud 36 | 37 | ### VisualStudioCode ### 38 | .vscode/* 39 | !.vscode/settings.json 40 | !.vscode/tasks.json 41 | !.vscode/launch.json 42 | !.vscode/extensions.json 43 | !.vscode/*.code-snippets 44 | 45 | # Local History for Visual Studio Code 46 | .history/ 47 | 48 | # Built Visual Studio Code Extensions 49 | *.vsix 50 | 51 | ### VisualStudioCode Patch ### 52 | # Ignore all local history of files 53 | .history 54 | .ionide 55 | 56 | # Support for Project snippet scope 57 | .vscode/*.code-snippets 58 | 59 | # Ignore code-workspaces 60 | *.code-workspace 61 | 62 | ### Windows ### 63 | # Windows thumbnail cache files 64 | Thumbs.db 65 | Thumbs.db:encryptable 66 | ehthumbs.db 67 | ehthumbs_vista.db 68 | 69 | # Dump file 70 | *.stackdump 71 | 72 | # Folder config file 73 | [Dd]esktop.ini 74 | 75 | # Recycle Bin used on file shares 76 | $RECYCLE.BIN/ 77 | 78 | # Windows Installer files 79 | *.cab 80 | *.msi 81 | *.msix 82 | *.msm 83 | *.msp 84 | 85 | # Windows shortcuts 86 | *.lnk 87 | 88 | # End of https://www.toptal.com/developers/gitignore/api/macos,visualstudiocode,windows -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Friction Logging Toolkit 2 | 3 | If you're a product developer, you know that frictionless user experience is key to success. Being able to effectively capture and distill feedback from end users is tricky, but essential. That's why we've developed a friction logging toolkit, to help you get the most out of your user feedback. 4 | 5 | This toolkit includes a friction logging template, which you can use to track user feedback and identify areas of friction. We also include some resources to get you started with friction logging. 6 | 7 | The resources here are a jumping-off point - they are not meant to be prescriptive, but rather to give you some ideas and inspiration for how you can use friction logging to improve your product development process. 8 | 9 | ## In this repo 10 | 11 | - [The developer feedback experience: friction logging (slides)](friction-logging-the-dev-feedback-experience.pdf) These are Slides from [Mike Bifulco's](https://mikebifulco.com) talk at Fintech Devcon 2022. 12 | - [friction-log-template.md](friction-log-template.md) is just what it says on the tin - an example / template document for writing friction logs 13 | - [How we use friction logs to improve products at Stripe](how-we-use-friction-logs-at-stripe.md) a markdown version of the Stripe DevRel team's article on Friction Logging 14 | 15 | ## More reading 16 | 17 | - [How we use friction logs to improve products at Stripe](https://dev.to/stripe/how-we-use-friction-logs-to-improve-products-at-stripe-i6p) 18 | - [Frictionlog.com](https://frictionlog.com/) 19 | - [An introduction to friction logging](https://developerrelations.com/developer-experience/an-introduction-to-friction-logging) 20 | 21 | ## Contributions welcome 22 | 23 | What does your team use for friction logging and collecting user feedback? Have tools or best practices you'd like to share with us? [Pull Requests](https://github.com/mikeb-stripe/friction-logging-toolkit/pulls) are welcome! 24 | -------------------------------------------------------------------------------- /friction-log-template.md: -------------------------------------------------------------------------------- 1 | # Friction Log: Your title here 2 | 3 | **Author:** Mike Bifulco 4 | 5 | **Date:** 10-10-22 6 | 7 | **Size:** S | M | L 8 | 9 | ## Context 10 | 11 | I recently had the task of setting up a new printer for my office. The process was relatively simple, but there were a few things I had to keep in mind in order to get the printer up and running smoothly. This is a summary of my experience, from choosing a printer, to unboxing it, installing it on my machine, and testing it out with a few sample prints. 12 | 13 | Overall, the process was reasonable, although I did find room for improvement in the initial software setup experience, and installing/replacing new ink cartridges. 14 | 15 | ## Pros 16 | 17 | - Documentation was clearly organized 18 | - The setup process only took a few minutes 19 | - The docs website was mobile-friendly 20 | 21 | ## Cons 22 | 23 | - The docs can feel a bit long - Video tutorials would have been helpful 24 | 25 | ## Stream of consciousness 26 | 27 | When I unboxed the printer, I wanted to set it up right away, so I headed to the [website](https://example.com), but struggled to find the link to the docs for a few minutes. When I found it though, I got the device connected to my WiFi network pretty quickly. The instructions were very clear and easy to follow. 28 | 29 | I then tried to print a document from my laptop. The process was very simple, and similar to other printers that I've used in the past, which was a good experience. Not having to learn a new workflow for a device such as a printer is always good. 30 | 31 | Them I moved on to trying to print a document from a USB sticl. This process was a little more confusing. The UI on the screen of the printer shows icons that are not strightforward to understand 32 | 33 | (...etc) 34 | -------------------------------------------------------------------------------- /friction-logging-the-dev-feedback-experience.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/friction-logging-the-dev-feedback-experience.pdf -------------------------------------------------------------------------------- /how-we-use-friction-logs-at-stripe.md: -------------------------------------------------------------------------------- 1 | # How we use friction logs to improve products at Stripe 2 | 3 | **Authored by** [Mike Bifulco](https://twitter.com/irreverentmike) and [Charlie Gerard](https://twitter.com/devdevcharlie). 4 | 5 | _This article was originally published on [dev.to](https://dev.to/stripe/how-we-use-friction-logs-to-improve-products-at-stripe-i6p)._ 6 | 7 | Friction logging is a practice that can be used by engineering teams building products to track and improve upon issues that users experience while using a product. The goal of friction logging is to make a given product better for everyone involved. End users and developers get a product that delivers value more directly, the team building the product gets a more attached, happier user base, and salespeople have an easier time showing value to potential customers. 8 | 9 | At [Stripe](https://stripe.com), we use Friction logs to share feedback with product teams about the products we build. This is at least part of the mission of our DevRel team. Our goal is to be the voice for devs who use Stripe’s products to build their own. We often serve as the liaisons between these worlds: the devs using our products, and the engineering teams building them. 10 | 11 | Stripe also encourages all employees to actively participate in giving feedback. During onboarding, every new Stripe is given training on how to give feedback on products, and the process for creating friction logs. 12 | 13 | ## Parts of a friction log 14 | 15 | ![Screenshot including the redacted first page of a 3 friction log documents](/images/image-1.jpg) 16 | 17 | ### Context 18 | 19 | The context describes the persona of the person reviewing the feature, as well as what they were trying to accomplish. For example, if you are reviewing a new API endpoint and this is your first time using the feature, it is important to mention this as part of your persona. You can try to write the context by answering the following questions: 20 | 21 | - How experienced are you with the feature? 22 | - What were you trying to build? 23 | - Which parts of the feature is this friction log about? 24 | 25 | Below is an example of context for a friction log about setting up a new printer: 26 | 27 | ![Screenshot of the context section](/images/image-2.png) 28 | 29 | ### Pros and cons 30 | 31 | Once you’ve written the context, you can move on to summarizing the pros and cons you’ve experienced. 32 | 33 | This part should be a list of bullet points clearly stating the parts of the feature or experience that you enjoyed or thought were useful, and the ones that you think could be better or did not match your expectation of how the feature should work. 34 | 35 | ![Include sections for Pros and Cons near the top of your friction log](/images/image-3.png) 36 | 37 | ### Detailed stream of consciousness 38 | 39 | Finally, the detailed stream of consciousness is the part where you should be giving feedback without necessarily following a specific structure. You should write it as you are going through your experience trying to use the feature. It can include anything you think could be useful to the team, no matter how small. Feel free to add screenshots, GIFs showing your interaction with the tool, links, etc. 40 | 41 | We are all different in how we use tools, our level of knowledge and expertise, the applications we’re trying to build, so any piece of feedback is valuable to help improve a product. 42 | 43 | To give you an idea, here’s an example of how this part of the friction log might look: 44 | 45 | ![Screenshot of Stream of Consciousness section](/images/image-4.jpg) 46 | 47 | ## Framework for a great Friction log 48 | 49 | ### Share size (S/M/L) up front 50 | 51 | **Small** - The friction log is small and manageable. It can be completed in a reasonable amount of time without feeling like a burden. 52 | 53 | **Medium** - The friction log is of a moderate size. It may take some time to read, but it is not excessively long. 54 | 55 | **Large** - The friction log is large and may take some time to consume. These likely capture larger user journeys, and show a holistic view of a process, as opposed to a small bit of confusion with a single feature. 56 | 57 | ### Make the journey clear 58 | 59 | The friction log should make it clear what journey the user is taking, and what steps they are taking along the way, as well as context on their persona ("I'm brand new to collecting payments on the web", or "This is the 3rd major release of my product, but we need to add support for taking payments in Canada"). Additionally, The log should be easy to follow so that the intended audience can understand it -- whenever possible, use language that your product teams and stakeholders will understand without having to go do research of their own. 60 | 61 | ### Highlight both joy & frustration 62 | 63 | While it is critical to share opportunities for improvement in a product, it is also extremely valuable to share what is going well. This helps to build trust with your engineering team, and can be a good reminder that you all share the same goal: making the product as good as it possibly can be. 64 | 65 | ### Be illustrative 66 | 67 | Wherever it may be helpful, provide screenshots, videos, or other visuals to help explain the process you’ve undertaken, and the real experiences you’ve had. This may take the form of a link to a developer screencast for longer friction logs. 68 | 69 | ### Describe issues objectively 70 | 71 | This is where emotional intelligence is critical. Avoid using emotionally loaded language, and instead describe the issues objectively. Something like "I got confused between steps 6 and 7, and went back to this docs page to look for what I missed" is far more helpful than "I wasted 2 hours on this, it's so bad!". 72 | 73 | ### Share your feedback broadly 74 | 75 | At Stripe, when a friction log is completed, it is shared to an email list that includes the entire company, as well as with the specific team working on the feature or product being highlighted. This takes advantage of the network effect: when everyone can see your feedback, it’s more likely that you'll start a conversation with a broad audience of affected parties. 76 | 77 | You may find that there are people who actively disagree with your perspective - don't fret, this is usually a good thing! Exposing your friction log to people with a diversity of experience and background means that any suggested changes to your product will be more considerate of a larger userbase. 78 | 79 | ###Follow-up! 80 | 81 | It's also good practice to follow up directly with people who may be tasked with coming up with fixes related to your friction log. Keeping an open dialog is important - it helps ensure that feedback is given and received in good faith, and that the outcome of your work is a meaningful solution (even if it isn't implemented right away). 82 | 83 | **This is where the magic happens.** All your work in crafting a great friction log is worthless if you don’t follow through and make sure that it has an impact on the product your company is building. Making sure that your log results in the creation of new feature requests and bugs is a good starting point - do your best to be a steward for these tickets after their creation, so that they are prioritized thoughtfully in your team’s backlog. 84 | 85 | The last bit of follow up comes after the implementation and release of updates to the product: tell the world! Update docs and release notes with the new changes, and follow up directly with affected users wherever possible. This is your opportunity to show them that your team is working hard to make things better for them. Let them know that you built something because of them, and that you’re always open to more feedback. This creates attachment and loyalty, and is the virtuous cycle that great product teams strive for. 86 | 87 | ## On giving feedback 88 | 89 | A friction log is essentially a detailed piece of feedback, so to ensure that it is helpful and received well, there are a few important points you need to keep in mind. 90 | 91 | ### Emotional intelligence is important 92 | 93 | Emotional intelligence encompasses self-awareness, social awareness, empathy and relationship management. Writing a friction log focuses on your personal experience with a feature or product, however, you have to keep in mind that it will be read by people who have put a lot of time and effort into building what you are using. 94 | 95 | Try to put yourself in their shoes and avoid using language that isn’t very considerate. For example, instead of saying something like “This is by far the worst API I’ve ever used”, which is not only rude but also unhelpful, you could change it to “I’ve struggled using this API because X, Y, Z”. This way, your feedback changes from a general comment to one more focused on your personal experience, and it is more helpful to explain what you struggled with so the team can take action to make improvements. Additionally, try not to use the pronoun “you” to address your feedback. Instead of saying “the API endpoint you implemented isn’t clear”, you could say “This API endpoint was a bit unclear to me”. This focuses your comments on the feature itself, instead of whoever implemented it. 96 | 97 | ### Trust is a critical ingredient 98 | 99 | When giving any kind of feedback, trust is very important. In general, your teammates want you to do well and you should have a common goal of making the experience better for your users so, when receiving feedback, you should know it comes from a place of care. However, if your company doesn’t have a great collaboration culture or if you only recently joined, it can be difficult to have this sense of trust. Before you try to implement friction logs as part of your process, make sure that you get to know your team members. If necessary, schedule calls to go through your friction logs with people so they can understand the state of mind you were in when you wrote your feedback. 100 | 101 | ### Giving feedback is hard; receiving it is even harder 102 | 103 | A bit earlier in this post, I talked about emotional intelligence and how you should put yourself in other people’s shoes when writing your friction log. This can be a difficult process when the feedback you need to give is not the most positive. However, remember that receiving feedback is even harder. If you’re on the receiving side, try to detach yourself from what you are reading and remember that this is an opportunity to improve. If this is not something you are used to doing, it can be a bit difficult at first and might take a few tries to get comfortable with. Hopefully, the more you do it, the more you’ll realize how beneficial it is, not only on a personal level but for all your users. 104 | 105 | ### Summary 106 | 107 | If you're not already using friction logging as part of your product development process, you should definitely consider adopting it. Here's why: 108 | 109 | - It can help you identify opportunities for improvement in your product, by highlighting bottlenecks and weaknesses. 110 | Showing that you listen to users and actively make changes to your product based on their feedback builds user trust and loyalty 111 | - Friction Logging can help to build a culture of trust and feedback, and incentivize emotional intelligence in communication between your colleagues 112 | - In the long run, friction logging can help you save time and money by ensuring that your product is constantly improving. 113 | Get our friction logging templates 114 | - We’ve created a [friction logging toolkit](https://github.com/mikeb-stripe/friction-logging-toolkit) for you to use if you’re interested in getting started with Friction Logging at your company 115 | - You may also want to check out [frictionlog.com](https://frictionlog.com) - they provide lots of great articles, examples, and resources on Friction logging. 116 | 117 | ## About the authors 118 | 119 |
120 | 121 | ![Charlie Gerard headshot](/images/charlie-headshot.png) 122 | 123 |
124 | 125 | [Charlie Gerard](https://twitter.com/@devdevcharlie) is a Developer Advocate at Stripe, a [creative technologist](https://charliegerard.dev/) and [Google Developer Expert](https://developers.google.com/community/experts). She loves researching and [experimenting with technologies](https://charliegerard.dev/). When she's not coding, she enjoys spending time outdoors, trying new beers and reading. 126 | 127 |
128 | 129 | [![Mike Bifulco headshot](/images/mike-headshot.png)](https://twitter.com/irreverentmike) 130 | 131 |
132 | 133 | [Mike Bifulco](https://mikebifulco.com) ([@irreverentmike](https://twitter.com/irreverentmike) on twitter) is a Developer Advocate at Stripe. He's also a serial entrepreneur, host of the [APIs You Won't Hate podcast](https://apisyouwonthate.com/podcast), and an espresso fanatic. Mike writes about product design and building with React on his own site, [mikebifulco.com](https://mikebifulco.com). 134 | -------------------------------------------------------------------------------- /images/charlie-headshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/charlie-headshot.png -------------------------------------------------------------------------------- /images/cover.webp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/cover.webp -------------------------------------------------------------------------------- /images/image-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/image-1.jpg -------------------------------------------------------------------------------- /images/image-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/image-2.png -------------------------------------------------------------------------------- /images/image-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/image-3.png -------------------------------------------------------------------------------- /images/image-4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/image-4.jpg -------------------------------------------------------------------------------- /images/mike-headshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/mikeb-stripe/friction-logging-toolkit/9fdc20491747fc1e0e73ecee604c3a6e2e728bf0/images/mike-headshot.png --------------------------------------------------------------------------------