When Approving Isn't the Answer: A Language Lesson from a Product Workshop

We didn't plan for a philosophical debate. We scheduled a straightforward, two-day Product Area workshop to look at "approval flows" in our platform. Just another unglamorous but necessary part of B2B software. We invited colleagues from across the business, did our homework, mapped current journeys, and on day two, we jumped into future-state thinking. Then we prioritized ideas on a simple effort/value matrix to decide what to explore next.

But somewhere between sticky notes and dot voting, the conversation shifted. What started as a systems discussion turned into a deeper question: what exactly do we mean when we say "approve"?

That question changed everything.

The workshop format that actually works

We've been running these Product Area workshops regularly at TimeLog. Here's the structure:

• First, we research a topic or system area in depth. We bring the right people into the room: sales, support, engineering, compliance. Anyone who carries context we might miss.
• On day two, we suspend today's constraints. We ask, "What should this look like if we designed it from scratch?" We sketch. We map. We name emerging initiatives.
• We end by ranking options by effort and value. It's not scientific, but it works. Ideas either survive contact with reality or they don't.

The real value? Alignment. This format helps us step back from "build a feature" and move toward "solve the problem." It pushes us to think holistically instead of shipping point solutions.

The "easy" topic that kicked our ass

Approval flows sound simple. Most corporate tools have them: timesheets, absence requests, project expenses, access rights. We came in thinking this would be a quick cleanup job.

We were so wrong.

The complexity wasn't technical. It wasn't organizational. It was linguistic and cultural. We discovered we'd been using "approval" to do way too many jobs.

Approval vs verification: the split that matters

Here's what blew our minds. In both English and Danish, "approval" (godkende) carries implied authority. You approve something when you have the mandate to say yes or no. That mandate comes from your role, a policy, or a law.

"Verification" (bekræfte) is totally different. It's about accuracy. You verify facts, confirm details, check that something is true or complete. You don't need authority to verify. You just need enough context to know if something is correct.

Once we named that difference, we saw it everywhere:

Why does this matter? Because when we label everything "approval," we inject authority and hierarchy into places where we really just need accuracy checks. That changes how people feel. It slows teams down. It pushes the product toward control when what users need is trust.

A dead simple model for decision flows

We landed on this super simple test for any decision flow:

Ask yourself: Is the receiver answering "Is this allowed?" or "Is this accurate?"

If they're checking policy, compliance, or financial risk? You need approval. If they're checking facts, completeness, or correctness? You need verification.

Real examples:

• Time off request = "Is this allowed?" (checking policy and coverage)
• Invoice review = "Is this accurate?" (checking line items and terms)

Mix those up and you create friction where none should exist.

Here's the kicker: sometimes you don't need either. A solid audit trail with transparent change history can provide safety without human checkpoints. That's something we're actively exploring at TimeLog.

Culture isn't just translation, it's mindset

This is where it gets wild. You can translate "Approve" perfectly, but the cultural weight doesn't translate at all.

As an American living in Denmark, I feel this constantly. Facebook translates "Like" as "Synes godt om" in Danish. It sounds heavy and formal. Nobody talks like that. My Danish friends just shrug and say they've gotten used to it. Small language users learn to bend to global products that don't quite fit.

But here's the thing: they still prefer local tools that match their mental models, not just their vocabulary.

Same deal in business software:

• In Denmark or Netherlands (low power distance), people expect flat structures. An "Approve" button feels patronizing when "Confirm" would work fine.
• In Japan or UAE (high power distance), explicit authorization is expected even for simple checks.

This isn't about words. It's about what the system assumes about authority and decision making.

Your design checklist for consent flows

When building these flows, ask yourself:

[ ] What's the core question?
    Allowed (approval) or accurate (verification)?

[ ] Who should act and why?
    Authority holder? Domain expert? The person who submitted it?

[ ] What's the cultural context?
    Formal authorization or collaborative confirmation?

[ ] What does your button text signal?
    Try "Confirm" or "Mark complete" when authority isn't needed

[ ] Can an audit trail replace the gate?
    If you can reverse, trace, and notify, why block?

[ ] How will you test this?
    Get native speakers on prototypes early

The mindset shift that changes everything

The biggest change from our workshop wasn't a new feature. It was how we think.

We started noticing where we'd bundled "approval" and "verification" together. Where we'd taught users to expect control instead of clarity. Where we'd created hierarchies that didn't need to exist.

Now everything's on the table. More verification flows. Smarter audit logging. Fewer gates with better transparency. We're rethinking it all.

What I learned

• Words create expectations. "Approve" creates hierarchy. "Verify" creates collaboration.
• Start with one question: is this about permission or accuracy? Let that drive everything.
• Culture shapes how people think, not just how they speak. A perfect translation can still be a terrible experience.
• Audit trails can be more powerful (and more human) than approval gates.
• Test your microcopy with native speakers for emotional weight, not just linguistic correctness.

Your turn

I'd love to hear your stories. Where does your company or culture expect explicit approval? Where does simple confirmation work better? What words do outsiders always get slightly wrong in your product?

Drop me a comment. Your examples will make all of us better designers.