Product Design
What should the product do, how should it behave and what evidence should change the decision?
- Condition: The product, workflow or interface is unresolved
Six responsibilities combined around the product condition
Tcules offers Product Design, Product Modernisation, Design Systems, AI Product UX, Design Engineering and Software Development. These are separate responsibilities rather than separate departments. One engagement may need one of them or a deliberate combination. The useful buying question is not which discipline sounds closest to the brief. It is which decision needs an accountable owner, and how far that responsibility must travel into implementation.
Choose by the condition
The leading responsibility locates the unresolved decision. It does not prevent adjacent work from joining the engagement.
Product Modernisation
What should be preserved, repaired, redesigned, replatformed, selectively rebuilt or retired?
- Condition: Established software must change without losing essential work
Design Systems
Which semantics, foundations, components and operating rules should become shared infrastructure?
- Condition: Several teams keep remaking shared interface decisions
AI Product UX
What may the system do, what evidence supports it and how does a person control or recover from it?
- Condition: AI now suggests, generates or acts inside the product
Design Engineering
Which decisions must be expressed and checked in code so the released experience remains faithful?
- Condition: Product intent changes between design and production
Software Development
How should frontend, backend, APIs, integrations, AI features, QA and deployment deliver the agreed scope?
- Condition: Tcules is accountable for the running product
Why several responsibilities may belong in one engagement
A modernisation may expose a workflow that needs Product Design, a shared pattern that needs Design Systems and a release that needs Software Development. An AI product may need research, an authority model, coded evaluation and backend integration. A design system may need one real product surface to prove that its rules work in production.
Combining responsibilities is useful when the same decision must survive across them. It is risky when the scope merely bundles disciplines without saying who owns each result.
Use this responsibility test
This test prevents a familiar failure: every function completes its deliverable, but nobody owns the contradiction between them.
- 1. Name the product decision that can change the outcome.
- 2. Name the evidence needed to make it.
- 3. Name every representation the decision must survive.
- 4. Assign one accountable owner at each boundary.
- 5. Define how the released result will be accepted.
What each responsibility produces
Product Design produces a resolved product direction
The work may include research, product modelling, information architecture, workflow, interaction, interface, prototyping and evaluation. The durable result is not a collection of activities. It is a product decision whose evidence and behaviour can be explained.
Product Modernisation produces a change disposition and credible sequence
The work distinguishes local repair from deeper redesign, replatforming and selective rebuild. It records continuity constraints, enabling engineering, migration and rollout conditions rather than treating an established product as a blank canvas.
Design Systems produces maintained shared product infrastructure
The system spans semantics, tokens, components, Figma, code, documentation, contribution, release and adoption. Its scope also states which decisions remain local to product teams.
AI Product UX produces an explicit human-AI contract
The product defines context, model role, evidence, uncertainty, authority, evaluation, progress and recovery. The system's capability does not decide what the user should delegate.
Design Engineering produces verifiable correspondence between intent and implementation
Coded prototypes, component contracts, frontend architecture and implementation QA make behaviour inspectable before and after release. Design Engineering is not a prettier handoff; it is responsibility for what the interface becomes in code.
Software Development produces and evolves the running product
Tcules can deliver frontend, backend, APIs, integrations, AI-enabled features, mobile products, QA, project-specific deployment and post-launch evolution. Managed cloud operations, security operations and universal SLAs are not implied.
Audits are a smaller decision purchase
An Audit or Assessment reads something that already exists and helps the team decide what to do next. It can end with a recommendation to repair locally, defer work or avoid a larger engagement.
A Service engagement takes responsibility for changing the product. An audit is useful when the symptom is real but the responsible intervention remains disputed.
Engagement shape is separate from service scope
The same responsibility can be purchased in different forms:
Scope, outputs, working cadence and acceptance conditions are agreed before work begins. Tcules does not publish a universal minimum or force every buyer through the same sequence.
Available engagement shapes
- A bounded assessment or Sprint Zero to frame a decision.
- A fixed-scope project with a defined responsibility and end.
- Continuing product work integrated with the client's roadmap.
- Combined design and development where Tcules owns both the product decisions and agreed implementation.
AI-assisted delivery is horizontal, not a seventh service
AI may help Tcules synthesise approved research, compare product models, explore interfaces, build coded prototypes, understand an existing codebase, implement bounded changes, generate tests and maintain documentation. For repeatable work, the team may use purpose-built agents or harnesses with constrained inputs, observable outputs and explicit acceptance checks.
The capability is not the model alone. It is the operating environment around it: approved context, client tool and repository boundaries, human review, automated checks where appropriate, traceable decisions and an accountable release owner. Work that is still experimental remains supervised and does not silently become a production dependency.
This horizontal delivery model is different from AI Product UX, which defines AI behaviour in the client's product, and AI Product Engineering, which implements that behaviour.
AI Product Engineering
Implements AI behaviour in the client's product.
Start with what the product is doing to the team
Describe what is stuck, expensive, unreliable or repeatedly disputed. Tcules can route the enquiry by responsibility without asking you to diagnose the service in advance.