[ ← All work ]Case study 05 / 05

Action Clarity

Dense screens looked like the problem, but the real one was that nothing said what to do next. Clarity here comes from structure, not subtraction.

Read the full case study(opens in a new tab)

This case study
product redesign · design direction, not launched
Role / Scope / Year
Product Designer · Insurance management platform · 2025

This was a redesign phase, not a launch, so no launch metrics are claimed; what follows is design intent and the ways I would test it.

01

Context

Action Clarity is an insurance management platform for the people who sell and manage insurance. It pulled customer data, policies, opportunities, order workflows, insurance products, team management, and wallet activity into one place, and the business wanted it to serve everyone involved in a sale. That ambition is worth naming, because a product built to support everyone can turn unclear for the people using it every day.

At first the trouble read as information overload. The screens were dense, so the obvious move was to strip them back and make them cleaner. That was the diagnosis to move past. Removing information was not the answer, because agents still needed enough context to act, and a thinner screen would have taken away the detail the job depends on. The real defect was that among all those objects, nothing showed what deserved attention first.

02

The reframe

The question shifted from how to make dense screens cleaner to how to help an agent know what matters and what to do next.

The complexity was not the amount of information. It was the gap between information and action.

Dense screens were a symptom. Closing the gap meant designing so each screen ends in a decision instead of another read, which is a structural problem, not a matter of showing less.

03

The system

One hierarchy answers that gap, and it governs every screen in the platform. Each screen resolves the same six questions in the same order, and that order is the layout itself. First context, what am I looking at. Then current state, what state is it in. Then priority, does it need attention. Then the next action, what should I do next. Then the key information I need before acting, and last the secondary detail that can wait.

Fixing the order means an agent never has to reconstruct it. Whether the screen is a customer, an opportunity, an order, or the home page, the decision surfaces before the detail that supports it, and the detail is there when the decision needs backing up. Nothing is deleted to achieve this. The density stays, but it is sequenced. A dense screen is legible when its parts arrive in the order a person would ask for them, and illegible when they arrive all at once.

This is why the work was structural rather than cosmetic. The same skeleton repeats across every module, so an agent learns it once and reads every screen faster for it.

Hierarchy · six questions in order, and the order is the layout

01Contextwhat am I looking at
02Current statewhat state is it in
03Prioritydoes it need attention
04Next actionwhat should I do next
05Key informationwhat I need before acting
06Secondarywhat can wait
composed into →the same six-step order on every screen, decision before detail
04

Principles

Six rules hold the hierarchy in place.

  1. Prioritize relevance over completeness. Show what the current task needs first, since users rarely need everything at once.

  2. Separate status from priority. State says where something is, priority says whether it needs attention, and the two never collapse into one label.

  3. Surface the next action. A screen should do more than describe a state.

  4. Preserve context. Agents move between customers, opportunities, policies, and orders, and the system keeps them oriented.

  5. Use controlled density. The product cannot be too minimal, so the goal is to structure complexity, not hide it.

  6. Make product cards decision-oriented. A plan says who it is for, why it fits, what it requires, and how to start, instead of sitting there as a tile.

05

The modules

The hierarchy shows up screen by screen, the same skeleton wearing a different job. There is no fabricated before-and-after here; the comparison is structural, from information spread across modules with status and priority collapsed together, to an action-first order where the two stay separate and blockers come first.

The Today home screen of the insurance platform, in Persian and right to left: a greeting, four summary cards for policies, orders, customers and products, a list of upcoming renewals with days remaining, and a recent orders list with status chips.
Fig 01 · Today

The home page stops being a launcher and becomes a workbench. It answers one question before anything else: what should I do first, today. Summary cards, renewals with days remaining, and recent orders with their status sit under that answer, so the day opens on a decision rather than a menu.

The customers list, in Persian and right to left: a search field above a table of 248 customers with columns for name, mobile number, national ID, policy count, opportunity count, and an active or lead status chip.
Fig 02 · Customers

The customers list is more than a database. Priority segments and next-follow-up dates sit alongside each record, so the screen surfaces who to contact next, not only who exists.

A customer profile: an identity card with an active-customer badge and new-opportunity and edit buttons, a details panel of phone, national ID and birth date, and a tabbed panel listing active opportunities with progress chips.
Fig 03 · Profile

The customer profile becomes a relationship workspace. The header answers context and a next-action panel answers what to do, and everything below it, opportunities, policies, orders, matched product, and timeline, is arranged so the decision comes before the detail.

An opportunity detail screen: a header with an in-progress chip, an information panel listing customer, category, product of interest and source, and a five step follow-up tracker with the first two steps complete and the third in progress.
Fig 04 · Opportunity

The opportunities screen is a status board. It puts stage and priority in two separate visual languages, so a late-stage opportunity and an urgent one are never read as the same thing.

A dense operational orders table with filter chips counting each state. The top two rows are highlighted as blocked, naming the blocker and offering a fix action, while the rows below show a dash in the blocker column.
Fig 05 · Orders

The orders screen is where controlled density earns its place. It stays a dense operational table but leads with the orders that need intervention, naming the blocker and offering the fix, so an agent sees what is moving, what is stuck, and what needs a hand.

Step one of a ten step add-order flow: a progress bar, a numbered current step for plate details with two required fields, and a persistent order summary panel listing vehicle, plate, insurer, premium and progress.
Fig 06 · Add order

The add-order flow is rebuilt as guided completion instead of a long administrative form. Required fields come first, optional fields are separated, a stepper explains each step, and an order summary stays visible so the agent never loses the thread.

06

Tradeoffs

RejectedStrip the screens back to minimalCleaner at a glance, but it removes the operational detail the job depends on.
ChosenControlled density, complexity sequenced not hiddenHarder to keep calm, but agents keep the context they need to act.

Every principle here is a balance held on purpose. The central one is density: the product cannot go minimal without stripping the detail agents act on, so clarity had to come from sequencing the complexity, not deleting it.

Three smaller trades follow the same logic. Flexibility gave way to consistency, so reusable components bend to each screen’s workflow without breaking the pattern. Product selling gave way to operational calm, so product cards are allowed to stand out while the platform stays a workspace and not a marketplace. And status visibility gave way to freedom from alert fatigue, because if every state looks urgent none of them are, so priority is spent carefully and the signals that do appear keep their weight.

07

Validate next

No usability results are claimed. These are the questions I would put in front of real agents, and the signals I would watch while they worked.

  • Whether agents can identify the next action faster than they can on the current screens.
  • Whether they read status as separate from priority, or still conflate the two.
  • Whether blocked orders become easier to resolve, and whether product recommendations help rather than distract.
  • Whether the add-order flow reduces uncertainty, and the home page actually helps an agent start the day.
  • What to measure: time to the next action, add-order completion and error rate in required fields, follow-up and blocked-order resolution, and self-reported confidence and clarity.
08

Reflection

The shift that mattered was recognizing that clarity is not the same as simplicity. In a product this dense, removing information creates new problems, so the harder and better question was what deserves attention first, and what should support that decision rather than crowd it. Answering it screen after screen is what turned the work from arranging layouts into designing a system for action. The screens are downstream of that decision, which is why the hierarchy, not any single screen, is the part worth showing.