truvi

I’m a product designer at truvi, a startup in Barcelona. Among other things I work on the dashboard.

This page is deliberately about method rather than product. truvi is my current employer, so what we’re building belongs to the company — what is mine to write about is how the work gets done, and what doing it in a team has taught me that working alone never could.

What a dashboard actually is

A dashboard is not a screen. It’s an argument about what matters, made in layout.

Every element on one is a claim that this number deserves more of somebody’s attention than that number. Get the hierarchy wrong and the person using it does not fail loudly — they just quietly stop trusting it and go back to exporting a spreadsheet. That failure mode is invisible in analytics and obvious in conversation, which is one reason I now insist on the conversations.

The hardest part is never the visualisation. It’s deciding what to leave off, and every stakeholder has a different answer, all of them defensible.

Working with people who are not designers

Most of my week is not design work. It’s conversation with engineers, product managers and stakeholders, all of whom are right about different things and none of whom are looking at the same problem I am.

I used to treat that as friction to get through on the way to the real work. It’s closer to the actual work. An engineer telling me something is expensive is not an obstacle to the design, it’s information about the design that I did not have. The version I would have shipped without that conversation would have been worse and slower.

The specific change: I now ask about cost early, while options are still open, rather than presenting a direction and finding out afterwards what it would take to build. Cheap information gathered late is expensive.

Showing work earlier than is comfortable

The habit that has mattered most is showing things before they’re ready.

My instinct is to disappear, work it out, and come back with something coherent. It feels more professional. It’s also how you spend two weeks going in a direction that a five-minute conversation would have corrected on day one.

So now I show the ugly version — the one with placeholder labels and an obviously wrong chart. It gets better notes, because nobody is afraid to break something that clearly is not finished. A polished mockup asks for approval. A rough one asks for help, and help is what I need at that stage.

It’s still uncomfortable every time. That has not changed; only my willingness to do it anyway has.

Feedback is not a performance review

Early in my career I took notes on the work as notes on me. Everybody says not to. Knowing that and feeling it are different things.

What helped was a small reframe rather than a large one: the people giving me notes have lived with this product longer than I have. When somebody pushes back, they usually know something I do not. My job in that moment is to find out what it is, not to defend what I made.

The corollary took longer to learn, that this cuts both ways. Sometimes I do know something they do not, and quietly folding is not humility, it’s avoidance. Disagreeing well, in the room, with reasoning attached, is part of the job too.

Still learning

Everything above reads like the writing of somebody who has it figured out. I do not.

I still over-polish. I still get attached to solutions past the point where the evidence supports them. I still occasionally build the elaborate version when the simple one would have done, and I usually notice about a day later than I would like.

The difference between now and five years ago is not that I make fewer mistakes. It’s that I notice them sooner and say them out loud faster, which, as far as I can tell, is most of what getting better actually looks like.