The Software You Wish Existed

Think about the software you use every day.

Somewhere in it, there's probably a screen that makes you sigh.

Maybe you copy the same information into three different places. Maybe the system gives you a number, and you immediately open a spreadsheet to find out whether you believe it. Maybe you've taught every new person on your team the same little workaround.

At some point, you've probably said, "I wish somebody would just build this differently."

What if you could help build it?

This is The Age of Imagineering. I'm Justin Thompson.

In the first few episodes, we've talked about making ideas real, the systems that help us act on them, and how we know whether the result deserves our trust.

Today, I want to bring all of that down to one very ordinary place. Your workday.

Because if you've done a job for years, you know things the software doesn't.

You know which exception will cause trouble. You know when a customer is really asking a different question. You recognize the number that looks perfectly reasonable until you remember what happened last month.

Some of that knowledge lives in a process document. A surprising amount lives in you.

And often, it shows up in those little workarounds.

The spreadsheet beside the official system. The note taped to a monitor. The extra question you ask before you press the button.

It's easy to dismiss those things as messy. But look closely, and you may find years of experience trying to tell the software what it missed.

Something that feels obvious to you may be obvious because you spent ten years learning to see it.

I'm an AI engineer. I work with these systems every day. That doesn't make me an excellent accountant.

I can help think through an interface. I can work on how information moves. But an experienced accountant may notice a mistake I wouldn't even think to look for.

That matters when we talk about who gets to build the next generation of tools.

Imagine an accountant who spends part of her week looking for duplicate invoices. Let's keep this example imaginary, because I want to walk through the decisions without pretending we've already measured the result.

She has a simple idea. Put suspicious pairs of invoices next to each other. Show the original records. Let somebody review them and record a decision.

She doesn't need an entire new accounting system. She wants help with one part that keeps eating her time.

So she describes it to an AI and asks for a rough version, using made-up records.

A little while later, there's something she can try.

The first version spots repeated invoice numbers. It puts them in a tidy list. From across the room, it looks like progress.

Then she starts reading.

Two different suppliers have used the same invoice number. The tool thinks they're duplicates. Meanwhile, an actual duplicate has a typo in its number, and the tool has missed it.

She knows why both mistakes matter.

Now she can be specific. Compare more of the information. Show me what made you flag this pair. Keep the supplier names visible. Give me a way to say that something needs another look.

The next version sounds less certain. It also gives her more useful information.

That's a good trade.

What happened there is worth slowing down for.

Her expertise didn't become irrelevant when the first version appeared. It became part of the design.

She could point to something concrete and say, "This is where you're missing the way the work actually happens."

That's different from filing another request and hoping somebody understands it six months from now.

A prototype gives people something to think with. You use it, notice a problem, and discover that the thing you asked for wasn't quite the thing you needed.

That discovery can happen while the idea is still fresh.

Now our accountant asks a colleague to try it.

He understands the comparison. But when he rules out a suspicious pair, he wants to leave a reason. Otherwise, somebody may come back tomorrow, see the same records, and investigate them all over again.

She adds a short explanation field. She makes previous decisions easy to find.

One person's experience got the idea started. Another person's experience made it better.

I like that picture of building software. People bringing what they know, trying something together, and letting the experience change the design.

It makes room for a kind of creativity that doesn't always get recognized as creativity.

Choosing what somebody needs to see first. Knowing which detail should stay close to a decision. Realizing that a confident green check mark could encourage the wrong behavior.

Those are creative judgments. They're also practical ones.

And the point reaches well beyond accounting.

Imagine a teacher trying to make a difficult idea visible. She knows the exact moment when students tend to get lost. She can picture something they could move around on a screen, so they can see what changes when one part changes.

Or a musician imagining an unusual instrument. A small experiment with sound, something that responds in a way existing tools don't.

Those are possibilities I find exciting because they begin with a person's point of view.

The person has noticed something worth exploring. Now there's a more approachable way to give it a shape.

Plenty of first attempts will be awkward. Some will lead nowhere. That's part of trying things. The opportunity is getting far enough to learn something from the attempt.

And sometimes the result can stay small.

A useful tool for a handful of people is still useful. A clearer screen, a confusing step removed, a mistake caught a little earlier. Those things belong in our picture of progress too.

We do have to ask whether our accountant's tool actually helps.

She's improved the design. Her colleague likes the explanation field. We still need to find out what happens when someone uses it to do the work.

In the last episode, I talked about the difference between something convincing and something we have good reasons to trust. Here's where that becomes practical.

Give the tool prepared examples with known answers. Include straightforward duplicates, legitimate invoices that happen to look alike, and the awkward cases an experienced person knows to expect.

Then compare the review with and without the tool.

How many real duplicates do people catch? How many harmless pairs take up their attention? How long does the whole review take, including fixing mistakes?

The tool might save time. It might create more work than it removes. Either answer would teach us something.

I would also want to know whether people can explain their decisions afterward. A tool can make a task feel easier while making the reasoning harder to follow.

We should notice that before we start depending on it.

And before real financial records enter the picture, there are other people to involve. Whoever is responsible for privacy and access. People who can assess the security. Someone who will maintain it when the underlying system changes.

A rough version can show us what is worth building. Making it dependable takes further work, and somebody has to be accountable for that work.

I don't want the person with the idea to carry all those responsibilities alone. I want them involved with the people who understand them.

The accountant knows the work. The engineer brings a different set of questions. Both should be willing to challenge what the other takes for granted.

Sometimes a familiar process is familiar because it works. Sometimes everyone has simply gotten used to it.

Building something new gives us a chance to find out which one we're dealing with.

There's a personal reason I keep coming back to this.

It is frustrating to understand exactly what would help and have no practical way to make it.

You can see the problem. You can explain it. You may have explained it many times. Eventually, getting through the day feels more productive than asking again.

I wonder how many good ideas have gone quiet that way.

AI gives more people a place to begin. It gives that knowledge another route into the things we use.

That doesn't settle the bigger questions about work. People have real concerns about their jobs, and a new tool doesn't automatically make a workplace more generous.

But I would like the person doing the work to have more say in how the work changes.

They have something to contribute that we should be curious about.

So here's a small place to start.

Think of one thing you keep working around. Choose something you understand well enough to describe in plain language.

Who is having the problem? What happens now? What would a better experience look like?

Then ask yourself what the smallest version would need to do.

Maybe it's one screen. Maybe it's a way to compare two things. Maybe it's a simple demonstration you could put in front of a colleague and ask, "Would this help?"

Keep the first experiment safe. Use invented examples. Leave real customer information and important decisions out of it while you're learning what you've made.

Then pay attention to what surprises you.

The first useful result might be a better question. You may discover that the problem sits somewhere else. That's still knowledge you didn't have before you started.

You don't have to know every technical step to bring something valuable to the table.

You do have to care about the result. You have to be willing to question it. And it helps to invite someone who sees the work differently.

That's how a wish begins to become a tool someone might actually want to use.

So I'll leave you with this.

What is the software you wish existed because you know the work well enough to see what's missing?

If something came to mind, write it down before the next busy day swallows it.

Follow The Age of Imagineering for more conversations about what we can do with these tools, and what we want them to do for us.

You can find the essays behind the show and subscribe at age of imagineering dot com.

I'll see you next time.