Part 1: Rethinking Feedback - Making It Easy for Everyone

When building apps, one of the most important-and most overlooked-components is feedback. Not analytics. Not crash logs. Real feedback from real users.

I've spent years working in environments where end users aren't always technically inclined-from government platforms to internal corporate tools. The guiding principle has always been simple: never assume users understand what's happening behind the scenes, and make it effortless to speak up when something goes wrong.

I often design with this thought: could my mum use this app? Could I explain it over the phone to a parent who "just wants it to work"? It's like defensive driving, but for support design.

Let's look at why traditional feedback methods don't work for everyday users-and how I ended up building FormLogger as a more human alternative.

Traditional Feedback Channels

We've all seen the usual suspects when it comes to gathering feedback: "Send us an email," "DM us on Twitter," or "Log a GitHub issue." These approaches are familiar and easy to implement, which is why they've become standard.

But in practice, they come with a lot of friction - especially for casual users, non-technical folks, or anyone who doesn't want to jump through hoops just to tell you something useful.

Email

Email feels like a reliable fallback. It's ubiquitous, and just about everyone knows how to send one. But it's not ideal for feedback. For one, when you expose your email address publicly, it quickly becomes a magnet for spam and unwanted messages.

Beyond that, not everyone feels confident writing a feedback email. They might not know what information is relevant, how detailed to be, or even what to say. Heck, sometimes I've even sent feedback but don't want a reply - more a did you know this app function is not working?

Once you do receive feedback by email, it usually involves manually copying that information into whatever task manager, bug tracker, or documentation system you use. It's just not a seamless workflow.

Things get even clunkier on mobile. On iOS, for example, tapping a "Send Feedback" link might unexpectedly boot the user out of your app, open a completely different app like Apple Mail, or fail altogether if they haven't configured a default mail client.

Social Media

Social media used to be a relatively straightforward place to handle feedback - especially during the era when nearly everyone had a Facebook or Twitter account.

Twitter, in particular, became a kind of informal help desk for many apps and services. It was public, fast, and easy to ping someone with a quick comment or complaint.

But things changed. Facebook gradually faded from being a go-to communication channel, especially for professional or app-related interactions. It became more focused on personal use - family updates, local events, and the like - and less of a place for users to reach out to products or developers.

Twitter was the next logical home for user feedback, but that situation deteriorated quickly after the platform was sold. The direction it took alienated large parts of the tech and creative communities - not to mention the general toxicity that began to dominate the space. We won't get into the details, but suffice it to say, it stopped being a viable option for many of us.

So we migrated. Mastodon became the new home for many in the tech world - decentralised, community-run, and aligned with open web values. But the learning curve is steep for non-technical users.

You have to explain what an "instance" is before someone can even sign up, let alone send feedback. Threads came along and promised a simpler, more mainstream social network, but not everyone adopted it. Then there's BlueSky, which found its own niche but still doesn't have universal reach.

The result? Fragmentation. You might get feedback across five different platforms, each with different audiences, moderation tools, and message formats. If you stop checking one, you risk missing someone's important feedback entirely. And even when you do catch it, it's difficult to triage, track, or prioritise when your inbox is a mishmash of comments, mentions, and DMs.

Public GitHub Repos

If your app is open source or lives on GitHub, it's tempting to just ask users to "open an issue."

In theory, that's a clear and structured way to receive feedback. But there's a catch: using GitHub assumes a level of technical familiarity that most of your users probably don't have.

It requires a GitHub account, and for non-technical users, that's already a barrier. Even if they do have one, the interface can feel intimidating - especially if they're greeted with labels like "bug," "enhancement," or "PR welcome."

You're essentially asking someone's parent, neighbour, or average user to learn how GitHub works just to tell you your button is broken. That's a high bar for a low-effort interaction.

The Real UX Problem: Making People Leave Your App

One of the worst things you can do to a user is bounce them out of your app mid-task. "Send feedback" shouldn't feel like stepping into another universe.

It interrupts the flow and breaks their mental model of how things are supposed to work. One moment they're using your app, and the next, they're staring at a different screen or app entirely - unsure whether something went wrong, if they tapped the wrong thing, or if your app just crashed.

That uncertainty chips away at trust.

Even when developers try to smooth things over by using an in-app sheet to launch an email composer, the process still introduces friction. For starters, not every user has a mail client set up on their device. And even if they do, they might not want to use the default app the system launches.

A common scenario on iOS is that the system opens Apple Mail - but what if the user primarily uses Gmail, Outlook, or another service? Suddenly, they're facing a cluttered, unfamiliar interface, or worse, a dead-end if they've never set up Apple Mail at all.

The result is a jarring detour: what should have been a seamless, in-app action turns into a small adventure through the OS. Some users don't make it back, or follow through on providing feedback.

This isn't just a matter of polish or optimisation. It's not about boosting conversion rates or making a slicker flow. At the core, it's about something more human: helping people feel confident, safe, and in control when they try to talk to you.

If your feedback channel makes them feel lost, anxious, or unsure what just happened, then something's gone wrong - not just with UX, but with trust.

How Non-Tech Users See Apps

Not everyone who uses your app speaks the same language you do. I've worked with users who didn't know what a "crash" meant. They couldn't articulate what went wrong - only that "something happened" or "the app stopped working." Their first instinct wasn't to report a bug, open a debugger, or check the console logs. It was to wonder, "Did I break it?"

And this isn't some abstract case - here's a real-world example. My mum uses a work-related app that's really just a thin wrapper around a website - the kind that opens a web view inside the app.

One day, the website showed a popup about planned maintenance. Except the popup didn't work properly. The start and end dates both showed as undefined, and the JavaScript powering it was failing to load - a silent 404 in the background.

When she asked me to take a look, I could see the issue immediately by checking the console and web inspector. But to her, none of that mattered. She assumed the app had been updated and her phone was no longer compatible. Even though nothing suggested that - there was no version warning, no "update required" message, no "device unsupported" notice - she defaulted to self-blame.

That's how normal people think. If something doesn't work, it must be their fault. Maybe their phone is too old. Maybe they did something wrong. And that uncertainty? It pushes people away.

When users feel confused or at fault, they rarely dig deeper. They don't look for a report button. They don't send an email. They don't open GitHub. They panic. Or they quietly delete the app. Or worse, they never open it again and just live with a negative impression of your product.

For these users, your goal isn't to increase engagement or retain them through clever nudges. The design goal is much more fundamental: build trust. Make them feel safe when something goes wrong. Let them know they're not at fault. And most importantly, give them a way to communicate without needing to "know the right words."

Segmenting the Experience

As developers and designers, we understand the rhythms of onboarding flows, modal interactions, and standard UI patterns. We know what's expected in a login screen, how a drawer menu works, and what a settings cog usually leads to.

But when it comes to reporting bugs or sending feedback, that shared understanding breaks down.

The average user might navigate your app's normal UI with some confidence - after all, they opted in, downloaded it, maybe even paid for it. But when something goes wrong, the context shifts. What they need in that moment is not the same type of interaction.

In a "normal" UI, you can assume a baseline of familiarity or willingness to explore. But a "support" UI - the interface that appears when something breaks or they need help - should be a different experience entirely.

It should be obvious, intuitive, and most importantly, effortless. It's not about hiding complexity. It's about removing friction at a moment of vulnerability.

That's exactly what FormLogger is trying to solve. It's not just a feedback form. It's a reframing of the feedback experience - designed not for power users, but for the people who just want to say, "Hey, something's not working," and trust that someone will listen.

Introducing a Better Way: FormLogger

Email is clunky. Social media is fragmented. GitHub is intimidating. What if there were a better way to collect feedback - one that actually respects your users and fits naturally into the app experience?

FormLogger is that better way.

Instead of relying on emails or third-party platforms, FormLogger gives you a native, in-app feedback form. It feels like a natural part of your app - not a detour, not a handoff, just a simple interface that users already understand: fill out a form, tap submit.

Behind the scenes, that form submits to a backend - often something lightweight like a Cloudflare Worker - which takes the structured feedback and automatically creates a GitHub issue in your chosen repository. You get clean, trackable feedback. Your users never see GitHub. They don't have to create accounts, write emails, or know anything about version control. It's all handled silently and securely.

Everything stays tidy and centralised. And more importantly, the user never has to leave your app or feel like they're doing something wrong. They just get to say, "Hey, this isn't working," and trust that someone on the other end is listening.

In Summary

We've been designing feedback systems for developers - not for the people actually using our products. That has to change.

If we want to build software that's truly user-friendly, our feedback tools need to reflect that.

We need to:

• Make the experience seamless, not disruptive
• Avoid fragile third-party dependencies
• Respect the user's time and trust, especially when they're confused or frustrated
• Build tools that accommodate different levels of tech literacy, not just the power users

FormLogger is a small but meaningful step in that direction. It brings feedback into the app experience - where it belongs.

In the next post, I'll walk you through how to wire everything up: creating a private GitHub App, configuring access for just the right repos, and connecting it all to something lightweight like a Cloudflare Worker. It's probably simpler than you think.