Insights
A product design agency decides what software should do, how it is structured and how it behaves. It is not a website shop or extra headcount. A product design agency works out what a piece of software should do, how it should be structured and how it should behave, then gives those decisions a form your engineers can
Insights · Buyer's guide
A product design agency works out what a piece of software should do, how it should be structured and how it should behave, then gives those decisions a form your engineers can build and your users can test. The work runs from research and product thinking through interaction design and visual craft to the design system that keeps the product consistent, and a good agency stays close while the product is built.
It is not the same service as designing a marketing website, producing screens for a pitch deck or filling seats with designers who own nothing. Some studios, Tcules included, also provide dedicated designers who work inside a product team; that is product design too, as long as the decisions and the context stay owned.
Tcules is a digital product design studio, so this is the work we sell. This page names no agencies and ranks none. It explains the category from the buyer's side so you can judge any provider, us included.
First, check which kind of product you mean
The phrase covers two trades. In manufacturing, product design is the work of industrial designers, who, in the words of the US Bureau of Labor Statistics, "combine art, business, and engineering to develop the concepts for manufactured products" and work with specialists such as mechanical engineers (Bureau of Labor Statistics). If you are making hardware, an industrial design firm is the provider you want, and the rest of this page will not help.
This page is about digital products: SaaS, business applications, data-rich tools, consumer apps and AI-powered software. In that market, "product design agency", "product design studio" and "product design firm" describe the same kind of provider. The label tells you little about a provider; the work it does and the decisions it takes responsibility for tell you what you are buying.
The work, from outcome to pixels
Paul Adams, writing on Intercom's blog in 2013, gave a definition that still holds: product design is about solving problems for people within the constraints of a specific business. He described the work as four layers taken from the top down: the outcome the product should achieve, the system of components and how they relate, the interactions, and only then the visual design. His warning was that a designer who starts at the fourth layer is styling, not designing a product (The Dribbblisation of Design).
The international standard for human-centred design reaches a similar shape from another direction. ISO 9241-210:2019 sets out four linked activities: understand and specify the context of use, specify what users require, produce design solutions, and evaluate those solutions against the requirements, repeating as evidence comes in.
In practice, the work a buyer should expect from a product design agency looks like this.
| The work | The question it settles | What you should receive |
|---|---|---|
| Research | Who uses the product, in what situation, and what they do today when it fails them | A record that keeps observations apart from interpretation, tied to the decision it informs |
| Product thinking | What the product must contain: its objects, roles, rules, states and what the first or next release must do | A product model, the main workflows and a stated boundary for the release |
| Interaction design | How the product behaves, including errors, empty states, permissions, partial work and recovery | A state and interaction specification, and prototypes where behaviour is uncertain |
| Visual craft | How hierarchy, typography, colour and layout make the product readable with real content | Interface design applied to realistic data, meeting the accessibility level you have agreed, such as WCAG 2.2 AA |
| Prototyping and evaluation | Whether a risky decision holds up before it becomes expensive to change | A prototype built to answer a named question, and what testing showed |
| Design systems | Which decisions should be settled once and shared across screens, teams and code | Foundations, components with their states, and rules for use and change |
| Build support | Whether the decisions survive contact with real data, components and deadlines | Review of the working product against the agreed behaviour, and decisions reopened where the build exposes a gap |
Two points in the table deserve a closer look, because they separate product design from attractive screens.
Prototypes answer a question, not "what will it look like". Stephanie Houde and Charles Hill, then at Apple, proposed in 1997 that a prototype should be described by which design question it explores: the role the product plays in someone's life, its look and feel, or how it will be implemented (What do prototypes prototype?). A polished clickable mock-up answers look and feel. On its own, it does not show whether the product model is right. An agency should be able to tell you which question each prototype is meant to answer, and what it does not prove.
A design system is shared decisions, not a component sticker sheet. The GOV.UK Design System, a public example, pairs styles and components with patterns for common tasks and the research behind them. For a single product, a lightweight version may be enough; when several teams build on the same foundations, the system becomes a product in its own right. Tcules covers that case separately in when to hire a design system consultant.
What a product design agency should not be doing for you
A studio may offer more than one of the services below, and that is fine. The problem starts when one is bought or sold as another.
A marketing website is a different job
A marketing site persuades a visitor to take a next step. A software product helps a user get work done, across roles, data, permissions and states that a marketing page never meets. The two need different research, different specifications and different testing. A strong website portfolio is not evidence of product design, and the reverse is also true. If you need both, ask to see product work with its empty, error and permission states, not only its hero screens.
Pitch-deck screens are not a specification
Concept screens for investors or a sales demo are made to persuade, and they can do that well. In Houde and Hill's terms they are look-and-feel prototypes, made without necessarily investigating the product's role or how it would be made to work. The risk comes when the deck screens become the brief for engineering, and the questions they never answered (who can do what, what happens when data is missing, what the second release changes) surface during the build. Adams titled one section of the same post "The most important product design work is usually the ugliest".
Seats without responsibility are not product design
Public-sector procurement separates two ways of buying design. The UK government's Digital Outcomes and Specialists 7 framework has one lot for suppliers who deliver specific, outcome-based digital projects, and a separate lot for specialists who bring targeted skills into existing teams (Government Commercial Agency, RM1043.9).
Where the designers sit matters less than who owns the product decisions and who holds the context. Plain staff augmentation supplies hands: you direct the work, own every decision and carry the management load, and when a person leaves, the context leaves with them. A product design studio can work inside your team in a different way. Its dedicated designers join your rituals and backlog and own an agreed set of product decisions, while the studio behind them keeps senior review and carries the context when people change. A defined project, where the studio takes responsibility for one product outcome, is the third option. All three are legitimate. Buying one while expecting another is where engagements can go wrong: an augmented designer waits for direction that never comes, or a studio is asked to fill seats and never given the access it needs to make decisions. What to keep in house, and how to keep product knowledge when you outsource, is covered in how do you outsource UX design without losing product knowledge?
When a team needs one, and when it does not
The deciding question is not whether you have designers. It is whether there is a body of product decisions that someone needs to own, settle and carry into the build, and whether your team can own it right now.
| Your situation | What fits |
|---|---|
| A new product with real demand or a working prototype, but the product model, roles and first release are still unsettled | A product design agency, starting before a large build commitment |
| An established product where screens keep being patched but the trouble sits in the workflow, rules or structure | A product design agency, or a focused audit first if the cause is disputed |
| A live product that needs a redesign without losing existing users | A product design agency that can work with the running product and your customers; see how to redesign a live SaaS product |
| An AI capability that has to act inside the product, where authority, review and recovery need designing | A product design agency with AI product experience |
| Steady, long-term design work that will keep a designer busy for years | Hiring in-house, with outside help only for peaks or specialist questions |
| Continuing product work, no senior design lead yet, and context that has to build up over months | Dedicated designers from a product design studio, owning agreed decisions inside your team |
| A design lead and backlog already in place, short of hands | Staff augmentation or contract designers working under your lead |
| A fully specified product that needs engineering capacity | An engineering partner, not a product design agency |
| A brand, launch campaign or marketing site | A brand or web studio |
Government guidance offers a useful test for the first row. The GOV.UK Service Manual says a team should not start building in discovery, and that it is not a failure to stop at the end of discovery if the research shows that is the best course (how the discovery phase works). A product design agency worth hiring for a new product should be willing to tell you the same.
What to expect from an engagement
The shape follows the problem. Engagements take three broad forms: a bounded assessment or audit when the symptom is visible but the cause is disputed; a defined project on one product area, from research through to tested direction; and a continuing relationship, sometimes with dedicated designers working inside your team, where the value comes from context building up over months. A good agency proposes the smallest shape that answers your question, and says so when a smaller or different engagement is the better first move.
The first weeks are spent learning the product as it exists. Expect requests for the running product, analytics, support tickets, design files, technical constraints, previous decisions and time with the people who know why things work the way they do, including customer-facing staff and engineers. The GOV.UK Service Manual makes a related point for public services: it sets out user research for every phase of a service, from discovery to live, not only for the start. An agency should not repeat research your team can already support; it should not skip research the decision needs.
You still provide decisions and access. Someone on your side has to be able to say yes, no or not now, and to accept the work. Without a named decision owner, the agency is left to guess, and a guessed decision has no one to defend it when the build questions it.
The output is decisions with their reasons. Files matter, but the durable asset is a record another person can pick up: the product model, the states and rules, what was tested and what changed as a result. If the engagement ends with a folder of screens and no reasons, your next designer starts again.
Design stays close as the build starts. Some questions only appear with real data, real components, responsive layouts and accessibility constraints. Whether the agency also builds or hands to your engineers, someone has to check that the agreed behaviour survived implementation and reopen the decision when it did not. If your product began as an AI-generated prototype, the path from there to production is its own question; see I vibe-coded an app. Now what?
Cost follows uncertainty, not screen count. The things that drive the size of an engagement are how many roles and workflows the product has, how much of the product model is still unsettled, how much research access exists, whether visual craft and a design system are in scope, and whether the agency also carries the work into code. Fixed scopes suit questions that are already well framed; time-based or continuing arrangements suit work where the research is expected to change the plan. A proposal priced per screen is pricing the fourth layer.
How to tell whether an agency does product design
Six questions will separate product design from interface styling in a first conversation:
- "What would you need from us before you could make a decision?" Listen for access to users, the running product and a decision owner, not only a brand guide and a list of screens.
- "Show me a piece of work before it looked good." Ask for a product model, workflow map or state diagram from a past project, and the decision it changed.
- "Which question would your first prototype answer?" A specific answer is a good sign; "it shows what the app will look like" is not.
- "What happens to the design once engineering starts?" You want a named way of checking the build and reopening decisions, not a handover meeting.
- "What will we own at the end?" Source files, research records and the reasoning behind decisions, in accounts you control.
- If they offer dedicated designers: "Which decisions will your designers own, who reviews their work, and how does a replacement pick up the context?" You want named people, a senior reviewer on their side, and a decision record a newcomer can read, not just a promise to backfill the seat.
If you are assessing a narrower audit provider rather than a design partner, the questions in how to choose a UX audit agency go further on that case.
Where Tcules fits
Tcules is a digital product design studio creating ambitious new software products and making established ones better. Product Design is the foundation of the practice, extended by Design Engineering and Software Development, with a particular focus on SaaS. The studio was founded in 2017, is based in Ahmedabad, India, and has worked on more than 90 projects for clients across 19 countries.
We work in two ways: as a studio that takes responsibility for a defined product outcome, and with dedicated designers who join a product team and carry agreed product decisions over months, with the studio providing continuity, context retention, roadmap support and specialist depth, so the team has less to manage. Our Product Design work connects research, product structure, workflow, interaction and evaluation under one accountable responsibility, and sets out where it ends and where design systems, design engineering and software development begin. How we work describes how an engagement is agreed, who owns which decisions and the ways to begin, from a bounded assessment to end-to-end design and software delivery.