Product design studio website

What a product design studio website should help you decide

A product design studio website should make it easier to assess whether a studio’s way of working fits a precise software problem. For founders, operators and small teams, the useful question is not whether a site looks polished. It is whether it explains how a vague opportunity becomes a bounded product decision, release and improvement cycle.

Look for a clear account of the problem being addressed, the intended audience, the scope of an initial release and the evidence that would change the next decision. A good website can describe these things without promising that every product will succeed. It should help you understand the studio’s operating assumptions before you begin a conversation.

IVRYN is an independent Paris-based product studio with separate product sites and audiences across its current work. Its public material frames product work around focused scope, useful measurement and automation used with care. That context bounds this article: it describes how to read a studio website and plan a product engagement, not proof of results from a universal process.

• Can the site state the user problem in plain language?
• Does it distinguish an initial release from a finished product?
• Does it explain what would be measured or learned next?
• Does it show how accessibility and responsible automation affect choices?

Start with problem clarity, not a preferred solution

The strongest signal on a product design studio website is problem clarity. A studio should be able to describe who has a difficulty, what they are trying to accomplish, where the current path breaks down and why the problem deserves attention now. This is more useful than a long menu of design deliverables because it gives you a basis for judging scope.

Problem clarity also exposes limits. If the audience, context or desired change cannot yet be described, a studio website cannot honestly prescribe the right product. At that point, discovery may be the work: defining the decision to make, the assumptions to test and the smallest useful artefact to create.

Be cautious with language that treats a feature list as a problem statement. “Build a dashboard” is an output. “Help a small operations team spot unassigned work before a handoff is missed” is a problem that can guide trade-offs in interface, data and release scope.

• Name the primary user and their moment of need.
• Describe the current workaround or friction.
• State the decision the product should improve.
• List assumptions that could invalidate the proposed direction.

How a product design studio website should explain releases

A website should help you tell the difference between a proof of concept, prototype and minimum viable product. These labels are often used loosely, but they serve different questions. A proof of concept checks whether a technical approach is feasible; a prototype makes an interaction or concept easier to evaluate; an MVP is a usable minimum release intended to test value in a real product context.

That distinction matters because the wrong artefact can create false confidence. A clickable prototype may clarify navigation without demonstrating that a service can operate reliably. A proof of concept may establish feasibility while saying little about whether users can understand or adopt the product. An MVP should not be treated as a shortcut around design; it requires a deliberate boundary around what is necessary to create and assess value.

When reading a product design studio website, ask which uncertainty a proposed release is meant to reduce. The answer should connect the format of the work to a decision, rather than presenting “MVP” as a generic promise of speed.

• Use a proof of concept for a feasibility question.
• Use a prototype for a comprehension or interaction question.
• Use an MVP when a narrow usable release is needed to assess value.
• Avoid treating any one of these as evidence for every other question.

Product design studio website checklist: evidence, accessibility and measurement

A credible product design studio website should make its evidence boundaries visible. It may describe methods, principles and intended measurements, but it should not turn plans into outcomes. If a case description does not specify what was observed, how it was measured or what the limits were, treat it as an illustration of approach rather than a proven result.

Accessible interfaces belong in the scope from the beginning. Accessibility is not only a final compliance pass: clear labels, understandable states, keyboard support, readable contrast and resilient content structure affect whether a small release is usable by more people. A website does not need to promise perfect coverage to show that these needs influence design decisions.

Measurable product outcomes should be tied to the original problem. A metric is useful when it helps a team decide whether to continue, adjust or stop. For example, a team might monitor whether intended users can complete a defined task, but the measure should be chosen with its limitations in mind. Raw activity alone does not establish usefulness.

• Check whether claims are separated from plans and hypotheses.
• Ask how accessibility requirements enter design and testing decisions.
• Choose one outcome measure and one qualitative signal for an initial release.
• Define what result would prompt a change in scope or direction.

Worked example: deciding what to ask a studio to build

Example: a five-person service business loses track of client requests that arrive through email, chat and notes. The team initially asks for “an AI operations platform.” A more useful product question is whether a shared intake view can help the assigned person identify, classify and respond to new requests before they become missed work.

A sensible first step might be a prototype if the key uncertainty is whether the team can understand and act on the proposed workflow. If the main uncertainty is whether messages can be collected from a specific source, a proof of concept may be more appropriate. If both the workflow and connection are sufficiently understood, a small MVP could support one request channel, one owner assignment rule and one status view.

The initial release should exclude tempting extras such as forecasting, broad automation and a full reporting suite unless they are required to answer the core question. The team could define a measurable outcome as the proportion of incoming requests assigned within an agreed window, while also collecting notes about cases the workflow does not fit. This would not prove a business outcome by itself, but it would give the team a clearer next decision.

Responsible automation in this example means keeping people able to review classifications and assignments, especially when unclear messages or exceptions could affect clients. The appropriate level of automation depends on the cost of error, the sensitivity of the information and the team’s ability to supervise the system.

• Problem: requests are missed because intake is fragmented.
• Small release: one channel, assignment, status and reviewable automation.
• Measure: timely assignment for the defined workflow.
• Limit: the result may not generalise to other channels or client types.

Limits of what a studio website can tell you

A product design studio website is a starting point for evaluation, not a substitute for shared discovery. It can explain principles, show the kinds of questions a studio considers and help you prepare a focused brief. It cannot determine your users’ needs, validate an untested assumption or guarantee that a release will produce a commercial result.

It also cannot settle every operational question. Data access, technical constraints, internal ownership, regulatory requirements and the availability of participants can materially change what a small release should contain. Those constraints should be surfaced early rather than hidden behind a standard process.

Use the website to form specific questions: What is the first decision we need to make? Which release type fits that decision? What evidence will count, and what will remain uncertain? A studio that can answer these plainly gives you a better basis for deciding whether to proceed.

• Do not confuse a methodology with proof of a result.
• Do not assume a portfolio presentation predicts fit for your situation.
• Treat scope, evidence and decision criteria as topics to agree before work begins.