Designers, Developers and Engineers Building Together
Most products fail at the seams — between the design file, the codebase and the circuit board. Here is how we think about designers, developers and engineers building together instead of passing work over a wall.
Products rarely fail in the middle of a discipline. They fail at the seams.
The design looked right, but the developer didn't know what the empty state was meant to be. The firmware worked, but the app assumed the device would always be online. The board was elegant, but the enclosure had no room for the connector the client actually needed. Each team did its job. The product still broke.
That is the problem cross functional product development is meant to solve — and it is the reason designers, developers and engineers at Incrix build together rather than in sequence. This article explains how we think about it: the principles, the hand-offs, and why a small team spanning software, hardware and design has an advantage here.
TL;DR
- The seams are the risk. Most product problems live between disciplines, not inside them.
- Hand-offs are conversations. A Figma file, a schematic or an API contract starts a discussion; it doesn't end one.
- Constraints travel both ways. Hardware limits shape interfaces, and interface needs shape hardware.
- Small helps. A 15-person team under one roof can involve every discipline from the first sketch.
The wall we don't want to throw work over
The traditional way to build a product is a relay. Someone gathers requirements. A designer produces screens. Developers build from the screens. Hardware, if there is any, happens somewhere else on a separate timeline. At each stage, work is "handed off" — which in practice often means thrown over a wall.
We have said before that traditional companies take requirements and write code, and that this tends to be costlier to build and to maintain. Our alternative in software is to understand the problem, architect an engineering solution, and then design the application. Cross-functional product development is the same idea applied to people: bring the disciplines together around the problem before anyone commits to a solution.
Designers and developers: from Figma to working software
For our software work and for Classory, design lives in Figma. That matters less because of the tool itself and more because of what a shared, live design file allows: developers can see work in progress, comment early and inspect exactly what a component is meant to do.
In principle, a good design-to-development hand-off covers much more than the "happy path" screen:
| What design hands over | Why developers need it |
|---|---|
| Components, not just screens | Reuse keeps the interface consistent and the code smaller |
| Every state: empty, loading, error, success | Real users spend a surprising amount of time in the unhappy states |
| Behaviour on small screens | Many people reach a product on a phone first |
| Content rules — lengths, truncation, languages | Real names, course titles and brand copy are never the length of placeholder text |
| The intent behind a decision | So that when something must change in build, it changes in the right direction |
The last row is the one that separates a hand-off from a conversation. When a developer understands why a layout works the way it does, they can make sensible trade-offs during build without breaking the design.
Where UX engineering fits
Between design and development sits a discipline often called UX engineering: turning design intent into faithful, well-built interface code. It is where accessibility, interaction details and edge cases either get handled or quietly dropped. The Nielsen Norman Group has published extensively on usability and on how design and development teams can work better together, and it is a resource we recommend to anyone crossing that line.
At Incrix, having a product designer who is also our C.I.O helps keep that seam narrow. Design decisions and architecture decisions are made with each other in view, rather than negotiated later.
Engineers and developers: where hardware meets software
Hardware adds a harder kind of seam. You can change a line of code in minutes; changing a PCB after production is slow and expensive. That asymmetry is exactly why embedded engineers and software developers need to talk early.
On a connected product, the conversation typically runs along a path like this:
Each step pushes constraints in both directions. If the device will live somewhere with patchy connectivity and unstable power — conditions we design for as a matter of course in India — then the app cannot assume a live connection, and the firmware has to buffer, retry and resume. If the interface needs to show something in real time, the hardware needs to be able to report it. We go deeper on this boundary in where hardware meets software.
Our embedded architects work across firmware, multi-layer PCB design and connected cloud, which means the person designing a board usually understands what the software on the other end needs. That is a big part of how Incrix Automation takes a board from silicon to cloud.
Designers and engineers: the product people can hold
The third seam is often forgotten: the one between design and hardware. A physical product also has to be understood, trusted and used. Labels, indicators, packaging, documentation and the companion app all shape whether a well-engineered board feels like a finished product.
This is where our brand and design team and our content team matter. A product is not done when it works; it is done when someone who didn't build it can pick it up and succeed with it — whether that is a student with an education kit or a factory operator with a controller.
Principles for cross-functional product development
We don't run a formal methodology for any of this. We work by a handful of principles that suit a small, multidisciplinary product team:
- Start from the problem, togetherBefore anyone opens a design tool, an IDE or a schematic editor, the people involved should agree on what problem is being solved and for whom.
- One source of truth per discipline, visible to allDesign files, code repositories and hardware documentation should be open to everyone on the product, not guarded by one team.
- Make constraints explicit earlyCost per unit, power budget, screen size, network conditions — say them out loud at the start, when they are cheap to design around.
- Review across the seamsAsk someone from another discipline to review your work. They will catch the assumptions you can no longer see.
- Test the whole product, not the partsA screen can pass review and a board can pass bring-up while the product as a whole still fails. Integration is where the truth is.
For teams looking for practical ways to put principles like these into practice, the Atlassian Team Playbook has useful, free exercises for kick-offs, roles and responsibilities, and retrospectives.
Why being small helps
Large companies can absolutely do cross-functional product development well, but they have to work at it — organising squads, aligning roadmaps, and fighting the gravity of departments.
A 15-person team has a different starting point. Our product designer, full-stack and AI backend developers, embedded architects, brand designers and editors all work under one roof in Kovilpatti. For us, collaboration across disciplines isn't a transformation programme; it is simply how the building works. You can see how the roles fit together in inside Team Incrix, and why we chose to span these disciplines at all in why Incrix builds across software, hardware and design.
Building together, on purpose
Great products are rarely the work of one discipline. They are the result of designers, developers and engineers seeing the same problem, sharing the same constraints and caring about the same outcome — and treating every hand-off as the start of a conversation rather than the end of their responsibility.
That is the way we try to build, from Classory to our ESP32 boards to the brands we design. If you want to see where it all leads, read what are we actually building at Incrix — or, if you like working across the seams, look at careers at Incrix.