Multimedia Content Creation

Interactive Content Creation

Build a useful tool with logic people can understand and results they can trust.

Some questions become useful only when readers can enter their own numbers. We design calculators, quizzes, and configurators with documented logic, a clear result, and no hidden use of the information someone provides. You walk away with a tool someone can complete by keyboard alone, an answer that holds up, and a maintainer who knows what to check when the numbers change.

Plan an interactive experience
Person adjusting sliders on a calculator interface that updates a result panel live

Some of the 500+ brands we've worked with

See all references
  • Watsons
  • GAP
  • English Home
  • Joker
  • Axa Hayat Emeklilik
  • Elle
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada

How we run it

How the tool moves from question to tested result

We settle the question, formula, inputs, and edge cases before designing the interface.

  1. Define the decision the tool must support

    Before sketching an interface, we define the single decision or number the tool must help someone reach. Someone on the team signs off on the one-line question before any interface gets sketched.

    A one-line statement of what the tool answers.

  2. Document the logic before development

    We document formulas, ranges, assumptions, and edge cases first so the team can explain the reasoning behind every result. A person checks the formula and its assumptions by hand. An agent can stress-test inputs, but it doesn't own whether the math is right.

    A documented decision model and input list.

  3. Keep only the inputs the result needs

    Every input field must affect the result or support a necessary state. We remove anything the tool does not need. Whoever owns the tool cuts any field that can't justify its place in the result.

    A minimal input list with each field's purpose noted.

  4. Write every state someone may encounter

    We write the loading, empty, error, and edge-case states alongside the main result so the experience remains clear when inputs or systems fail. A person walks through every error and edge-case state before calling the state list complete.

    A content matrix covering every state a user can hit.

  5. Test the full experience with realistic inputs

    We test the prototype with real scenarios and complete the full flow using keyboard-only navigation before calling it finished. Someone tests the prototype with real numbers and a keyboard alone before it's called done.

    A working prototype with test results attached.

  6. Give the maintainer a usable handoff

    The maintainer receives the formula, its assumptions, and a clear list of upstream changes that require another review. The person taking over confirms they understand the formula and what triggers a re-check, before the handoff closes.

    The finished tool plus a maintenance note.

Testing more inputs does not settle the formula

We use models to run unusual input combinations and draft early result copy across different score bands. That coverage helps us find breaks sooner. The formula, its assumptions, and the limits of each result still need a person who can answer for them, especially when money, health, or another consequential decision is involved.

What you get

What remains useful after launch

You receive the working experience and the documented reasoning needed to maintain it responsibly after launch.

  • a landing page wireframe

    A tested interactive experience

    A live calculator, quiz, or configurator tested with realistic inputs, errors, and edge cases.

  • a style guide with marked rules

    A readable logic record

    A plain-language record of the formula or decision rules behind each result, suitable for non-developers.

  • a measurement note with a small trend line

    A practical maintenance guide

    The pricing, assumptions, and ranges that may change upstream, plus exactly what to update when they do.

We call it done when: someone can complete it start to finish, including by keyboard alone, get an answer that holds up, and your team knows what to check when the underlying numbers change.

Who it fits

When the answer depends on the reader

Use this method when the reader's numbers or situation change the answer. If everyone receives the same answer, an article will usually serve them better.

A good fit when

  • A calculator's answer changes with the reader's budget, team size, or setup, but a static page cannot account for those inputs clearly.
  • Sales calls and support tickets keep repeating the same situational question, so the team needs a tested answer people can work out for themselves.
  • Your result needs a formula or decision rule that non-developers can review, because presenting the answer as a black box would make it impossible to defend.

Better handled as other work when

  • The honest answer is the same for almost everyone, so a well-written page would serve better than a quiz.
  • The proposed tool asks for personal data that does not change its calculation, so those fields need removing before the interface and data use can be approved.
  • Pricing, ranges, or assumptions will change after launch, but nobody has accepted responsibility for updating the logic and rerunning its tests.

People who write and ship this content

Some of these consultants write the pages themselves. Others plan distribution or check how a piece performs once it's live, so the team below covers more than one stage of the work.

Tools we use

Tools behind this work

  • Whimsical

    maps every branch of the tool's logic before development starts

  • Outgrow

    builds the working calculator or quiz itself from the approved logic

  • Airtable

    the state-by-state test log, every input combination checked off

  • axe DevTools

    tests keyboard and focus behavior through the tool's live interactive states

  • Notion

    the maintainer handoff: logic, test log, and who owns it next, in one place

Start the work

Does the useful answer change from reader to reader?

Tell us which decision the reader is trying to make. We will check whether their inputs change the answer enough to justify building a tool.
Discuss the interactive content idea
Two people shaking hands on the start of the work

Before we start

Frequently Asked Questions

Will you build the tool as well as define its logic?

We define the logic, content states, and specification for a developer. Depending on the stack, we can also build a lightweight tool directly.

How do you handle calculations involving health or money?

We flag it early and add extra review for the formula and disclaimers because an incorrect result matters more when the stakes are higher.

Who owns the tool once it is live?

A named owner on your team maintains it as pricing, ranges, and assumptions change. The handoff identifies every item they need to review.

Can the experience avoid collecting personal information?

Often, yes. We use the smallest input set the logic requires rather than collecting extra information for possible marketing use.

What accessibility checks does an interactive tool need?

Keyboard navigation and clear error states are required. If someone cannot complete the tool without a mouse, it is not finished. That check catches real problems: on one build a slider control turned out to be unusable by keyboard and was swapped for a stepper input before launch. Edge cases matter for the same reason, which is why a zero-usage input returns a clean "not applicable" message instead of a divide-by-zero error.