Visualizing Financial Purity: Designing Color for Shariah States

When designing a financial screening tool like Shariah Signal, the immediate temptation is to use a traffic light system: green for compliant, red for non-compliant. While this works for simple binary states, it fails the user when the underlying data is fluid. Shariah compliance in the equity markets is rarely a static 'yes' or 'no.' It is a snapshot of a company’s financial health based on quarterly filings, fluctuating debt ratios, and evolving revenue streams. Relying on a binary color palette risks misleading a user into a false sense of permanent security or immediate rejection.

We had to rethink how color communicates risk, compliance, and data age. In our studio's experience building tools like Salah Companion, we learned that users rely on visual cues for quick decisions, but those cues must be backed by technical precision. For Shariah Signal, we moved away from pure red/green tropes toward a semantic color system that accounts for the nuances of financial ratios and the reality of stale data.

The Problem with Binary Color Logic

Traditional UI design uses green (#4CAF50) to signal success and red (#F44336) to signal error. In a stock screener, if a company's debt-to-market-cap ratio is 32.9% (below the common 33% threshold), a green light suggests 'purity.' If it ticks to 33.1%, the light turns red, suggesting 'prohibited.'

This creates two distinct engineering and design challenges:

1. 1.The 'Cliff' Effect: Users might buy a stock that is dangerously close to the threshold without realizing it is one market dip away from non-compliance.
2. 2.Data Recency: A 'green' status based on a report from nine months ago is fundamentally different from one based on a report filed yesterday.

To solve this, we developed a palette based on Chromatic Nuance. We needed a system that could communicate 'Compliant,' 'Non-Compliant,' 'Doubtful/Borderline,' and 'Stale/Outdated' without creating visual clutter.

Designing the Four-State System

We categorized the compliance status into four primary UI states, each with a specific color logic and associated metadata.

1. Confirmed Compliant (The Deep Emerald)

We avoid 'Neon Green' because it implies a temporary or 'go' state like a start button. Instead, we use a Deep Emerald. This color has higher blue values, making it feel stable and institutional. It signals that the company passes all five standard filters (Business Activity, Interest-Bearing Debt, Interest-Bearing Securities, Excess Liquid Assets, and Impure Income).

2. The Warning State (Amber vs. Orange)

In Shariah screening, a 'warning' isn't just an error; it's a proximity alert. We use a specific Amber (#FFB300) when a stock is within 5% of a threshold (e.g., a debt ratio of 31.5% against a 33% limit). This tells the user: "This is compliant today, but keep a close eye on the next quarterly filing."

3. Non-Compliant (The Muted Crimson)

Aggressive red creates panic. Financial decisions should not be made in a state of panic. We use a Muted Crimson. It is distinct from the background but lacks the 'error' vibration of pure red. This state is triggered when a primary business activity is haram or a financial ratio is breached significantly.

4. The Stale State (Neutral Grayscale)

This is the most overlooked state in financial UI. If our backend hasn't parsed a new 10-K or 10-Q filing within a specific timeframe, the UI should not claim a stock is compliant. It shifts to a neutral, desaturated Slate. This communicates 'Unknown' or 'Awaiting Data.'

Implementation in Jetpack Compose

From a technical perspective, we handle these states using a sealed class in our ViewModel. This ensures that the UI cannot represent a state that doesn't exist. We learned the importance of this architecture while managing complex dynamic forms.

``kotlin sealed class ComplianceStatus { object Compliant : ComplianceStatus() data class Caution(val breachProximity: Float) : ComplianceStatus() object NonCompliant : ComplianceStatus() object Stale : ComplianceStatus() } ``

By passing this state to a custom ComplianceBadge component, we can swap the color and icon dynamically. We also use a 'Surface Overlay' technique where the background of the card subtly tints to match the compliance state, providing a secondary visual cue for the user without requiring them to read the specific label.

Solving for Color Blindness and Accessibility

Color alone is never enough. Roughly 8% of men and 0.5% of women have some form of color vision deficiency (CVD). If we rely solely on the difference between Emerald and Crimson, a user with Protanopia might see them as nearly identical shades of brownish-gray.

To fix this in Shariah Signal, we apply three layers of identification:

1. 1.Iconography: Compliant stocks get a checkmark; Caution stocks get a thin exclamation triangle; Non-compliant stocks get a strike-through circle.
2. 2.Text Labels: We never use a color bubble without the word "Compliant" or "Non-Compliant" inside or immediately adjacent to it.
3. 3.Luminance Contrast: We ensure that the 'Non-Compliant' Crimson and the 'Compliant' Emerald have different luminance values. Even in black and white, the 'Non-Compliant' state appears darker than the 'Compliant' state.

You can read more about our general approach to Android Accessibility Basics to see how these principles apply across all our apps.

The "Doubtful" Zone: Handling Ratios

One of the hardest parts of designing Shariah Signal was the visualization of the ratios themselves. A stock might pass the debt filter but fail the liquid assets filter.

We use a Componentized Breakdown approach. Instead of one giant 'Non-Compliant' banner, we show a list of the five standard filters. Each filter is its own mini-UI element with its own state. This allows a user to see why a stock failed.

Example Case: Company X

• Business Activity: Pass (Green)
• Debt Ratio: 34.2% (Red - Threshold is 33%)
• Cash Ratio: 12% (Green - Threshold is 33%)

In this scenario, the overall header is Red, but the individual line items show that the company’s core business is fine—it's just the debt levels that are problematic. This granularity empowers the user to make an informed decision rather than just following a 'Signal' blindly. It also helps them identify stocks that might become compliant again if they pay down debt in the next quarter.

Technical Trade-offs in State Rendering

When we build for Android, we have to consider the performance impact of frequent UI updates, especially in a list of 50+ stocks. We avoid calculating compliance states on the UI thread. The calculation engine lives in a background worker that evaluates the JSON response from our financial data provider against the user's selected Shariah standard (e.g., AAOIFI vs. S&P).

We then cache these states. If a user scrolls through a list, the UI simply pulls the pre-calculated color and icon from the database. This prevents the 'jank' that occurs when an app tries to run math and render complex gradients simultaneously.

What to do next

1. 1.Audit your current UI for binary traps. Look at any part of your app that uses a simple Red/Green toggle. Ask if there is a 'Warning' or 'Stale' state that is currently being hidden from the user.
2. 2.Test for Color Blindness. Use the 'Simulate color space' developer option on your Android device to view your app in Protanomaly or Deuteranomaly modes. If you can't tell the difference between your success and error states, add icons immediately.
3. 3.Define your thresholds. If you are building a tool that tracks limits (financial, time-based, or health-related), define a 'Caution' zone—typically 5-10% from the limit—and assign it a distinct semantic color.