User test findings and options

Each problem from the 30 September product config test, described separately, with one or more possible solutions sketched. For discussing in the team.

Present

Product config user test · 30 September 2026

10 findings, each with options to discuss

For each problem the test showed: what happened, what testers said, and one or more ways to solve it, sketched. Options marked “Tried in product admin” are built in that prototype; the others aren’t. Nothing here is decided.

Hege

Sets up contracts

No onboarding

Berkay

Handles weekly customer deals

Rarely creates products

Øyvin

Needs a guided path

Heavily guided by the facilitator

What worked

All three understood product = content + licenses + prices without help, and started with the main group.
Hege and Berkay read a license group as the usage choices a customer gets.
Berkay and Øyvin created a time-limited subscription and described it correctly.

“It seems to fulfil what we do today, but in a nicer way.”
Berkay

“A very simple, nice and tidy page.”
Øyvin

Caveats on the evidence

Test 1 (Hege) was blind, with no onboarding.
Test 3 (Øyvin) was heavily guided: the facilitator named the licenses, set prices and prompted the publish question.
Seeded scope parameters ("duration") distorted the content group step in tests 1 and 2.
Some ideas came from Elisabeth, not testers: the exclude wish, the social media example, the default + per-customer overrides model.

Finding 1 of 10

License group vs license is the clearest point of confusion

Testers thought they were creating a single license. Button labels and layout don’t show how a license group and its licenses relate, and "Add license" and "Create license" do the same thing. The sidebar says "Licenses", but the page lists license groups.

Seen with Hege, Øyvin (Berkay got it right).

“I maybe don’t quite understand the difference between license group and license.”
Øyvin, at the end

Team notes on the board

More consistent layout with the rest of the admin: buttons in the same places, a clearer distinction between groups and licenses, a collapsible accordion like supplier management, clicking a license opens Edit (Ferdinand).

Option A

Groups as accordions

From Ferdinand

License groups

+ New license group

Editorial licenses3 licenses · used by NTB Editorial

Editorial useWeb and social media+ Add license

Creative licenses3 licenses

Keep license groups. The page is called "License groups"; each group is an accordion with its licenses inside, one "New license group" button and "Add license" inside each group. Clicking a license opens it.

+: Smallest change; matches supplier management.
−: Still two concepts to learn before a first product.

Option B

Licenses chosen on the product

Tried in product admin (PA6) API change

Product › Licenses and prices

✓Editorial use

1 500 kr

✓Web and social media

2 000 kr

Commercial use

From the license library; any product can use them.

No license groups. One license library; each product ticks the licenses it sells and prices them on the same screen.

+: One concept fewer; licenses and prices are set together.
−: Sharing a set of licenses between products means ticking them again (a "copy from product" shortcut helps).
API: Products point at a license group today.

Option C

Show a group as the customer’s choice

License group: Editorial licenses

Customers choose between:

◉ Editorial use1 875 kr

○ Web and social media2 500 kr

As on the asset page, for NTB Editorial.

Keep groups, but present each as "what the customer chooses between", with a small preview of the license options as the asset page shows them.

+: Builds on how Hege and Berkay already read license groups.
−: Doesn’t remove the second concept; the preview needs real prices to make sense.

Finding 2 of 10

Selections need to support exclusion

"All editorial except NYT" means ticking about 70 suppliers, and new suppliers can’t be included automatically. Today’s contract system solves it with a higher-priority "not this" contract. Testers also expect to include or exclude by supplier, such as Magnum.

Seen with Hege, Berkay.

Team notes on the board

UI spike: modes or rules in the UI to enable exclusion or inclusion. Look into Bjørn’s wireframe. What happens when we add a new supplier: added automatically to many products, or an active choice for variants? (Ferdinand)

Or highlight the select-all button better: it was missed during the test (Ferdinand).

Option A

"All except" per field

Tried in product admin (PA2) API change

Content

SupplierAnyOnly theseAll except

NTBAFPNew York TimesReuters…

New suppliers are included.

Each field (supplier, media type…) is Any, Only these or All except. Excluded values are struck through. New values are included unless excluded.

+: One click for "all except NYT"; new suppliers join by themselves.
−: A new mode to explain; needs an exclusion condition in the API.
API: The API has no "not includes" (Ferdinand’s note).

Option B

Pre-checked boxes, uncheck to exclude

From Hege (bring back pre-checked boxes), Ferdinand

Suppliers

✓ Select all69 of 70 selected

✓NTB✓AFPNew York Times✓Reuters

✓Tick new suppliers automatically

A "Select all" that is easy to see, everything ticked, untick what to leave out. A switch decides whether new suppliers are ticked automatically.

+: No API change for the selection itself; familiar checkboxes.
−: Long lists stay long; the "new suppliers" switch is easy to miss.

Option C

Exclusion as its own rule

API change

Content rules

1 · Include

All editorial images

2 · Except (higher priority)

Supplier: New York Times

+ Add rule

Like today’s contract system: a broad selection plus a higher-priority "except" rule listed under it.

+: Matches how NTB works today.
−: Priority between rules is another concept to learn.
API: Rule priority would need modelling.

Finding 3 of 10

The steps don’t lead into each other

The order is learnable (Øyvin followed it after onboarding), but each step ends in a list or a toast with no next step, results are hard to find, and inherited settings don’t link back to where they are set. A real deal (all editorial except NYT, with a discount, for a set period) needs six separate pieces.

Seen with Hege, Berkay (the deal example is a team illustration).

“I have a content group. But where is it?”
Hege

“I don’t really know what I’ve done.”
Berkay

Team notes on the board

Language help: titles, descriptions, tooltips first, then test again. Wizard (full page): low-hanging fruit. Task-focused interface (to-do list or checklist on the page). Context help is better for some users (Ferdinand).

Option A

One page with a checklist

Tried in product admin (PA2, PA5)

NTB Creative · Draft

1 Name

2 Content

3 Licenses and prices

4 Variants

5 Customer view

NameContentPricesCheckedPublish

A product is set up on one page, section by section, with a checklist beside it from creation to Publish.

+: Everything about a product in one place; you always see what’s left.
−: A long page; rare tasks (content, licenses) and frequent ones share it.

Option B

A full-page wizard

From Ferdinand

New product

1Content2Licenses3Prices4Review5Publish

Step 3: give each license a price

BackNext: Review

New product opens a wizard: content, licenses, prices, review, publish. Afterwards the product page shows the result with links back into each step.

+: Low-hanging fruit; guides first-time users like Øyvin.
−: Editing later is a different screen from creating.

Option C

Keep the pages, add the next step

Main group saved

SDL Editorial created · 12 490 imagesNext: create licenses →

On the product: Main group SDL Editorial · License group Editorial licenses (links)

Each page ends with "Next: …" and a button. Anything inherited (main group, license group) links to where it is set.

+: Smallest change to today’s admin.
−: Still six places for one deal.

Finding 4 of 10

Naming is hard because visibility is unclear

Testers didn’t know who sees what they write: product name (Hege), license description (Berkay), license terms (Øyvin). There is no preview. Labels like "Primary scope" and "editorial images" vs "editorial license" add to it. Single-language names (EN/NO/SV) is a team finding from the code, not raised by testers.

Seen with Hege, Berkay, Øyvin.

Team notes on the board

Signal whether a name or description is internal, external or both, with colour and icons. Which language should they use for the input? (Ferdinand)

An admin widget for the public site to see which product an image belongs to (Ferdinand).

Option A

Label who sees each field

Tried in product admin (PA9)From Ferdinand

Product

Name Customers see this

NTB Editorial

Note Only admins

For the 2026 newspaper deals

Every field says "Customers see this" or "Only admins", with an icon.

+: Answers the question where it’s asked; cheap.
−: Doesn’t show how it looks to customers.

Option B

Live customer preview beside the form

Tried in product admin (PA10)

License name

Web and social media

Description

Customer sees

◉ Web and social media2 500 kr

Editorial use online for 12 months.

A preview of the asset page’s license options updates as names, descriptions and prices are typed.

+: Shows the result; testers asked for a visual example.
−: Needs a sample image and a viewer to preview as.

Option C

Language tabs on customer-facing text

API change

Name

Norsk ✓English ✓Svenska · missing

NTB Redaksjonelt

Customer-facing fields have Norwegian, English and Swedish tabs that show which are filled.

+: Makes the language question explicit; ready for TT.
−: More fields to fill; which languages are required is a decision.
API: Names and texts are single-language in the API.

Finding 5 of 10

On-demand onboarding works, so keep it at hand and finish it

Berkay reopened the guide as a reference during the task. Øyvin followed its order (main group, licenses, product). The guide stops before publishing and checking the result.

Seen with Berkay, Øyvin (Hege had no onboarding).

Option A

A checklist that stays on screen

Tried in product admin (PA5)

NTB Creative · Draft

1 Name

2 Content

3 Licenses and prices

4 Variants

5 Customer view

NameContentPricesCheckedPublish

The guide becomes a checklist next to the work, ticked off as each step is done, through to Publish.

+: The guide and the progress are the same thing.
−: Takes screen space on every product.

Option B

The guide as a side panel

Products page (still usable)

GuideStep 3 of 7: LicensesA license says how a customer may use an image…Next step

Help opens the guide in a panel beside the page, not a modal, at the step you are on. Extended with publishing and checking.

+: Keeps what worked; reference while working.
−: Still separate from the work itself.

Option C

Help on the fields

From Ferdinand

License

Description

Shown to customers under the license name. Say where and how long they may use the image.

Short help text and tooltips on each field, written for the person filling it in.

+: Context help suits some users better (Ferdinand).
−: Doesn’t show the order of the steps.

Finding 6 of 10

Licenses need real usage terms

A license is a name plus free text, with no channel, duration, accounts or paid promotion. Hege negotiates exactly those per order today. Structured terms would let customers pick usage themselves and cut the back-and-forth.

Seen with Hege, Berkay.

“Editorial use on a website or in a press release. That’s where we differentiate prices.”
Berkay

Option A

Structured terms on the license

Tried in product admin (PA7) API change

Commercial use

CommercialPrintWebSocial media12 monthsPaid promotion

Business websites, ads and marketing material.

A license has use (editorial or commercial), channels, duration and paid promotion, shown as chips.

+: Comparable licenses; a base for pricing by usage.
−: Which dimensions, and their values, need agreeing with sales.
API: Licenses have no usage fields.

Option B

Customers choose by usage

API change

How will you use the image?

WebSocial mediaPrintTV

12 monthsOne publication

Web and social media2 500 kr

On the asset page the customer says where and how long they will use the image; the matching license and price follow.

+: Cuts the back-and-forth Hege handles by email.
−: Needs structured terms first; a bigger change for customers.
API: Needs structured terms and a lookup by usage.

Finding 7 of 10

Customer agreements have no home

One real deal is spread across products, discounts and subscriptions, each keyed by product. You can’t see what customer X pays for image Y. Every customer has a tailor-made deal today, and Hege asked whether NTB should keep that or standardise.

Seen with Hege, Berkay.

“NTB-production subscriptions should be two clicks instead of setting up a whole contract.”
Berkay

Option A

One agreement page per customer

Tried in product admin (PA8) API change

Aftenposten AS · Agreement

DiscountRunning

20 % off NTB Editorial, everything except NYT, all licenses

1. januar 2026 – 31. desember 2026

Image pack

10 downloads: NTB Editorial, editorial and web use

+ Add term

All of a customer’s terms on one page: discounts, subscriptions and image packs, each covering products, content and licenses for a period, written as one sentence.

+: "All editorial except NYT, 20 % off, for a year" is one term.
−: A new concept (agreement) in the API and the admin.
API: Terms are keyed by one product today.

Option B

A customer filter across today’s pages

Discounts & premiums

Customer: Aftenposten AS ▾

Editorial deal · SDL Editorial Images−20 %

Editorial deal · SDL Editorial Videos−20 %

Also on Subscriptions; a summary on the customer.

Subscriptions and Discounts get a customer filter, and a customer summary lists everything that customer has.

+: No new concept; works with today’s API.
−: A deal is still several records in several places.

Option C

A price check

Tried in product admin (PA11)From Ferdinand (admin widget)

Price check · Aftenposten AS

Sold by NTB Editorial, variant AFP

Editorial useIncluded (image pack)

Commercial use3 200 kr → 2 560 kr (deal)

Pick a customer and an image: see the price per license and which product, variant and term set it.

+: Answers "what does X pay for Y" whatever the model; also a support tool.
−: Shows the result, doesn’t make deals easier to set up.

Finding 8 of 10

Publishing and customer deals are mixed

Berkay didn’t expect subscriptions to be how a product reaches customers. The facilitator pointed to Subscriptions in tests 2 and 3, which added to it. "Workspace" didn’t say who gets the deal. The form uses discount wording, and after Berkay’s subscription the public page still showed "Add to cart" (bug). Hege sets up contracts, Berkay handles weekly deals and rarely creates products, Øyvin needs a guided path.

Seen with Berkay, Øyvin; two jobs from Daniel’s persona audits.

“Subscription isn’t necessarily what I’d connect to that process.”
Berkay

Option A

Two areas: catalogue and customers

Tried in product admin (PA1)

CatalogueProductsLicensesCustomersCustomersPrice check

The sidebar splits what is sold (products, licenses: rare) from customer deals (agreements, price check: weekly).

+: Each job has its own place; publishing isn’t confused with deals.
−: People who do both switch between areas.

Option B

Clearer words on today’s forms

New subscription

Customer

Aftenposten AS ▾

Unlimited downloads of

NTB Editorial · Editorial use

~~Workspace~~ → Customer · ~~Discount~~ wording removed

"Workspace" becomes "Customer", the subscription form drops discount wording, and each page says what it is for.

+: Cheap; fixes the most direct confusion.
−: Doesn’t separate the two jobs.

Finding 9 of 10

Special prices can’t be set for groups of customers

A discount or price list targets one workspace and one product. There are no customer groups, no "all products", and new products aren’t covered.

Seen with Berkay.

“Linking customers to product categories with set prices will save us a lot of time every day.”
Berkay

Option A

Customer groups with their own terms

Tried in product admin (PA8) API change

Customer group: Schools

50 % off all products, also new ones

From 1. januar 2026

Members

Oslo katedralskoleBergen katedralskole+ 41

A group (e.g. Schools) holds terms every member gets, on all products including new ones. A customer’s own terms come first.

+: One change reaches every member and every new product.
−: Precedence (own vs group) must be clear to sales.
API: Prices target one customer group id and one product.

Option B

Price tiers on the product

API change

NTB Editorial · prices

StandardSchoolsNGOEditorial1 500 kr750 kr900 krWeb2 000 kr1 000 kr1 200 kr

Each product has a price column per customer category (Standard, Schools, NGO); customers are put in a category.

+: All prices for a product in one table.
−: Every product needs every tier; deals beyond tiers still need terms.
API: No customer categories in the API.

Finding 10 of 10

There is no "done", and no way to check the result

Testers looked for "Publish", but products stay Draft with no control to change it. Draft is undefined and may not even gate sales. Onboarding stops before publishing, and there is no preview: asset counts are placeholders and a new subscription didn’t show on the public page. The API already supports published, so it’s a UI gap.

Seen with Berkay, Øyvin (Hege ran out of time, but couldn’t name the product without seeing the customer view).

“I’m also very dependent on seeing output.”
Berkay

Team notes on the board

Publishing a product is not implemented in the backend, and the way of publishing is not in the UI either. Button: "Publish product" (Ferdinand).

Option A

Publish with checks

Tried in product admin (PA3, PA5) API changeFrom Ferdinand (button)

Ready to publish?

Name in Norwegian and EnglishContent: 232 imagesLicenses and pricesCheck what customers seePublish product

A "Publish product" button that lists what is missing, including a check of the customer view. Drafts are never sold.

+: A clear "done"; nothing half set up reaches customers.
−: Needs a rule for what Draft means for sales.
API: Publishing isn’t implemented in the backend yet.

Option B

View as a customer

NTB Editorial

View as

Aftenposten AS ▾

Open public site ↗

Opens an image from this product with the customer’s prices.

A link from the product opens the public site as a chosen customer, on an image from the product.

+: The real result, not a preview.
−: Needs a way for admins to act as a customer on the public site.

Option C

Say why it isn’t live

Products

NTB EditorialPublished

NTB CreativeDraftNo English name, no prices

The products list shows a status per product and, for drafts, what is stopping it.

+: The overview answers "what is live?" at a glance.
−: Doesn’t show what customers see.

Pick one or more options per finding, or add better ones.
Check the options marked “API change” with the backend team before choosing them.
Mock the chosen options, or try them in a prototype: the product admin prototype shows one combination working end to end.
Test again with the same tasks, and a real deal as one task.