Consulting for Product Management, UX and Usability

UX Consulting and Usability: What Gets Built and Whether It Gets Used

UX and product management consulting focuses on two decisions that overlap in everyday practice but are rarely demonstrated together: what a product should be capable of next — and whether what has been built is truly usable in its users’ day-to-day work. The first decision is made in prioritization, roadmaps, and value propositions; the second is made on the screen, in forms, and in click paths. The topic becomes important as soon as a release is launched but usage doesn’t follow, as soon as support has to answer the same inquiry repeatedly, or as soon as a product plan must be defended against multiple functional areas without anyone being able to substantiate the underlying assumption. What it takes is evidence from real use, a prioritization that is also able to say no, and a design that holds up all the way into implementation.

Frame Your Product Question View the Topic Areas

Product owner in front of a wall of design sketches for an application

Leading companies trust our network

Two Decisions

What UX and Product Management Consulting Delivers — and What It Does Not

Product planning at the board: assumptions are made visible before the next product stage is decided

UX consulting — called usability consulting, UX strategy or, with an eye on the commercial side, product management consulting, depending on the house — works on a single weak point: the unproven assumption. Every digital product is based on assumptions about what tasks its users want to accomplish, how much that’s worth to them, and how they go about doing it. As long as no one tests these assumptions, the loudest voice in the room prevails, and the error only becomes apparent after release — but by then, it’s already built into the software.

It separates the product question from the design question. “Should we build this?” and “Is what we’ve built usable?” are two questions requiring two different types of validation and often involving two different people in charge. In many organizations, there’s a process for one but no one accountable for the other. Those who mix the two end up discussing buttons while the prioritization remains unresolved — or vice versa.

It replaces assumptions with evidence based on real-world usage. There’s a set of practical tools for this: user interviews, task analysis, UX research using real tasks instead of opinion polls, prototypes that are allowed to fail, and usage data from live operations. The value lies not in the method, but in the order: the riskiest assumption is tested first, because only it can still derail the plan.

It treats usability as a requirement that must be demonstrated, not as a matter of taste. Whether a form is labeled clearly, whether the contrast is sufficient, whether a process can be completed using the keyboard — these are verifiable, not negotiable. Since the German Accessibility Strengthening Act (BFSG) came into force, part of this has also been legally required for products in the consumer market. That turns a design debate into an acceptance criterion.

The same service is requested under a range of labels: UX consulting, UX consultant, user experience consulting, product management consulting, product discovery, usability testing or service design — project briefs and job postings usually reach for one of these. Bilingual staffing is the norm for us, not the exception.

What it does not do. It does not make product decisions for you: what gets prioritized and what gets rejected remains the company’s decision, because it ties up budget and commitments to customers. Nor does it replace development capacity — a tested design that nobody has implementation time for changes nothing. And it does not rescue a product whose benefit does not exist: where the user’s task is not met at all, better usability only makes the route to the wrong place more comfortable.

Where this page ends: ideation, portfolio, and business model are the subject of innovation management consulting. We describe the pricing model and willingness to pay in pricing consulting, and the way the teams around the product work in agile transformation consulting.

Anzeichen

When External Support on Product and Interface Is Worth the Effort

Product and UX work is an ongoing task; external support is not. It’s worth it when a decision needs to be made for which the company lacks the evidence or experience — and when an outside perspective is less costly than making a mistake. The signals below are the ones houses actually approach us with; this is not an exhaustive list, but rather the most common starting points.

1. A Release Is Out and the Usage Does Not Follow

The feature is complete, but measurements show it’s hardly ever used — and no one can say whether it’s hard to find, difficult to understand, or simply unwanted.
These three causes call for three completely different solutions; the most expensive one is usually the one chosen.
A brief usability test with real-world tasks helps distinguish between the cases before recreating the feature.

2. Product Planning Is a Wish List From Several Departments

Each department has submitted its request; the order reflects bargaining power.
What was rejected isn’t recorded anywhere, so it will come up again in the next round.
A transparent prioritization requires a criterion that is independent of the proposer.

3. Support Keeps Answering the Same Question

The same follow-up question over and over, the same part of the process, the same workaround within the team.
The effort ends up in service costs rather than in product development, where it originated.
Support and usage data pinpoint the spot very precisely, once someone brings them together systematically.

4. A New Product Is to Meet an Unknown Market

The project has been approved, the target audience has been defined, but no one from that group has been consulted.
The riskiest assumption rarely lies in the technology, but rather in whether the problem is actually a pressing one.
A few in-depth conversations and a testable prototype will determine the scope of the project.

5. The Interface Has Grown and Nobody Owns It

Over the years, several teams have developed their own templates: different forms, different terms for the same thing.
Every change becomes more expensive because it has to be updated in multiple places.
A shared inventory view and standardized building blocks make this growth manageable again.

6. A Tender or an Audit Requires Accessibility

Accessibility is promised or required, but no one has ever tested it using a reliable method.
The most common violations are mechanical in nature and can be fixed inexpensively — as long as they are found early.
After acceptance, the same correction costs many times more because it affects surfaces that have already been delivered.

Do any of these sound familiar? In a brief initial consultation, we’ll determine which assumption needs to be substantiated first, what kind of evidence is sufficient — and whether an outside expert is even necessary.

Plan the Next Piece of Evidence

Topic Areas

The Topic Areas: From Product Strategy to a Usable Interface

The topic areas can be staffed separately or as a bundle. They are interdependent because each one requires the next: A value proposition without user research is merely a claim; product planning without design expertise remains a statement of intent; and a tested design without building blocks for development is just an image. Where to begin depends on which of the three sides is weakest in the house: market knowledge, decision-making capability, or design.

Product Strategy and Value Proposition

Who the product is designed for, what problem it solves better than the previous makeshift solution, and how its success will be measured. Everything else follows from this definition — it is also the reason why a product can say “no” without appearing arbitrary.

User Research and Discovery

Conversations with real users, observing how tasks are performed in everyday work, and prototypes designed to disprove assumptions. UX research doesn’t provide opinions here, but rather answers to specific questions — and it does so before any development time is committed.

Prioritization and Product Planning

Organize the many legitimate requirements into a logical order: by impact on the user’s task, by risk associated with the underlying assumption, and by implementation effort. This includes documenting rejected items in writing so they are not renegotiated in every round.

Interaction Design and Interface

Walking through the process: What appears on the screen, what terms does the product use, how many steps does the most common task require, and what happens when an error occurs? This is where it’s decided whether a good product idea will succeed in everyday use or fail because of its usability.

Usability Testing and Accessibility

Testing based on tasks rather than personal preference: Can real users complete the process without assistance? And does the interface meet recognized requirements for contrast, labeling, keyboard navigation, and structure? Both aspects are measurable and therefore subject to acceptance testing.

Design System and Handover to Development

Reusable building blocks, defined states, documented rules — so that multiple teams can build the same interface rather than six different versions of the same form. Handing off to development is part of the design process, not a step that comes afterward.

Where the biggest difference would arise for you is roughly outlined in twenty minutes — including the uncomfortable answer if external support brings nothing at this point.

Narrow Down the Topic Area

Engagement Models

The Forms of Engagement — and When Each One Holds

External product and UX professionals can be integrated in very different ways, and the choice you make has a greater impact on the outcome than the profile itself. A one-time review of an upcoming decision is different from a role that’s a permanent part of the team, and both are different from ownership on an interim basis. Two questions are key: Who carries the product decision in the end, and how much context does that person need for it?

Determine the Engagement Model

Review

Evidence for an Upcoming Decision

A specialist with a narrowly defined scope of work: to verify an assumption, test an interface against real-world tasks, and assess its level of accessibility. The result is a written report with supporting evidence and a recommendation — without any overarching structure.

Add-On

A Team That Is Missing One Role

The team is working, but one function is unfilled: nobody runs user interviews, nobody designs, nobody keeps the priority order. The external specialist takes on that role while operations continue and works with the tools already in the house.

Stand-In

Product Ownership on an Interim Basis

In the event of a vacancy, parental leave, or a major concurrent project: someone takes over the product on an interim basis, makes decisions within the established framework, represents the team internally — and leaves a documented status report for the successor.

Build-Up

Building a Product Function

The house has software, but no product management and no design function. The task is not a single initiative but the ability to work: responsibilities, decision paths, a shared understanding of what counts as evidence — with handover to your own people.

Contexts of Use

Contexts of Use: Where the Reality of Operation Decides Product Success

The context of use determines what good design actually means. Someone who uses an application for work eight hours a day needs speed, a keyboard, and familiarity; someone who opens it once a year to fill out an application needs guidance and clarity. Someone who operates a machine while wearing gloves needs large targets and error tolerance. That’s why we staff product and UX roles based on contextual experience rather than tool knowledge: An interaction designer familiar with regulated application workflows understands within the first week why a required field can’t simply be omitted there — someone without that experience would take months to figure it out, often against resistance. The same logic applies to the product side: at what intervals can features be delivered, who must approve them, and what documentation is required for acceptance. The following contexts are those in which our network is most densely staffed; they serve as examples, not as limitations.

Assignment Scopes

Assignment Scopes in Product and UX: What Has to Be Evidenced

Product and UX projects differ less in terms of effort than in what needs to be documented in the end. If you define this in advance, you can accept the final result; if you leave it open-ended, you’ll end up with a presentation. The following scopes are examples from our portfolio — each with the specific deliverable against which it must be evaluated.

Evidence Ahead of a Larger Investment

Before committing the development budget, the riskiest assumption should be evaluated: Does the task exist, is it pressing enough, and is the planned approach feasible? Evidence consists of a decision-making proposal backed by documentation from user interviews and a tested prototype — and explicitly includes the option to cancel the project.

Reworking an Existing Interface

An application is in use, but it is being bypassed, used incorrectly, or generating support costs. The evidence is not the new appearance, but in changes to a predetermined metric: the processing time for the most common task, the abandonment rate for the process, or the number of support inquiries.

Building Product Management as a Function

The company delivers software, but without clear ownership of the priority order and the value proposition. The evidence is the ability to work: a maintained priority order with reasoned rejections, a recurring decision rhythm, and people within the company who can carry out both without external guidance.

Design System and Proof of Accessibility

Multiple teams are working on the same interface, and an audit or request for proposal requires verifiable accessibility. Proof consists of mandatory building blocks with documented statuses, a recorded baseline, and a completed list of defects — not a promise that attention will be paid to this in the future.

How a Product Assumption Becomes an Evidenced Decision

Not a procedure, but the order in which product and UX work produces its evidence. It is independent of who does the work — and it explains why the order isn’t arbitrary: Each step can render the next one unnecessary.

The assumptions of a product initiative are named and sorted by risk

1. Write the Assumptions Down and Take the Riskiest First

What must be true for this project to succeed? User needs, benefits, willingness to pay, technical feasibility — listed separately.

The order follows the damage an error would cause, not the effort the test would take.

Skip this step and you end up testing what was obvious anyway.

Observing the user task in everyday work as the basis for the product decision

2. Clarify the User and the Task

Who is doing the task today, using what makeshift solution, and how much does it cost them?

Observation in everyday work situations is more revealing than interviews: People describe their actions differently than they actually perform them.

The result is a task description against which each design can later be evaluated.

A prototype is tested with real user tasks before development starts

3. Gather Evidence From Real Use

Prototype, test task, real users — and explicit permission for the design to fail.

Usage data from the product already in operation completes the picture wherever it is running.

What is evidenced is not approval, but whether the task gets done without help.

A product decision is recorded with its reasoning and the documented rejection

4. Decide — and Record the Rejection

The decision remains within the organization; the proposal makes it justifiable and transparent.

Whatever is not built is documented with a reason, so it does not return in every round.

At the same time, it is determined what would later indicate that the assumption was incorrect.

User flow and interface states are tested and handed over before implementation

5. Design and Test Before Anything Is Built

Operating procedures, terms, states, and error conditions are designed and verified against the task specification.

Contrast, labelling, keyboard operation and structure are settled here, not raised as a complaint afterwards.

We hand over what a development team can implement without needing to ask for clarification.

Usage data after the release is measured against the metric set beforehand

6. Measure Usage and Follow Up

After the release, measurement runs against the metric set beforehand, not against the impression.

Support and usage data show where the design behaves differently in everyday use than it does in testing.

What does not hold up is taken back again — that, too, is part of product ownership.

Price Range

What UX and Product Management Consulting Costs: Daily Rates and Budget Ranges

Product and UX experts are billed at a daily rate; we do not offer a flat fee for the entire project. The level depends on five factors: the decision-making scope of the role, the usage context of the product (regulated applications, medical devices, and industrial user interfaces sit above the average), the proportion of on-site work, the duration of the assignment — the longer the assignment, the lower the daily rate — and how scarce the desired profile is on the market.

In the Product Management & UX functional area, our inventory currently ranges from €500 to €1,800 per day.

Interim Head of Product

€1,200 – €1,800 per day
Freelance AI Product Manager

€900 – €1,400 per day
Freelance Product Manager, Strategy

€850 – €1,250 per day
Freelance Digital Product Manager

€750 – €1,100 per day
Freelance Product Manager

€700 – €1,000 per day
Freelance Product Owner

€650 – €950 per day
Freelance Product Designer

€600 – €950 per day
Freelance UX Designer

€550 – €850 per day
Freelance UI Designer

€500 – €800 per day

Every range is stated at the same level on the corresponding role page.

Here’s how to budget a project. The planning unit is the person-day. A bounded piece of evidence ahead of an investment decision — user interviews, a prototype, a decision proposal — typically ranges from 10 to 25 person-days. For the revision of a coherent process — including design, testing, and handover — it’s more like 25 to 50. A role that remains part of the team on an ongoing basis follows a different calculation: two to four days a week, for as long as work on the product continues. When building a product feature, time for the handover to your own people is added — without it, the mandate ends along with the knowledge it has generated.

The meaningful figure isn’t the rate itself, but its share of the total development effort: Where a team is engaged for half a year, ten days of upfront evidence pay for themselves as soon as they prevent a single month of misaligned work. For an application with a handful of internal users and little pressure to change, an external mandate is hardly worth it — we make that clear before a proposal is even drafted.

What sets us apart from an agency and a consulting firm. You pay the specialist directly, not the overhead structure above them: no budget management, no partner fees, no surcharges for toolkits or slide decks. Conversely, there is no apparatus and no creative department here — what gets staffed is a single specialist or a small group, and product ownership stays with you. We steer clear of performance-based models: they reward convenient numbers and penalize uncomfortable evidence.

Matching a profile to a task is the real decision point: A tested interface requires different experience than a reasoned priority order. The full inventory is listed under Product Management & UX—including Freelance Product Manager, Interim Head of Product, Freelance UX Designer, and Freelance Product Owner. Adjacent to it we also staff Software Engineering & Architecture, Data Engineering & Data Science, and Customer Service & Experience.

95.9%

of the one million most visited home pages showed automatically detectable violations of the WCAG 2 requirements in February 2026 — up from 94.8% the year before, and the first increase in six years.

WebAIM Million 2026, analysis of 1,000,000 home pages

51%

of the home pages examined contain form fields without a label — the error that makes sign-in, search and ordering unusable for part of the user base.

WebAIM Million 2026, most common error types

56.1

detected barriers per home page on average, 10.1% more than a year earlier: interfaces grow faster than they are tested.

WebAIM Million 2026, detected errors per page

UX consulting determines whether a digital product actually solves its users’ task and whether it can be used without assistance. It relies on user interviews, task analysis, prototypes, and testing against real-world tasks — and it delivers evidence, not judgements of taste. The term is often used interchangeably with usability consulting or UX consulting; anyone who also means the commercial side speaks of product management consulting.

Both address different questions. Product management decides what gets built and in what order — it is responsible for the value proposition, prioritization, and rejection of features. UX owns whether what has been built is usable—user flow, terminology, states, error handling, and accessibility. In small houses one person carries both; as soon as multiple teams are working on the same product, they are two roles with two separate obligations to provide evidence.

Billing is based on a daily rate. In the Product Management & UX functional area, our current rates range from €500 to €1,800 per day, as listed for each role on the respective role page. For a project, the number of person-days is the relevant metric: a scoped proof of concept prior to an investment decision typically ranges from 10 to 25 days, while the revision of a related process ranges from 25 to 50 days.

The rate follows the decision-making scope and the usage context, not the tool. A role that leads a product organization and is responsible for commitments to customers ranks higher than a role that designs a specific user flow. On top of that come context premiums: regulated applications, medical devices, and industrial user interfaces require documented work and experience with compliance obligations.

A usability test checks whether an existing design is usable: It answers the question, “Does this work?” UX research answers the upstream question, “Is this the right approach?” — through interviews, task observation, and prototypes designed to disprove a hypothesis. As long as it’s unclear whether the task is even a pressing issue, conducting a usability test out of order is a mistake: it optimizes the path toward a goal that no one is pursuing.

By defining the metrics before the work begins — not afterward. Key metrics include the processing time for the most common task, the abandonment rate for a specific process, the number of support inquiries, the error rate in data entry, and the activation rate of new users. What cannot be defined in advance cannot be attributed afterward; therefore, the metric belongs in the assignment and not in the closing report.

The German Accessibility Strengthening Act (BFSG) transposes the European Accessibility Act into German law and requires that new products and services introduced to the consumer market — including online stores, banking services, and e-books — meet accessibility to the recognised state of the art; public entities are already bound by these requirements. In practice, this means: sufficient contrast, labeled form fields, full keyboard accessibility, logical structure, and text alternatives. A legal review is necessary to determine exactly how your product is affected; we do not provide legal advice, but rather implement the technical and design requirements and verify compliance.

It is worth it when a decision needs to be made for which the company lacks the necessary evidence or experience, when a role is vacant while the product continues to be developed, or when an outside perspective can prevent a costly mistake. It is not worthwhile if the decision has effectively already been made and only needs to be justified, if no development capacity has been allocated for the outcome, or if the root cause lies in the collaboration between teams — in that case, it is not a product issue but an organizational one.

You can rely on us

Excellent. We are not the only ones who think so.

consultingheads has received several awards from leading trade magazines and independent third parties.

Award for consultingheads: F.A.Z. Institut TOP Berater 2026

Award for consultingheads: kununu Top Company 2025

Award for consultingheads: kununu Top Company 2024

Award for consultingheads: kununu Top Company 2023

Initial Conversation

Let Us Talk About the Next Stage of Your Product.

Your product question framed in twenty minutes

The riskiest assumption named, not a catalogue of methods

Daily rates per role are published openly in advance

A short initial conversation in which we sort through your situation and name which assumption needs evidence first — and whether we have the right people for it.

Book an Initial Conversation