Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
39

How to Process Customer Criticism

from Daniel Marino [alt+shift+b] in programming

Why do us product designers opt into a career where we’re regularly challenged to be vulnerable?! Design is super subjective, and everyone is a critic! Regardless of your education or how sharp your design eye is, you’ll never be able to please everyone. This is especially true when you work on a product that has thousands upon thousands of users! One of my personal challenges of being a product designer is learning how to process customer criticism. Its an ongoing struggle for me because I tend to be very sensitive to criticism in general. I’ve grown thicker skin over time, but there are still some days where I get down in the dumps. My knee jerk response is to cave in, and give everyone what they want (or demand) so we can all be happy. However, good product designers don’t cave. We take a breath and carefully processes the criticism. Digging into Customer Criticism It’s hard, but sometimes you need to dig underneath the harsh and sometimes-hurtful comments. Is there actual legitimate feedback? Even if a customer insults you, it doesn’t negate the fact that they’re having a poor experience. Once you’ve pushed past the hurtful comments and processed the feedback, are there common themes or issues raised by these customers? Obviously, bugs should be fixed, but have you overlooked some UX considerations? Be honest with yourself. If there are things you can improve, and time allows for it, you should improve them. Even the tiniest improvement can be enough to change someone’s reception to a design! Haters Gonna Hate What about the people that hate something just because they can? Sometimes you just have to accept the fact that some people aren’t going to like something. Some things to consider: You’re more likely to hear negative feedback. People are more inclined to write a support ticket when they dislike something. For every person complaining about your design, there’s likely hundreds or thousands that really like it! Some folks like to complain for the sake of...
1st Sep 2020

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from Daniel Marino

Letting Claude Teach Me

Now that I use AI regularly to help write code and complete tasks, I find myself in a position where I’m not learning as much as I used to. That feels a bit crummy. Fairly often, Claude writes code I don’t fully understand. For example: I know enough TypeScript to be dangerous, but I’m definitely not an expert. Recently I had Claude take some typing I thought was overcomplicated and drastically simplify it. The new version was clearly better — I just couldn’t tell you why. So I asked Claude to explain it in simple terms. Sure enough, it did. I guess that’s a silver lining to using AI: it can at least explain why it did what it did. A coworker mentioned he has Claude write one-off explanations with examples whenever this happens, and I liked that idea. So I built a skill around it. The skill looks at my uncommitted code, breaks it down, and writes a short blog article for me to read. I’m a fan of Josh Comeau’s blog and the way he uses interactive examples to teach a concept, so I made that part of the skill too — Claude generates interactive examples alongside the explanation, then packages everything up in a small Vite environment. The first iteration was expensive to run. At least 3 minutes, and roughly 10K tokens. I’m fine burning tokens, but I’m also thrifty 😬. The second iteration kept the Vite environment and styles already wired up, so Claude only had to write the article and the examples. That brought it down to about a minute and 7K tokens. Better — though I’d still like to get the token usage lower. The blog format is great, but it’s a lot of work (for Claude) to generate all of this just to delete it when I’m done reading. It’d be nice to have these articles persist somewhere I could revisit later, or share with other people. That brought me to my current iteration. It’s an Astro project that lives on GitHub. The skill works roughly the same way — review uncommitted code, generate a post complete with interactive examples — but now it publishes to a TIL subdomain where I can read the articles at my leisure or pass them along. It’s all vibe coded, and that feels appropriate. I’m up front about it on the site itself: Things Claude changed that I didn’t understand — explained… by Claude. I’ll probably keep tinkering to bring the token usage down further, but it was a fun project to put together, and I’m happy to let Claude teach me what it’s doing.

4th May 2026 • 1 votes
What I’m Using in 2026

This is an updated list of what I’m using in 2026. I’m only sharing what’s changed since last year’s list. Applications Chrome — Chrome was on my list last year, but I’m mentioning it again because I actually used Brave for most of 2025. I like Brave, and honestly I can’t even remember why I switched back to Chrome 🤷🏻. ChatGPT — I hate that I’m listing AI tools, but if I’m going to be transparent, it has to be here. I use it a bit for code, but mostly for rewording messages or rubber-ducking ideas. Claude Code — I wrote about my thoughts and reluctance to embrace AI for coding. My company pays for it, so I use it. Endel — I’m neurodiverse and have been trying to be more intentional about using tools that help me stay focused. Endel is super cool and has a lot of genuinely helpful features. Hyper — I was previously using iTerm2, but switched to Hyper mostly because it feels prettier. That’s probably a dumb reason since I could have customized iTerm2, but I installed Hyper on my new machine and never felt the need to switch back. Retcon — My team is pretty opinionated about Git history, and rewriting history via the command line or VS Code started to feel tedious. Several coworkers use LazyGit, but I didn’t want another terminal-based tool. Retcon does exactly what it promises and lets me handle more advanced Git workflows without having to be a Git super-nerd. Notion — I was using Bear for notes, but didn’t feel like I was getting enough value out of paying for it. That’s not a knock against Bear—it’s a great product. Notion’s free plan works just fine for me. I also tried Obsidian this year and liked it, but parts of it felt quirky. It also seemed like a bigger time investment to make it feel as polished as Notion or Bear. VS Code — I tried Zed for a bit, and there are things I really like about it. That said, I ran into a few weird and buggy behaviors that I just couldn’t get past. Equipment I got a 2025 M4 MacBook Pro when I started my new job this year. It’s more than powerful enough for anything I need to do.

4th Jan 2026 • 1 votes
The Money Filter

One of the biggest challenges I’ve faced as a web designer is how often people expect a website for next to nothing. Somewhere along the way, the perception formed that a website is a commodity—quick, cheap, and interchangeable. So when someone asks what I charge (for a very basic marketing site), I usually reply, “That’ll cost around $5,000.” That number isn’t a gimmick—it’s a filter. It immediately reveals who understands the craft behind the screen, who values quality, and who’s serious about investing in their own business. It separates those looking for something fast and inexpensive from those seeking something purposeful and crafted. It used to frustrate me when people balked at the cost. Now? I see it as a helpful sorting mechanism. It shows me who I actually want to work with. The Cost of “Cheap” There’s no shortage of DIY website builders promising professional results at a low price. And honestly—sometimes that’s fine. If you just need something quick and functional, a template might be all you need. But a boutique website is something entirely different. When you hire me, you’re not buying convenience—you’re investing in craft. A boutique site is designed and engineered specifically for you. It’s not a template dressed up with new colors. It’s built intentionally, shaped around your goals, your audience, your brand’s personality, and the experience you want people to have. And cheap solutions often come with hidden costs: lost conversions poor usability and performance accessibility issues a generic, forgettable brand presence The value of a bespoke website isn’t just in what it does. It’s in how it’s made—and what it communicates about you. Why Bespoke Work Matters When I build a custom website, it’s not just about aesthetics. It’s about alignment—making sure every part of the experience supports your story, your content, and your clients’ needs. Every choice—typography, layout, semantics, performance—is intentional. Anyone can make a website that looks good. I handcraft websites that feel right and function beautifully. As a design engineer, I don’t hand off a static mockup and hope the final result captures the original intent. I design with the intent to build, carrying the project from concept to code so the final experience is cohesive, thoughtful, and true to the vision. That’s what boutique design is: every pixel and every line of code has purpose. The Bottom Line If you only need a website, you don’t need me. But if you want a boutique digital experience—something that reflects your values, your vision, and your commitment to quality—then I’m the right fit. You’re not paying for a website. You’re paying for craftsmanship, collaboration, and care. And while not everyone values that, the right clients do. My pricing isn’t just a number—it’s a filter that helps me focus on the people who appreciate the work, the craft, and the impact it can create.

30th Nov 2025 • 1 votes
How I Handletter

When I first got into hand-lettering, I had a hard time finding people who shared their full process—especially the digitizing phase. So here’s a look at how I typically work. Everyone’s process is different, and a lot depends on your style and how you plan to present the piece. For me, since I don’t have the steadiest hand, I tend to embrace rough, scrappy, distressed looks. Most of my work ends up digital anyway, so mistakes can be fixed later. Here’s a short process video I made a while back. Thumbnails & Sketching Start with quick thumbnail ideas on scrap paper. Refine the chosen direction with a pencil on Bristol Paper. If possible, I use a drawing pencil (softer, lighter lead makes cleanup easier). After inking, I clean up with an art gum eraser. Inking My go-tos are Microns in different thicknesses. In the video I sharedI used a .08 for outlines and Graphic 1 for filling letters. I used a Gelly Roll 10 to add cut-outs, create depth, and fix small mistakes 😬. Digitizing I scan the inked artwork using Scanner Pro on iOS. Clean up in Pixelmator Pro. Add textures for distress and wear (I’ve collected a bunch of texture packs over the years). Where I’ve Used This This is basically the same process I followed for my State Motto series, and most of my other lettering projects. Don’t be afraid to lean into your natural tendencies (like a scrappier style if your hand isn’t steady) and use the digital phase to enhance or correct. Trial and error is a huge part of it.

19th Sep 2025 • 1 votes
Vibe Coding and the Existential Dread of Progress

Does anyone else hate the term vibe coding? I’ve been pretty resistant to incorporating AI directly into my development workflow. I use it all the time to clean up emails, Slack messages, and blog posts (including this one). It’s helped me plan vacations, write my cover letter for Planning Center, and even gain insights from journaling. But coding? That felt like crossing a line. At first, I confined AI to repetitive tasks—formatting long word lists into arrays, deciphering cryptic console errors, or exploring how to integrate Vite into a Rails codebase still using Sprockets. All helpful, but I steered clear of anything that touched “real” engineering. Still, AI isn’t going anywhere. And as much as I hate admitting how much I rely on it, it genuinely makes my life easier. So I gave vibe coding a shot. Spoiler: I’m sold—with a few caveats. Vibe Coding an Alfred Workflow I’d played with basic Alfred workflows before, using the built-in UI or tools like Alfy. But I had an idea for something more complex—and neither the time nor the motivation to learn how to build it from scratch. The Problem At Planning Center, our design system has 300+ tokens (and counting). To grab one, I’d open our Storybook instance, scroll to the search bar, type in a few characters, click to copy, then return to my editor to paste it. Repeat that a few dozen times a day, and the friction starts to add up. The Solution An Alfred workflow that lets me search tokens via fuzzy matching, press Enter to copy, and paste directly—eliminating multiple steps and speeding up my flow. Using Claude Code I’ve tried ChatGPT and GitHub Copilot. They both work well (though I find Copilot’s integration with VS Code a bit invasive). I’m not ready to pay out of pocket, so I started using Claude Code through Planning Center’s access. Setup took less than 10 minutes. Anthropic’s documentation is clear, and their tips on effective usage are actually helpful. Building the Workflow with Claude Code I kicked things off with a prompt: I want an Alfred extension where I can enter “tt” followed by characters, and tokens from URL redacted will be shown using fuzzy search. Claude generated a Python script… that didn’t work. It produced a workflow Alfred couldn’t import. So I responded with: The Alfred extension fails to import. Claude replied something like, “You’re right, let me fix that,” and, impressively, it did. After about three hours of iterative prompts and debugging, I had a fully functional Alfred workflow that: Stores design tokens as a JSON database Caches data locally Refreshes if unused for over an hour Fuzzy-finds tokens on input Displays color swatches for color-based tokens I also used Claude to: Generate 100+ color swatches (since Alfred can’t use data URIs) Write a Bash script that builds the workflow with semantic versioning I don’t know much Python, but I know enough to skim the output and feel confident in the structure. And because this was a small, siloed project, I wasn’t concerned about maintainability or codebase conventions. The Cost Aside from the monthly AI access fee, the entire three-hour build process cost around $10 in usage tokens. That’s ~$3.33/hour—far below the value of my time. And now, every use of the workflow saves me 10+ seconds. That adds up quickly. If I’d tried to build this from scratch, it easily could’ve taken 10+ hours and been half as effective. That’s not even accounting for generating the color swatch images. I did spend about an hour trying to get Claude to scrape the tokens directly from the design system site, but that turned out to be unreliable. Still, the final solution works and required zero extra effort from the rest of my team. The Pros and Cons of AI in the Workflow Pros Efficiency Boost: Great at handling menial but necessary tasks—JSON formatting, token lookups, error decoding, etc. Rapid Prototyping: I built a working Alfred workflow in a single evening. Even if it were only a prototype, it would’ve been valuable. Creative Leverage: Designers and PMs can use AI to sketch out ideas and flows, helping engineers jump into development faster. Cons Skill Stagnation: Over-reliance on AI could erode problem-solving ability or deeper understanding of frameworks and languages. Job Displacement: AI is replacing some roles. At Planning Center, leadership has been clear AI won’t replace people—only support them. But the broader industry picture is less certain. Environmental Cost: Running large AI models consumes a lot of energy. Price Tag: Even if it saves time, AI access and usage can get expensive—especially if you’re footing the bill. So Why Do I Still Feel Icky? It took me a while to name the feeling, but I got there: I’m grieving the loss of what it means to be an engineer. I’ve spent over 20 years solving problems, building UIs, and turning ideas into code. I’ve always taken pride in being able to take a design and bring it to life. But now, what it means to be an engineer is changing—and that’s uncomfortable. I don’t want to become just a prompt wrangler. But I also don’t want to be the person who gets left behind because they refused to adapt. The logic is clear: why pay one engineer for 10 hours of work when another can produce the same result in two with AI? Finding the Sweet Spot I think the answer lies somewhere in the middle. Engineers should still understand their craft—be able to reason through problems, write maintainable code, and build features from scratch when needed. But AI should be a tool we use intentionally to reduce toil and accelerate progress. We don’t call it cheating when someone uses code completion. Why should this be any different?

19th Jul 2025 • 1 votes

More in programming

If we do not stop to help each other, what do we become?

Yesterday, I received this email as a response to You Can't Vibe Code Love. It's such a remarkable and powerful statement that I asked permission to share it here, in its entirety, with personal information redacted: Hey Jeff, Hope you and your family are doing well.

6 hours ago • 1 votes
You are still valuable

A frustrated Reddit post about being a condom between an AI and production made the rounds in our team. Here is why I think the opposite is true and what it means for how we review code, plan work and think.

2 days ago • 2 votes
A Short Update on Designing for Foldable Devices

And here we are three years after I wrote about the Google Pixel Fold being announced, followed now with the announcement of the iPhone Duo...(I have questions about the naming by the way). Four years ago I was talking about web primitives in the platform for the Surface Duo. My how time flies. There are CSS media features, a Viewport Segments API, a Device Posture API but Chromium based browsers are the only ones currently supporting these things. I haven't been able to find any signal yet on whether Safari will support these things in the web platform as the developer docs focus on application development. If you're interested in trying out the platform features, you can emulate the Surface Duo and Galaxy Z Fold in the developer tools. And if you're thinking, do I really have to have my website adapt to two screens? The answer is no. Adding a design to an application or dual screen makes sense if you have an experience that has two simulataneous contexts that are useful e.g. a list of email messages/inbox on one screen, an open message, email thread or email composer on the other. Here's one of my talks from 2022 if you're interested in learning more about what's available in the browser for dual screen/foldable devices. Happy building :)

2 days ago • 1 votes
Mommy bloggers react

After a write-up in the New York Times, Mommy Bloggers had two options. Either lean in, or step back. Given how popular it became after that, it's not hard to guess which option they chose. The post Mommy bloggers react appeared first on The History of the Web.

4 days ago • 2 votes
Haunt 0.4.0 released

I'm quite a bit late on this one, but Haunt version 0.4.0 was released released back in July. I haven't had much time for blogging, but I'm catching up now! This release contains a small set of improvements and bug fixes since the 0.3.0 release in 2024. About Haunt Haunt is a static site generator that uses the Guile Scheme as its configuration language. It aims to be simple, functional, and extensible. Features include: Easy blog and Atom/RSS feed generation Markdown post support Simple development server for viewing edits before publishing Purely functional build process User extensibility Notable changes Added support for HTML in Markdown documents. This was a long time coming because guile-markdown did not support it and the library was abandoned by the original maintainer. As part of my work at Spritely, we forked it, implemented the relevant portions of the CommonMark specification, and released it. Spritely's guile-commonmark fork is now considered to be the official upstream by Guix and others. A further consequence of this is that guile-lib is now a required dependency for building Haunt as we need the (htmlprag) module to parse Markdown documents with embedded HTML. html->shtml from guile-lib's (htmlprag) module is now used instead of xml->sxml in the HTML reader. It was silly of me to use xml->sxml for this purpose years ago, but at the time I wanted guile-lib to be an optional dependency. Added haunt new subcommand for creating a new site. Added default directory, template, and prefix arguments to flat-pages procedure. Added support for index metadata flag to flat pages for pretty URLs. Flat pages now receive all page metadata, not just the page title. This is a breaking change from 0.3.0. Added .scm as an additional extension for sxml-reader. make-file-extension-matcher now supports multiple extensions. Fixed emission of <script> and <style> elements. Fixed handling of no available reader in flat pages builder. Fixed unreachable error handling clause when a reader is not found for a post. Fixed default blog theme template missing an <html> tag. Fixed overloaded -h option in haunt serve. Deprecated post in Skribe reader in favor of document. Download Haunt 0.4.0 is already available in Guix: guix pull guix install haunt See the Haunt project page for information on how to build from source. Thank you to Camilo Rodrigues, Noé Lopez, jgart, Jakob L. Kreuze, and Daniel Meißner for their contributions to this release! Happy haunting!

4 days ago • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in