In Conversation with Gaana: Reflections on Empathy, Enterprise Design, and Electric Blues

"In design, there are better answers and worse ones. Some decisions create access; others create barriers. Visual systems follow principles of hierarchy, contrast, accessibility, clarity, not to restrict creativity, but to invite people in.

Design is not self-expression. It exists to meet a need. To help someone accomplish something with greater ease than before. That's how I think about my role." -  Gaana Srinivas, Founding Designer at Seezo

From reimbursements to cybersecurity vulnerability assessments, Gaana has spent years building tools for professionals who need software to work reliably and clearly. This conversation explores what it means to design for trust in spaces where trust is critical. 

We talked about constraints as creative fuel, design thinking, and why enterprise software doesn't have to look boring. About comforting colors, aerogel metaphors, and the difference between being a compass and a GPS.

What follows is a conversation about craft, philosophy, and the designing systems people actually want to use.

There’s a belief that B2B app designs are functional but boring. Do you agree?

I understand where that belief comes from. Many enterprise tools are designed purely for function. But I don’t think they have to be boring.

When I worked at Pleo, one of the things that drew me in was how much they cared about visual design. I loved hearing accountants tell us about how they weren't used to people making nice things for them, which I thought was crazy because I think everyone deserves good design.

Cybersecurity feels similar. We’re used to dashboards that are glaring red, deep green, dark, intimidating. But that’s not the only way to communicate seriousness. I'm excited to think about reshaping how the category feels, to create tools that are calm, clear, and respectful of the user’s expertise.

What’s your definition of good design? And what does design thinking actually mean?

To me, design thinking is the process you follow to reliably solve problems. Let's figure out what it is that we're trying to solve for our users and why. Then, create a problem statement, or a How Might We. For Seezo, that could be “How might we enable cybersecurity professionals to assess all of their product requirement documents in a way that eliminates as many vulnerabilities as possible quickly?”

Getting one version of that out, showing it to our customers, and then iterating on it - to me that's the design process in a nutshell.

Does good design differ between B2C and B2B?

Well-designed software helps users accomplish what they're trying to do, that part doesn't change.

If you're talking about a direct consumer brand, they might focus on having very strong and attractive marketing. That might translate into colors, a lot of animation, a lot of engagement, notifications, ways to attract your attention. 

For a cybersecurity org, we're dealing with professionals who know exactly what they want to use a tool for. The way that we help them succeed is to make their processes as easy and as quick to perform as we can. 

The task at hand is just different. In my opinion, context is what makes a certain design good or bad.

You've worked in fintech and now cybersecurity. Are there more constraints in "serious" industries? Less freedom?

Constraints are some of the most important things in design. In fact, the scariest thing for me would be if someone said "build whatever you want." Like, give me some lines that I can color in!

In highly regulated areas like fintech or cybersecurity, yes, the challenge is greater because there's a couple more things you need to take in account versus the average say, social media app. 

But it doesn't mean you have to take all the fun out of everything.

While working in reimbursements, I pushed for getting Lottie animations on the app. We already had fantastic motion designers, and I asked them for a little celebratory animation whenever people got their money back. There was a charming spinning coin and some fluttering bank notes. It was honestly delightful and made sense in context.

There is always space to bring delight, but we need to make sure that we're adding delight as a gorgeous afterthought, on top of making sure that we keep their jobs to be done at the core. If your feature doesn't work as expected, or if the fun gets in the way, that's no good.

There's this tension between "reliable" design and "cutting-edge" design. Beautiful sites sometimes feel less reliable. What do you think about that?

The funny thing about visual design is that we associate flashiness with dishonesty, or we can sometimes think that something that looks exciting is trying to cover something up that doesn't work so well.

What makes something reliable or trustworthy is consistency. If the user's expectations of behavior are matched, if when they perform an action that action is very easily visible to them, and when the system performs an action that also must be visible, that drives trustworthiness.

I still go back to the Nielsen Norman Group's 10 Heuristics for Usable Interface Design. One of them is minimalism and aesthetic design. When you have many items on a page, they all really need to earn their right to be there. 

Having come to my professional life in the Danish design tradition, there's a lot to learn from it. I wouldn't call anything I do 'cutting edge' - it hasn't got crazy animations and lots of effects and scrolljacking. But I try to make things pretty and easy to consume, which to me walks the line of cutting-edge and hopefully even beautiful!

Also, 'reliable'-looking software can still be terrible. You have to use it to find out.

You are an advocate of product thinking. What does it mean to you?

Product thinking means recognizing that good design isn’t the only constraint. We have to account for engineering realities and business goals. 

If something looks great but can’t ship on time or doesn’t support the company’s strategy, it doesn’t matter. It has to work well for the user and for the business.

Product thinking is something that can be practiced by anybody. In our company, all of us are empowered to be product thinkers because we've recognized that we're building parts of a larger whole. 

Keeping that context in our minds, understanding what our customers really want, understanding that we only have so much engineering capacity, and making decisions based on that is what product thinking really encapsulates.

Have you faced resistance from engineering teams when your design perspective differs from theirs?

Engineers often think from the standpoint of a builder, often opposite to mine which is that of a user. We're coming at the problem from different ends, so it's usually not a true difference in design perspective.

I value collaboration and discussion with engineers because I rely on them bringing up stuff I didn't think about. It's the same with product leadership, and in our case, on a CEO who brings deep cybersecurity expertise. Most importantly, we have a direct line to customers through our customer success co-founder.

I’ve often seen companies fall into tunnel vision, where their own perspective defines everything. At Seezo, we balance deep cybersecurity expertise with real customer insight and let both genuinely inform our decisions.

Can you share an example where customer feedback fundamentally changed your design approach?

Every time! The first version of a design is a hypothesis.  Users say "hey, this is what we think people want," and they're gonna tell us "no, this doesn't work, and this is why" over and over again, until we get it right. That's a constant growing and learning process.

Right now, a version I'm working on is: understanding what kind of information users want to see upfront to triage a requirement, versus later. Progressive disclosure isn't a new idea at all, but I got this specific solution by listening to users and our internal team.

How do you prioritize visual hierarchy when everything seems important?

Everything may seem important, but it just physically cannot be true. In cases like this, I take people through a card sort exercise - one of the many tools in the toolkit of a designer.

Basically I say “Here’s everything we could show you, now rank it. In order of importance. No, you can't put things next to each other"

Everyone ranks it differently. But when you aggregate the results, patterns emerge. That’s how you discover what truly matters.

All of our customers are really different in how they use Seezo. Some decisions are made in seconds; others require deeper context. Both of these can be supported by our system. Supporting the majority of their workflows means that we're winning, and it means that they want to use us more.

Seezo’s main principle is "be a compass, not GPS". How does this inform your design decisions?

Every cybersecurity function works differently. Different hierarchies, tools, processes—even different definitions of what "risk" means or what "triaged" looks like.

If we're prescriptive, if we scream "high risk" at every turn, we're claiming a confidence that supersedes the user's own expertise. That's not our place.

The people at these companies are in charge of how security is done. We're just there to help. So why not have a language that also doesn't shout?

We're a compass, not a GPS. We provide gentle guidance to professionals who do this work every day and who have the final say.

That philosophy shows up in our visual language. Even our directional arrows and compass points echo that philosophy. They reinforce orientation not control.

When I think about our design system, there's black or hyperlink blue and then there's fuzzy, muted indigo. Still dark, but less extreme. Maybe even reassuring.

Tell me about your visual system for Seezo.

I sometimes describe the system as “aerogel.” Light, almost transparent in feel but structurally strong. Resilient under fire. I like to draw on these metaphors in order to give myself creative ways to match back visually to the Seezo brand when I need to make decisions.

I've picked low-saturation indigos, lavenders, and pleasant cornflower blues that communicate comfort, stability, and solidness without feeling too harsh. They are colors I'm very partial to but I think really work for our context.

But with Seezo, the real product is language. The reason people buy us comes from what we write, especially how we explain vulnerabilities. That’s why typography is so important to me. I try to focus on strong hierarchy, lots of whitespace, and good readability. It's an ongoing process. There's definitely a science to it, but it's also philosophical.

If you had to capture your design vision for Seezo in one line?

What I want to communicate through Seezo's UI is consistency, clarity, and trust.

Our communications or design manifesto is not something I carry by myself. It's something that all of us at Seezo embody through our work.

Finally, how has AI changed how you design? 

It's up-ended my whole process. Specs don't mean what they used, and our engineers spin up the UI so quickly that sharing static  Figma screens with them feels silly. The tools, the expectations, everything about my job has changed very quickly.

Most importantly it's changed when I do my thinking. That's been the hardest adjustment.

But we're all adapting and I love using Claude to rapidly prototype iterations that my users and teammates can click through and validate very quickly. There are still parts of the process I haven't figured out but I'm optimistic that me and the larger design community will figure it out quickly, as we already are. I really feel design as a discipline, as a software function, and as a job isn't going away, it just looks different. And we're all figuring it out together.