Design Process

Design at Hardal isn't a separate function that hands things over to engineering. It's embedded in how we build. Engineers care about how things look. Designers write copy and think about data flows. The line between roles is intentionally blurry.

Who does design

Right now, design at Hardal is collaborative. Berkay DemirbaşBerkay DemirbaşCo-founder / CTO is primarily responsible for product design decisions, from the interface to the brand identity. But design is everyone's job: product engineers shape the UI they ship, and anyone on the team can (and should) raise concerns or suggestions when something doesn't feel right.

All our design files live in Figma: Figma Brand & UI

Good design decisions come from people who are close to the customer problem. That means everyone building the product has a stake in how it looks and feels.

How we approach a new feature

1. Understand the problem first. Before sketching anything, be clear about what you're solving and for whom. "Customers can't find the consent configuration" is a problem. "Add a settings tab" is a solution that may or may not solve it.

2. Start with the simplest version. Our design bias is toward the minimum that solves the problem well. More features, more UI elements, and more copy are usually not the answer. Cut until cutting would break the thing.

3. Design in context. Use the actual product, in the actual browser, on an actual screen size. Figma comps that don't account for edge cases, real data, or loading states mislead the whole team.

4. Get eyes on it early. Don't polish before getting feedback. A rough version with real questions is more useful than a polished version with no questions.

5. Ship and see. The last 10% of polish can wait. Ship when it works correctly, observe how people use it, then improve based on what you see.

Design principles in practice

Clarity over aesthetics

A clean UI that confuses users has failed. A slightly ugly UI that people can use without thinking is better. Aim for both - but when they conflict, clarity wins.

Real content, not lorem ipsum

Design with actual customer data, actual copy, and actual edge cases. A dashboard that looks beautiful with three clean data points will look broken with 47 entries and a customer name that's 40 characters long.

Dark mode is not optional

We support both light and dark modes. Any new UI must be tested in both.

Mobile is real

A significant portion of our customers' marketing teams check dashboards on mobile. The product doesn't need to be mobile-first, but it must be mobile-usable.

Giving feedback on design

Be specific. "This feels off" is hard to act on. "The spacing between the chart and the table makes it look like they're unrelated, but they're actually showing the same dataset" is useful.

When giving design feedback:

• Separate aesthetic preferences from functional issues. Both matter, but in different ways.
• Ask "what is this trying to do?" before suggesting a fix.
• If you're the engineer building it, you have authority to push back on designs that are technically difficult for unclear reasons. The goal is always the best outcome, not fidelity to the original comp.

Brand assets

For logos, colors, and type specs, see Logo & Branding and UI Design System.

For voice and copy decisions, see Brand Voice.

For the full Figma library (brand assets, components, icons), use Figma Brand & UI. Request access from Berkay DemirbaşBerkay DemirbaşCo-founder / CTO if you don't have it yet.

External design requests

If a partner, sponsor, or press outlet asks for brand assets, refer them to our brand guidelines. Send them the approved assets - don't create new variations on the fly.

If someone needs something that doesn't exist (a new banner size, a localized version), open a Linear issue and tag Berkay DemirbaşBerkay DemirbaşCo-founder / CTO. Don't improvise brand assets.