By: Marta Camacho
Operations & Product Lead @deitta
https://www.linkedin.com/in/martacamachosayago/
Empathy is probably one of the most frequently used concepts in product design, yet it is also one of the easiest to oversimplify. We often associate empathy with usability: reducing friction, simplifying journeys or making interfaces more intuitive. Those objectives are important, but I have come to believe that they describe only part of the problem.
A product can be remarkably simple to use while still leaving people uncertain about what they are agreeing to, why certain information is being requested or what they receive in return. If users complete a journey without understanding it, I am not convinced we have built a truly empathetic experience.
Perhaps the reason I think about this so often is that, before working in product, I am a user myself. Like everyone else, I install applications without knowing exactly how they work, decide whether I want to create an account and weigh up whether a product deserves a place in my daily life. I value products that communicate clearly, and I quickly lose confidence when I feel I am being guided towards a decision without enough context to understand it.
The only difference is that I also have the privilege of seeing what happens behind the interface. I know that every screen, every piece of copy and every interaction is usually the outcome of conversations between design, engineering, legal, operations and business teams. What appears to users as a simple button is often the visible result of dozens of decisions that they will never see.
That perspective has fundamentally changed how I understand empathy in product.
Every product asks something from its users. It may ask for their attention, their time, their money or, increasingly, their data. In return, it promises value. Product teams often focus on optimising that exchange so that it happens as efficiently as possible. I believe our responsibility goes a step further: ensuring that people understand the exchange they are entering into.
The question is not only whether someone can complete a journey. It is whether they understand why the journey exists, what value it creates for them and whether the trust the product asks of them feels justified.
This distinction has shaped many of the product conversations I have been part of. More than once, what initially appeared to be a straightforward UX improvement became something much broader once we stepped back and considered its implications. Removing a screen, shortening a flow or simplifying a decision often made the interface cleaner, but it did not always make the experience better. Sometimes we realised that what we were removing was not friction but understanding.
Those moments rarely remain design discussions for long. They quickly become conversations about operations, customer support, legal responsibilities and the promises a product is making to its users. A feature cannot communicate transparency if the organisation cannot support that transparency operationally. Equally, no operational process can compensate for an interface that leaves people confused about what is happening.
That is why I have gradually stopped thinking of product as something owned exclusively by the product team. A product is the point where strategy, technology, operations, legal and communication meet. Users never experience those functions separately; they experience a single relationship with the organisation. Every inconsistency between what the interface communicates and what the organisation delivers weakens that relationship, even if the interface itself is beautifully designed.
Working on deitta has reinforced that belief every day.
Although people often describe deitta as a data platform, I have never thought of it primarily in those terms. To me, it is an attempt to redesign the relationship between organisations and the people whose data makes so much of today’s digital economy possible.
That ambition sounds simple, but it changes the questions we ask ourselves when designing the product.
We are constantly asking whether users understand why we request certain information, whether the value they receive is sufficiently clear and whether we are making assumptions simply because we know how the product works internally. It is surprisingly easy, inside any organisation, to forget how much context users do not have.
For that reason, one of the habits we have deliberately built into our product culture is continuous self-criticism. We regularly revisit features that are technically correct but communicatively weak. We rewrite messages that are accurate but difficult to understand. We redesign flows that perform well according to the metrics because we believe they could do a better job of explaining the value exchange taking place.
Those decisions are not driven by perfectionism. They come from recognising that one of the biggest challenges in product is reducing the distance between the company and the user.
Every organisation understands its own product better than anyone else. It knows why certain processes exist, why particular information is required and what happens behind the scenes. Users do not have that context, nor should they need it. Our responsibility is to translate complexity into understanding without hiding the reality of the exchange.
I increasingly believe that this is where product creates its greatest value. Not simply by building useful features, but by helping people understand why those features exist, what role they play and how they benefit from using them. In many cases, understanding is just as important as usability. When people understand the value being offered, trust becomes a consequence rather than an objective.
Looking back, I think that principle has shaped deitta more than any individual feature we have built. We are constantly trying to make the gap between business intentions and user understanding a little smaller. Every release, every redesign and every discussion is another opportunity to ask whether we are communicating our intentions as clearly as we possibly can.
That work is never finished. As products evolve, so do users’ expectations, concerns and questions. Building trust is therefore not a milestone that can be achieved once and forgotten. It is an ongoing commitment to ensuring that the experience people have always matches the experience we intended to create.
Ultimately, I do not believe the best products are those that ask the least from their users. I believe they are the ones that make the value exchange so clear that people can make informed decisions with confidence.
Because trust may begin in the interface.
But it is always proven in the relationship between the product, the organisation and the person using it.
