Why clarity is a
product decision

The screen was not
the first crime scene

Most people blame the interface first.

So the normal reaction is to redesign.

Sometimes that helps.

But sometimes the interface is only confessing what the system already did wrong.

A confusing screen is often just the visible body of a deeper problem.

That is not design freedom. That is system failure.

The first real pattern became visible when I looked back at the products I had built. They were not connected by category. They were connected by friction.

The pattern I kept finding

At first, each product looked different.

But under the surface, all of them were fighting the same problem. People were not struggling because the subjects were impossible. They were struggling because the systems around those subjects forced them to remember too much.

Different questions. Same enemy.

Unmanaged cognitive load.

Good products do not make complex things fake-simple. They make complex things navigable.

Expense Hive: when money
becomes memory

Expense Hive was not built because expense apps did not exist. It was built because the problem appeared in real life.

During bachelor's, my friends and I kept running into the same small financial confusion. Someone paid for food. Someone paid for travel. Someone bought something for the group. Someone forgot to add a bill. Someone said they would pay later. Someone remembered the expense, but not the exact split. Someone had personal spending mixed with shared spending.

Nothing looked serious at first. But slowly, small amounts became small confusion. And small confusion became repeated conversations.

That was the gap. So I built Expense Hive — a mobile app made to instantly log expenses, split expenses between groups, add bills, use group chat, track personal expenses, manage group splits, add payment reminders, and see how much was spent during a week or month.

The important part was not only the feature list. The important part was timing. Expense tracking fails when logging happens too late. By the time a person opens the app later, the context is already weak. The amount may be remembered, but the reason is blurry. The group may be remembered, but the split is unclear. The bill may exist, but the responsibility is floating.

Expense Hive had to reduce that gap. It needed to answer:

• Is this personal or shared?
• Who paid?
• Who owes whom?
• Has the bill been added?
• Is there a reminder?
• What did I spend this week?
• What did the group spend this month?
• Did someone forget to settle?
• Is the conversation connected to the expense?

That last question mattered more than it looked. Money between friends is not only math. It is memory, trust, timing, and communication. A split without conversation becomes another loose thread.

So Expense Hive needed to connect:

expense → bill → group → people → reminder → settlement → conversation

That connection is clarity. Not just a clean UI.

A normal app records the amount. Expense Hive tried to preserve the context around the amount. That is where I started understanding something deeper:

The user does not only need storage. The user needs the system to remember the situation.

Because my friends and I actually used our own app, the feedback was immediate.

Real use exposed fake clarity very quickly.

Expense Hive taught me that clarity is not created by showing fewer things. It is created by connecting the right things.

Food Tracker: when logging
becomes invisible

The food tracker was personal. I built it because I wanted to track food, gym, and daily activity without turning my life into spreadsheet work.

Most tracking apps demand too much.

That sounds fine for one day. But after a week, the tracker becomes the task. That is backwards. The goal was not to become better at logging. The goal was to become better at living with the data.

So I built a more automated food tracker. Instead of manually entering everything through forms, I could simply say:

"I ate 2 eggs."

The system would break it down into nutritional values and log it automatically. That small interaction changed the product.

The food tracker connected: food logging, nutrition breakdown, gym tracking, daily activity, personal patterns, repeated meals, and progress over time.

The real product question was not:

"How do I make the food logging screen beautiful?"

The real question was:

"How do I make logging almost disappear?"

That is where clarity moved from design into engineering. The system had to understand simple human input and convert it into useful structured data. It needed: natural language input, food parsing, nutrition calculation, automatic logging, daily summaries, gym/activity connection, repeated food handling, low-friction corrections, and simple review.

A generic tracker asks the user to become precise. A clear tracker carries some of that precision for the user. The clearest interface is sometimes the one the user barely has to touch.

If the user has to fight the system to build a habit, the system becomes the habit.

A health product should not add stress to a health goal. It should reduce the distance between intention and action.

Pose Estimation: when movement
becomes data

Pose Estimation was my thesis. The idea was not limited to one sport. Cycling was one example, but the deeper concept was broader:

Can a machine learning system analyze an athlete's body movement and give coaches useful real-time movement data?

In sports, performance is movement. A runner's knee angle. A cyclist's ankle motion. A football player's body balance. Small movements can create big outcomes. Some movements improve performance. Some waste energy. Some increase injury risk. Some problems are too subtle, too fast, or too repetitive to catch consistently with the eye.

The system translated:

video → body points → motion attributes → coaching insight

That chain is fragile. A human sees an athlete moving. A machine sees frames, pixels, coordinates, keypoints, confidence scores, missing detections, noise, angles, and temporal changes. Somewhere inside that chain, raw motion must become meaning.

That is not a design problem first. It is a system problem.

A coach does not need raw coordinates. A coach needs answers:

• Is the movement stable?
• Is the posture risky?
• Is the ankle movement consistent?
• Is the leg motion efficient?
• Is the athlete repeating a harmful pattern?
• Is the output reliable enough to act on?
• What should be watched over time?

The product needed to avoid a common trap:

Technical output can look impressive and still be useless.

A skeleton overlay may look futuristic. A chart may look clean. A dashboard may look scientific. But if the coach cannot understand what to do with it, the system has failed.

Pose Estimation taught me that clarity in technical products means showing not only the result, but also the meaning and limits of that result. The system must communicate: what it detected, what changed, what matters, what might be uncertain, and what the coach should review.

Data is not clarity. Meaning is clarity. And in sports technology, meaning can protect the body.

Skift: when scheduling becomes
operational intelligence

Skift came later, but the pattern was already familiar. Once again, the visible problem looked simple. Scheduling. A restaurant needs people in the right place at the right time. That sounds like a calendar problem.

But after working inside real restaurant operations, the calendar started looking innocent. The deeper problem was not placing names into boxes. The deeper problem was that the schedule was being asked to carry information it did not understand.

A shift is not just time. A shift contains:

But most scheduling systems flatten all of that into a clean grid.

Clean, yes. Clear, not always.

Clarity does not mean the screen has fewer elements. Clarity means the system understands what the user is trying to decide.

For Skift, the manager is not only asking: "Can I place this employee from 16:00 to 22:00?" The real question is:

"Will this branch survive Friday evening without stress, overstaffing, missed updates, or mistakes?"

That changed the product. The calendar could not simply display shifts. It had to understand them.

So Skift needed a deeper clarity layer: expected sales pressure, role coverage, employee availability, contract-hour awareness, shift conflicts, replacement options, weather-aware hints, task readiness, communication status, branch alerts, AI scheduling suggestions, and explanations behind recommendations.

The manager should not have to remember everything alone. Who is good at closing. Who is new. Who already worked too many hours. Who missed the update. When sales usually rise. Which shift is risky. Who can replace someone quickly.

If the manager carries all of this alone, the manager becomes the integration layer. That is bad product design. And bad engineering.

Skift's purpose is to reduce that invisible burden. Not by replacing the manager. But by preparing the decision.

A clean calendar is design. A calendar that explains risk is engineering.

Calendar tracking: when time
becomes a system

Calendar tracking looks ordinary.

But time is not just a list. Time is pressure. A calendar is not valuable because it stores events. It is valuable when it helps the user understand what their day is becoming.

A normal calendar says:

"You have something at 17:00."

A clearer system asks:

"Does this fit your day, your energy, your priorities, and your previous commitments?"

The problem is not remembering an event. The problem is connecting the event to the rest of life.

A calendar system can become unclear when:

• Tasks are separate from events
• Reminders are too late
• Priorities are not visible
• Repeated routines are not understood
• Work, gym, study, food, and personal plans live separately
• The user has to mentally calculate what matters

The system should help reduce this load. It should understand: what is fixed, what is flexible, what repeats, what is urgent, what is optional, what requires preparation, and what affects the rest of the day.

Time management is not about filling boxes. It is about reducing future confusion.

Endrare: when identity
needs structure

Endrare itself became a clarity problem.

A normal portfolio is easy to build.

But normal was the problem. A portfolio that shows everything often explains nothing. The visitor arrives and sees: too many projects, too many skills, generic copy, random animations, no clear positioning, no reason to remember the person.

So the real question became:

What should Endrare make clear within seconds?

Not everything I have done. Only the direction.

Endrare needed to communicate:

• I build software
• I think in systems
• I care about design
• I understand operations
• I can connect business and engineering
• I can build products from real problems
• I am not just listing projects
• I am building a body of work

That is why the archive matters. That is why "05-thinking" matters. The case studies are not decorations. They are evidence.

Endrare is not only a website. It is a clarity system for identity. It decides what to show, what to hide, what to sequence, and what feeling the reader should carry after leaving. That is product design. And again, it is engineering too. Because structure creates perception.

What these products
taught me

Looking back, the products were different, but the lesson kept repeating.

Different products. Same lesson.

Clarity is not decoration. Clarity is system design. And system design lives in decisions most users never see.

How products
become unclear

After building these systems, I started noticing common ways products lose clarity.

Too many decisions are pushed to the user

The system refuses to prioritize. So the user must decide everything: what matters, where to click, what to ignore, what changed, what is urgent, what is safe, what happens next. This creates stress. A product should not ask the user to manage the product.

The system shows data without meaning

Data is not clarity. A dashboard full of numbers can still be useless. The user needs interpretation: Is this good? Is this bad? Compared to what? Should I act? Is this normal? Is this urgent? Without meaning, data becomes decoration.

Workflows are designed from screens, not situations

A screen-first product asks: "What should this page contain?" A situation-first product asks: "What is happening in the user's life when they open this?" That changes everything.

Context decides design.

Labels are vague

Words carry product logic. "Dashboard" is not enough. "Overview" is not enough. "Manage" is not enough. "Details" is not enough. Clear products name things according to user intent. Not developer convenience.

Every feature wants equal attention

Products become unclear when everything screams. Urgent messages. Normal updates. Old tasks. New tasks. Analytics. Settings. Suggestions. Notifications. If everything is important, nothing is. Engineering must support priority. The UI cannot fix bad priority logic.

The product does not remember enough

Users hate repeating context. If the system already knows something, it should not ask again without reason. This applies to: previous group expenses, repeated foods, athlete history, employee availability, previous schedules, recurring events, user goals, and common actions. Memory creates clarity when used carefully.

The product remembers too much

The opposite is also dangerous. A system that remembers everything can become noisy. Not all history is useful. Good memory needs selection. A clear product remembers what reduces friction and hides what creates noise.

The system hides consequences

Users need to know what will happen after an action.

Clarity means consequences are visible before action.

The engineering
behind clarity

Clarity requires technical decisions. Not only visual polish.

Information architecture

The system must decide where things belong. If messages, tasks, updates, schedules, bills, logs, and reminders are all mixed together, the user suffers. Good information architecture makes the product feel obvious.

Data modeling

The product must understand relationships.

In Expense Hive: user belongs to group, expense belongs to user or group, bill belongs to group, reminder belongs to payment, chat belongs to group, settlement belongs to split. In Skift: employee belongs to branch, shift belongs to schedule, task can belong to shift, message can belong to group or shift, warning can belong to schedule conflict, sales data can belong to branch and hour. In Pose Estimation: frame belongs to video, keypoint belongs to body, movement belongs to sequence, insight belongs to coaching context.

If the relationships are weak, the UI becomes messy.

State management

The system must know what state something is in.

Without clear states, users feel unsafe.

Permissions

Clarity depends on role. A manager, shift leader, and employee should not see the same product. A coach and athlete may need different views. A group member and expense creator may need different controls. Permissions are not only security. They are UX.

Defaults

Defaults are product opinions. A good default removes work. A bad default creates repeated correction. In Food Tracker, repeated meals should be easy. In Skift, common shift patterns should not need rebuilding. In Expense Hive, recent groups and common splits should be accessible. Defaults decide whether the product feels intelligent or stubborn.

Validation

The system should prevent errors early. Not after damage. Examples: impossible split amounts, missing group members, duplicate expense entries, schedule conflicts, contract-hour warnings, invalid food quantities, uncertain movement detection, missing athlete data. Validation is not just error handling. It is clarity before failure.

Notifications

Notification logic is engineering. The design can make a notification pretty. But engineering decides whether it should exist. Not every update deserves interruption. A payment reminder may need a notification. A shift change today definitely needs one. A weekly food summary can wait. A pose anomaly may need coach review. A normal archive update does not need noise.

Search and filtering

A system becomes stressful when users cannot find what they need. Filters must match real mental models. Not database columns.

Good filters speak the user's language.

Performance

Slow products feel unclear. When the interface delays, the user doubts themselves. Did I click? Did it save? Did it fail? Should I refresh? Was the log added? Was the shift published? Was the expense split? Performance is emotional clarity.

The design
behind clarity

Design still matters deeply. But design becomes strongest when it is supported by system thinking.

Good design creates: hierarchy, rhythm, space, contrast, grouping, focus, readability, calmness, trust.

A product can be technically powerful and still feel terrible if the design is noisy.

For my products and Endrare, my design direction became:

• White or warm off-white backgrounds
• Black text
• Calm spacing
• Subtle motion
• Clear section hierarchy
• Minimal decoration
• No unnecessary gradients
• No fake futuristic UI
• Readable typography
• Interface confidence without shouting

Because clarity has a visual temperature.

The goal is calm precision. A clear product should make the user feel:

That feeling is designed on the screen. But it is engineered underneath.

The suspense of
a clear product

The strange thing about clarity is that users rarely notice it directly. They notice the absence of pain.

They do not say: "Excellent cognitive load reduction."

But behind that ease is a chain of decisions.

Clarity is not the absence of complexity. It is the presence of decisions.

The wrong way and
the clearer way

Expense Hive

The second product understands the situation.

Food Tracker

The second product removes friction.

Pose Estimation

The second product turns data into action.

Skift

The second product explains risk.

Endrare

The second product creates memory.

Principles
I use now

Start from the user's situation, not the screen

Ask: what is happening when the user opens this? A user does not open a product in a vacuum. They open it during pressure, confusion, curiosity, planning, stress, or decision-making.

Make the system choose priority

Do not show everything equally. Equal visual weight creates unequal mental pressure.

Connect related information

If a message belongs to a shift, attach it to the shift. If a reminder belongs to a bill, attach it to the bill. If a movement attribute belongs to a body part, attach it to the athlete's performance context. If a food log belongs to a gym day, connect them.

Design for the next action

Every screen should quietly answer: "What should I do next?"

Explain warnings

Do not just alert. Explain why. A warning without reason creates anxiety. A warning with reason creates trust.

Use memory carefully

Remember what reduces friction. Forget or hide what creates noise.

Make states visible

Users should know whether something is draft, saved, changed, pending, approved, risky, completed, unsettled, or uncertain. Invisible state creates fear.

Keep language human

The product should speak like it understands the work. Not like a database table.

Make performance part of design

Fast response creates trust. Slow response creates doubt.

Remove before adding

Every new feature increases cognitive load unless it removes more than it adds. This is one of the hardest product rules. Because adding looks like progress. But removing often creates clarity.

What I now believe

I now believe clarity is one of the most valuable product qualities. Not because minimalism is trendy. But because people already carry too much.

A product either adds to that weight or removes some of it. That is the real test.

A clear product should do at least one of these:

• Reduce decisions
• Reduce memory load
• Reduce repeated work
• Reduce uncertainty
• Reduce searching
• Reduce fear of mistakes
• Reduce interpretation effort
• Reduce unnecessary choices
• Reduce manual calculation
• Reduce disconnected communication

If it does none of these, it may still look good. But it is not clear.

The final lesson

For a long time, I thought clarity meant making things simple. Now I think differently.

Clarity is not simplicity. Clarity is responsibility.

It means the product takes responsibility for structure, priority, memory, timing, consequence, and interpretation.

It means the system does not throw complexity at the user and call it flexibility.

It means design and engineering stop blaming each other.

Because the user does not care whether confusion came from the UI, backend, database, permissions, model output, or workflow. The user only feels the confusion. So the product must solve it as one system.