Product
JBRAA Risk Monitor — threat and disaster awareness mobile app
JBRAA RISK MONITOR · THREAT INTELLIGENCE & DISASTER AWARENESS · MOBILE REDESIGN
JBRAA Risk Monitor: A Clearer Alert Hierarchy
Redesigning JBRAA Risk Monitor around one decision hierarchy — and extending it into retrieval, access and content
- Design specification for an existing Android app
- One decision hierarchy applied across every surface
- Six-dimension filtering with a visible query
- Before and after both inspectable
The 30-Second Version
Severity · location · time · headline
JBRAA Risk Monitor delivers threat and disaster alerts — terrorism, protest, weather, health, traffic — to professional users making movement and safety decisions. The original, shipped Android app carried the right information in an order that left the ranking work to the reader.
I designed the iOS and Android redesign around one decision hierarchy, then applied it to filtering, licensed access and analyst content. This case study documents the design deliverable; deployment of the redesign has not been independently verified.
The redesign establishes a single ranking the product performs on the user’s behalf, instead of an interface where every alert had to be interpreted before it could be judged.
Context & Role
A client redesign of a live, shipped Android product, redrawn for iOS and Android. JBRAA is a professional risk-monitoring service: alerts are authored by analysts, and access is sold as licensed packages that determine which countries a user may view. That commercial model matters to the design — these are paying professional users who open the app to act, and retrieval speed is the value they are paying for.
Project Overview
Year
2025
Project type
Client redesign of a live, shipped Android product, redrawn for iOS and Android
Scope
Complete redesign of the screens and components for iOS and Android. The original Android app was live; the redesign is documented here as a design deliverable.
Role
Senior UI/UX Designer — design owner for the redesign
Users
Professional and organisational users monitoring risk across regions
Alert categories
Terrorism · Protest · Weather · Health and safety · Traffic
Region
Pakistan-focused, with a multi-country access model
Surfaces designed
Sign-in and splash · home and category feeds · alert detail · calendar with filtering · upcoming events · account and region entitlement
Commercial model
Licensed packages; country access enforced from the backend
Ownership
OwnershipDetail
What I owned
The redesign end to end: the decision-hierarchy model, information architecture, all screens and components, filtering, entitlement states, detail-view structure and the visual system
What the client owned
The alert content model and categories, the analyst authoring pipeline, the licensing and entitlement rules enforced from the backend, and release scope
What I recommended but did not decide
That analyst copy adopt named fields — event, impact, recommended action — so structure could be rendered as layout rather than typed prefixes; and that severity be defined as a graded scale rather than a single high value. Both sit inside the client’s content model.
The Problem
These users are not browsing. They open the app because something may have happened, and need to judge quickly whether it concerns them. A heuristic review of the shipped app found four patterns working against that.
No scanning order
Centre-aligned content mixed with left-aligned blocks gave the eye no consistent entry point, so every card had to be read rather than scanned.
Severity was the least visible element
Risk level sat as small text at the bottom edge of a card, in the position an interface usually reserves for metadata.
Colour carried two meanings
Category labels and severity values both used red; headings used green. Colour signalled taxonomy and urgency at once, and reliably communicated neither.
Structure was typed, not designed
EVENT, IMPACT and REASON appeared as inline text prefixes inside paragraph blocks, so long advisories became an undifferentiated wall.
And in the account area
In the account area, fields used placeholder text as their only label, so a field’s meaning disappeared once it was filled.
Discovery & Constraints
Three inputs informed the redesign: a screen-by-screen heuristic review of the shipped app; client input on alert categories, the analyst authoring pipeline and the licensing model; and a review of how public-warning products convey severity, including established colour-coded alerting conventions that separate hazard type from hazard severity.
Constraints
- A shipped product with existing users — content could be reorganised, not removed, and the app had to stay recognisable
- Alert copy is analyst-authored and varies from a two-line traffic note to a multi-paragraph advisory with impact lists, so any structure had to hold at both extremes
- Access is entitlement-based and enforced from the backend, so the interface has to express a permission state it does not control
- Severity has to survive a small screen, read quickly, in variable light, by someone who may be moving
From Evidence to Principle
The four findings pointed at one underlying cause. The app had no ranking of its own information — every element was presented as equally important, so the reader performed the ranking on every card, every time.
That produced the principle the rest of the redesign is built on:
Rank the information once, in the design, so the reader does not have to rank it again.
The decision hierarchy
- 1Severity
- 2Location
- 3Time
- 4Headline
- 5Body
Why severity leads
Ranking requires deciding what leads. The hierarchy I defined places severity first, then location, then time, then the headline and body — with category acting as a persistent label that identifies the alert type rather than a step in the reading sequence. This is the order used for the rest of this case study, and the order the design applies on every surface.
The design hypothesis behind putting severity first is that it is the fact most likely to qualify the others: location and timing both matter, but knowing an incident is nearby and recent tells you less about whether to act than knowing how serious it is. Placing severity in a fixed, immediately-resolved position is intended to let a reader triage a feed efficiently — spending attention on the alerts that warrant it rather than reading each one to find out.
Applying that ranking forced three further decisions. Severity had to become a component rather than a printed value, so its position could be guaranteed everywhere it appears. Red had to be released from category use, because a colour marking urgency cannot also mark taxonomy. And the card needed a fixed anatomy, so the same facts resolve in the same positions on every item in every feed.
Extending the Hierarchy: Retrieval
The same ranking problem existed at the level of the feed. The shipped app presented alerts chronologically, which ranks by recency — a proxy for relevance that weakens as soon as the feed spans several categories across multiple provinces. A reader whose exposure is one province receives a list ordered by something other than their exposure, and a question as ordinary as "what happened in Punjab this week" can only be answered by scrolling.
Filtering across six dimensions — country, province, city, category, month and date — lets the user supply the ranking the feed cannot infer. The six follow the way exposure is defined in the client’s own content model: geographically at three levels of precision, by hazard category, and over a time window.
Applied filters resolve into removable chips below the header, which keeps the current query visible and editable one dimension at a time. Where a user refines the same question repeatedly, the state of the query is itself information — an invisible filter is indistinguishable from an empty feed.
Extending the Hierarchy: Access
Licensing is the product’s commercial structure, and it reaches the interface as a constraint: a user’s package determines which countries they may view, enforced from the backend. The chain runs from the package sold, to the entitlement recorded, to the regions returned, to what the interface must then express.
The straightforward option is to show only entitled countries. That produces a clean screen and an ambiguous one, because it makes coverage that does not exist indistinguishable from coverage the user has not purchased. So the region selector lists the full set with unentitled countries visibly present but disabled, and the account screen shows the selected region alongside the member package. The interface is designed to make the limit legible and attribute it correctly — as a commercial boundary rather than a fault or a gap in the service.
Extending the Hierarchy: Content
Two decisions carried the ranking principle into the detail view. The detail header repeats the same facts the card resolved, so context survives the transition and the user is not re-establishing what they are looking at. And analyst copy is structured by layout rather than by typed prefixes: event and impact become headings, consequence lists become bulleted lists, and a collapsible summary sits above the full text — which lets one template hold a two-line note and a long advisory without either being misread.
A third decision came from the existing product rather than the interface. The shipped app carried a small unlabelled copy icon, and client input confirmed it exists because alerts are forwarded into messaging groups — meaning part of the product’s distribution happens outside it. Treating that as a named action rather than a stray icon acknowledges the workflow instead of designing as though the app were the destination.
Separating scheduled events from live alerts addresses a different ranking problem to severity, and is worth distinguishing. Severity ranks items against each other by urgency. Upcoming and live items are not comparable on that scale at all — an anticipated protest next Tuesday and an active incident now demand different reading, and ranking them in one list forces a comparison that does not hold. Severity establishes the reading order within each alert; separating upcoming from live events defines which items belong in the same feed.
Accessibility requirements
Accessibility requirements in the design specification. Production accessibility and WCAG conformance have not been verified.
- Pair severity colour with an icon and a text label, so urgency does not depend on colour alone
- Specify contrast requirements for severity and category over photography, assessed against the least legible image conditions
- Maintain readable minimum text sizes for the place and time metadata
- Size filter chips and their remove controls for one-handed use
- Support large system font sizes without clipping long advisories
Outcome
What changed in the design
Each row compares the original Android experience with the proposed redesign. The changes apply the same information hierarchy at different levels of the experience; they are design decisions, not measured outcomes.
Original appRedesign specification
Every element presented as equally important
One decision hierarchy, applied across all surfaces
Severity printed as metadata
Severity positioned as a fixed component
Red used for category and severity alike
Red reserved for severity alone
Chronological feed ranked by recency
Six-dimension filtering with a visible query
Entitlement enforced silently
Entitlement expressed and attributed
Structure carried by typed prefixes
Structure carried by layout
What was designed
A complete redesign of the product’s screens — sign-in and splash, home and category feeds, detail view, calendar with filtering and applied-filter states, upcoming events, account and region entitlement — together with the severity, card, filter-chip and metadata components that make the hierarchy reusable rather than drawn per screen. The design is complete; production deployment of the redesign has not been independently verified.
What remains unvalidated
The redesign rests on assumptions throughout — including the retrieval and entitlement rationales above. These are the three primary hypotheses, none of them tested:
- That a fixed reading order is intended to reduce the time needed to judge an alert’s relevance
- That a positioned severity badge is noticed more reliably than a printed severity value
- That a visible query state is intended to reduce filter abandonment on a long feed
What would be measured next
These are proposed validation methods. They are not evidence that the redesign works — they are how I would find out.
PriorityMethodHypothesis it tests
Comprehension
Timed card-reading task — show an alert for three seconds, then ask severity, location and category
Can the decision facts be extracted at a glance? This is the central claim.
Severity salience
Matched recall task comparing the old and new card layouts
Does positioning outperform printing?
Retrieval
Share of sessions applying a filter, dimensions used, and abandonment before results
Does the query model work on a small screen?
Reflection
The lesson I took from this project is about sequencing, and it came from getting it wrong.
I designed the severity badge before defining the severity scale it belongs to. The component is sound — fixed position, colour paired with icon and label — but it was derived from a single value rather than from a model of how severity is graded, what each level means, and what a reader should do at each one. That order is backwards. A scale is a system decision; a badge is its expression. Building the expression first meant the strongest idea in the redesign rests on a foundation I had not yet defined, and it is the reason the recommendation to grade severity ended up in the client’s column rather than being settled in mine before the component existed.
What I carry forward is to define the model first and let the component fall out of it, rather than designing a good element and reasoning backwards toward the rule it should have followed. The same discipline applies to the wider project: I identified ranking as the problem through heuristic review, which was enough to act on, but a hierarchy that decides what a reader sees first deserves to be tested with readers before it is built on.
Ranking information is a design decision. Declining to rank it is also a decision — it just moves the work to the user.
