Digital products: which parts are design and which are technology?
Clearly understand which parts belong to the designer and which parts belong to the technical team, so you can match the right people to the right tasks from the very beginning.
The digital product designer handles the experience part: user research, flow, wireframe (rough interface layout), complete interface, design system, and specifications delivered to the development team. The foundational technical part belongs to the technical team or software company: backend (server and data processing), database, infrastructure, and complex system integration. You should define this boundary from the start to avoid gaps appearing during the project.
- Your team already has programming capabilities and can build it themselves; they just need to hire a UI designer.
- A bridge is needed between the design intent and the technical team; choose design along with coordination during development.
- Projects with multiple parties involved need to clearly define the scope from the start.
- Expecting a designer to both design and build a complex backend.
- products with deep technical components like banking or ERP without a dedicated software company.
Digital product design is divided into two layers: the experience and interface layer, and the foundational technical layer. These two layers need each other but are handled by people with different expertise. Clearly defining the boundaries helps you assign the right people to the right tasks and prevents gaps from appearing during the project.
The part related to design
The experience and design layer typically includes:
- User experience research: interviews, journey mapping, identifying pain points.
- Design user flow: outline how users navigate through each step in the product.
- Wireframe (raw interface structure): a sketch of the screen layout before implementing the actual interface.
- Complete interface design: colors, typography, layout, states, transition effects
- A design system: a consistent, reusable component library for the entire product.
- Deliverable specifications: detailed descriptions of behavior, dimensions, and conditions for the development team to accurately realize the intent.
For projects that require tight collaboration, the designer should also work with the technical team during the development process.
The part related to technology
A design studio is not a software company, so the following parts belong to the programming team or software partner:
- Backend (server, business logic processing behind the interface)
- Database: design, optimize, operate
- Infrastructure: server, cloud, system security.
- Integration of complex systems: bank payment gateways, ERP, heavy real-time systems.
- Platform performance: loading speed, load capacity, optimization of technical algorithms.
Business metrics like conversion rates or revenue cannot be guaranteed by the interface alone, as they depend on strategy, pricing, operations, and many factors beyond the interface.
A good product solution arises from the collaborative give-and-take between design and engineering, not from one-way request passing.
Marty Cagan, INSPIRED and EMPOWERED
Therefore, the designer's role is to design and coordinate closely, not to replace the programming team.
Two collaboration models in practice.
Model 1: hire a separate designer, your team builds it. Suitable when the programming team has sufficient capability and only needs to receive the design files along with specifications to start building immediately.
Model 2: design with collaboration throughout the build process. Suitable when a strong connection between design intent and the technical team is needed: the designer participates in reviews, answers dev questions, and adjusts designs when encountering real technical limitations.
Clearly define the model from the very beginning so that all parties know each other's expectations and no one overlaps roles.
Common mistakes when not defining the scope
- Expecting a designer to both design and build the backend leads to role confusion midway through the project.
- Do not finalize who is responsible for technical aspects from the beginning; gaps between parties may be discovered only during implementation.
- Considering the handover of design files as complete, overlooking the coordination step for the dev team to understand the intent correctly and handle exceptions properly.
- Creating products that require deep technical expertise, such as banking or ERP, without a dedicated software partner.
- Expectations that the interface design will ensure conversion rates or revenue.
How to balance when forming a team
There are three questions you should answer before choosing people. Does your technical team already exist, or do you need to find one? Who makes the decision when design and technical aspects conflict? Which part of the product is the most prone to errors if misunderstood?
When it is clear who does what, the project runs smoother, there is less role confusion, and the final product aligns better with the intent.
Decision checklist
Subject: Digital product design: which parts belong to the designer and which parts belong to the technical team. Sinh Vũ guide, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Sinh Vũ P1 service policy (Boundaries), internal documentation. Marty Cagan, INSPIRED and EMPOWERED (books, original English versions).
Frequently asked questions
Can one party design and program the entire product?
It may work for small products, but usually each side excels in one layer. Experience and interface design require user-centered thinking. Backend and infrastructure need specific technical capabilities. For complex products, correctly pairing both sides often yields better results than having one side take on everything.
After receiving the design, will my dev team understand and implement it correctly?
It depends on the quality of the deliverable. A good deliverable includes specifications (detailed descriptions of behavior and state), a clearly structured design file, and sufficient guidelines for the dev team to follow. For complex projects, it's advisable to have a designer participate in the review during the build. Both sides need to agree on this from the start to understand each other's expectations.
If my product needs to integrate banking or handle heavy data, what about that?
The deep technical part belongs to the expertise of specialized software companies. The experience and interface for that product can still be designed separately, but the integration and infrastructure require a technically skilled team. Clearly defining who does what before starting is a step that should not be overlooked.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.