BUGS 🐛 ...and why non-tech founders should look for them

How to test software as a non-technical person

Hey friends,

Laura here. And before we launch into today’s newsletter, I want to give you some backstory. A few years ago, before I was a writer at Krit, I worked as a project manager for a digital agency. They built websites.

When I first started, I couldn’t code, and I had no clue how to move around the backend of a website. 🙃

So it surprised me when our developers loved floating test sites my way. It’s no exaggeration to say they were gleeful sending me links. 😳

When I eventually asked them what’s up with this?, they explained I had a perspective no one else on the team provided. Because I was new to tech, I stumbled more easily and revealed usability flaws more quickly. And that was a huge strength.

I mimicked the actual client and end-users far better than anyone else on the team, so my clicking around? It really, really mattered.

Confession: I take the computer from my husband all the time now 💻 #

These days, I’m closer to the other end of the spectrum. Sometimes, I watch my husband (an actuary) click around web pages, and it makes my fingers twitch. After navigating a thousand websites in the last decade, project managing tens of them, and building a few of my own, I’m able to spot patterns and layouts faster than he is.

I know the button he wants is right over there under the dropdown in the corner. And the login is just below the...ohhereletmedoit. 🙈

But if I can wrangle my hands and impatience, his small delays and hesitations communicate something very valuable.

The thing is, he doesn’t know how to get around common usability issues—just like when I first joined the agency. When trendy designs are flashy but unhelpful, he gets distracted. When site structure sucks, he struggles to find information. When buttons use tech jargon, he doesn’t know WTH to click. 😯

And you know what? Those insights are gold.

Imagine if the site builders knew those bottlenecks?

Imagine if they knew exactly how to help customers find information and get to value faster? What kind of revenue boosts, word-of-mouth referrals, and acquisition gains could that produce? 💸

You can be this goldmine for your technical team 🏆 #

If you’re non-technical, you can be this insights goldmine for whatever you’re building.

Your perspective is absolutely vital for uncovering the issues a technical team might be blind to after years of experience.

But, it can be intimidating to share what you experience. I know, because I’ve been there. 😬

You may feel like you don’t have the vocabulary to describe issues—“the, um, thing? is behaving weird.” Or you may worry you’re doing it wrong. You may even get frustrated and wonder, wouldn’t it be more efficient to have someone technical do this?

100%, your technical team should conduct rigorous tests before they send you any software. But no matter how extensively they test, they will miss a few things...because they’re human. And because they’ve been building tech for ages. 🤓

You can see things they can’t. So here’s how you can communicate what you notice, in a productive and helpful way. Because remember, even the right feedback delivered the wrong way can hurt teams and slow them down!

How to make your app even better with feedback 🚀 #

Okay, so here’s the context. Your team has just sent you your app. They’ve asked you to click around it and tell them if you notice any issues. You’re exploring what they built, and you’re noticing some issues.

Here’s what you do next:

1. Take screenshots or videos of what you see 📷

When you notice something weird, take a screenshot. Trust me, it’s easier to show a developer an issue than it is to explain it. If you’re on your laptop and the issue involves multiple steps (e.g. clicking 3 buttons to get to a blank screen), consider recording it with something like Loom for even more clarity.

2. Provide context for your team 🔎

A developer will almost always need to re-create your experience so they can see what’s wrong and fix it. To do that, they’ll need to know the exact steps you took when you experience the issue. Were you on an iPhone or android? Were you in Chrome, Safari, or some other web browser? When you share an issue with the team, make sure you describe what you did so they can re-create your experience.

3. Compile everything, then send 💬

As tempting as it may be to rapid-fire issues to your team, please don’t bombard them with 20+ stream-of-consciousness messages. Set aside an hour or so to poke through the software they sent, and compile everything you notice into one doc or email. Your team can fix things much faster this way.

4. Organize issues by how important they are 🚩

A good way to ensure your team is working through high-priority items—and not getting stuck on low-priority ones—is to communicate which items actually are high-priority.

Personally, I’m a big fan of putting everything you notice into one of 3 buckets: high-priority, medium-priority, and low-priority.

  • High-priority items are big issues that gum up the main functions the app is supposed to do. Like placing an order or viewing results.
  • Medium-priority items are things that frustrate the overall experience and could drive customers away.
  • Low-priority items are often nitpicky tweaks that don’t significantly impact the overall experience. Like wanting a button bigger or smaller.

Your technical team may move some items up or down the priority scale, but this initial organization will be a huge gift to them. 🎁

5. Differentiate between PREFERENCES and ISSUES

Issues are errors that cause you or your customer to stumble as you walk through the app. Preferences are non-errors that don’t get in your way but also don’t sit quite right with you.

Issues almost always need to be addressed. Preferences sometimes need to be addressed. 👀

Why is this distinction important? Although it is your app, you are not the customer. And your customer is the most important stakeholder here because they’re the ones pulling out their credit cards. So if your preferences make it harder for the customer to use the app, it’s in your best interest to prioritize the customer—not your preferences. That’s why preferences only sometimes need to be addressed.

And last, assume your team has the best intentions. Chances are, they’re trying real heckin’ hard to make a great app that you’ll love. If you see more issues than you expect, bring it up kindly and honestly. That dialogue can save your relationship and may provide helpful context for you both. ❤️