实习日志 / English / UI Refactoring / Giving the claims interface a persona: an oatmeal turtleneck and a good watch

Giving the claims interface a persona: an oatmeal turtleneck and a good watch

中文 | English

When I redid the claimant interface in early September, I had a very concrete problem: there was nothing to base a judgement on for what this interface should look like.

The old version was an entry page with a white background and a green gradient, three claim-type cards below it, and a step-by-step form behind them. It looked like an insurer's website, or any SaaS landing page. The trouble was that whenever we discussed changing a colour or a button, people could only say "looks good" or "doesn't", and nobody could convince anyone else.

Find a person first

The turning point came from an observation an industry mentor shared: what users really trust is a professional private client manager who looks at things from their side; the words "insurance company" cannot give that trust on their own. This person is calm without being stern, has style without showing off, is reliable without fawning, has seen a lot and still never puts you under pressure.

That sentence was about product positioning, and I took it directly as the starting point for the visuals. The interface should feel like this person.

Adjectives alone were not concrete enough, so I dressed the person: an oatmeal turtleneck sweater with an inconspicuous but very good watch. Warm and understated overall, with taste in the details. From then on every visual choice could be tested with one question: would that person wear this?

A colour system from a sweater

The first decision was the background. The default cold white of screens is a tech-product choice, and so is office white. But the person opening this interface has just had an accident, and the first thing they see should not be cold. So the background became oatmeal white #F7F4EF, like the colour of good paper. The sidebar and panels go a step darker on the same warm hue, and areas are separated by tone, not borders. Text uses a warm charcoal with a yellow cast, because cold grey on a warm background looks dirty.

Each of the three background levels is about 7% to 8% darker in lightness than the one before, with no new hue. Text has three layers, spaced far enough apart that no two greys look "about the same".

The second decision was the accent colour, and it took the longest. Almost the whole insurance industry uses blue or green: blue for trust, green for safety. Because everyone uses them, neither colour is distinctive any more; they just look like a template. I asked a different question: which colour does nobody in this industry use, yet carries the right feeling? The answer was sage green, a desaturated, slightly grey green. It is calm, alive and quiet, the kind of colour that feels comfortable to see in a quiet room.

The anchor is #5F8F80, with a scale pushed out in both directions. Lighter steps lean slightly yellow and darker steps lean slightly blue, which gives the scale warmth and looks more natural than mechanically adding white or black:

The only extra semantic colour is an error red, #B83228, a restrained red. "Confirmed" reuses sage green instead of adding a separate success green, so the palette does not fragment over time.

As soon as the choice was made, a new risk appeared. Oatmeal plus sage slides easily into holiday style: lazy, relaxed, like a guesthouse. But the client manager is at work. So green is rationed: it appears only where it has a clear function, the line to the left of Agent messages, the send button, fields noted this turn, and the ring around a focused input. Everything else is carried by warm charcoal and oatmeal white. With very little colour, each appearance has a reason, and that is where the distinctiveness comes from.

Type: nearly giving the Agent a different voice

For a while I wanted Agent messages in a serif face, so you could tell at a glance who was speaking. I dropped it after trying. A serif brings a bookish air; it reads like someone writing you a letter. In this setting, the user needs to feel that someone is seriously handling their case. In the end the whole site uses only Inter, a sans-serif, and Agent messages are one size larger than the user's (17px against 16px). Size is enough to tell the speakers apart.

Sizes and weights follow the same idea. The smallest readable size is 14px; anything smaller is only for badge text:

For weight, body text is 400, navigation and labels 500, headings and the send button 600. The table has one exception at each end: 11px only for badge text and the vertical expand label on the collapsed right panel, and 18px kept in reserve.

In the end a serif appears in exactly one place on the site: the illustration on the entry page. The plan for it follows the photo-abstract-editorial approach, turning a real photo into an editorial piece with the original photo on top and an abstract colour-block panel below, with a line of English title on the panel set in Source Serif 4. Its colours must also come only from the token tables above, with no other hue. One serif inside an illustration is an accent; put into the conversation, it becomes the Agent's voice. I drew that line very clearly. Until the photo is ready, the hero area holds an inline SVG with three geometric blocks as a placeholder.

The more important the control, the squarer it is

The remaining rules come from the same image.

Corner radii are small overall, never more than 10px. The rounder something is, the more it looks like a consumer product; the squarer, the more it looks like a tool, and this interface is a tool. Toolbar buttons are 4px, quick-reply buttons 6px, the send button, input and user bubble 8px, and the hover background of list items 10px. There are no pill-shaped buttons anywhere.

Shadows are almost never used; layering comes from background tone. There is exactly one shadow on the whole site, the glow around a focused input:

box-shadow: 0 0 0 3px var(--sage-tint);

Borders come in two weights. Boundaries between regions are 2px, borders inside components are 1.5px, never 1px, because 1px looks too thin on high-density screens and does not feel solid:

All spacing is a multiple of 4, from 4px to 40px. Messages are 28px apart, and the conversation area has 36px (top) and 40px (left and right) of padding on desktop.

States speak quietly too. A field not yet filled is italic in pale --t-faint, not red; the user is tense enough already, and the interface should not add to it. A field noted this turn should be seen at once: the field name turns --sage-deep, the value goes to weight 500, and a new badge is attached. Only fields added or changed this turn are marked, not earlier ones; otherwise the screen fills with green and the marker loses its meaning.

A three-column workspace

Once the conversation starts, the interface becomes a workspace. On desktop it is a three-column grid, switching to a mobile layout at 768px:

The middle column is the main visual and the only main entry. The right panel lets users check and correct what the system noted at any time, without competing with the conversation for attention. On a phone there is no room for three columns side by side, so the noted information goes back into the conversation itself, and users never have to leave the message they are reading to look elsewhere.

A few component rules exist to keep the persona believable. Agent messages have no bubble and no avatar, only a 2px sage line on the left and a small Claims assistant label; they read like something being carefully written down. User messages sit on the right in bubbles on the --bg-sidebar tone. The traditional web form and "talk to a person" entries are kept as 14px text links in --t-muted with a light underline, sitting quietly in the secondary navigation. Users can find them, but they do not compete with the Agent as the main entry. Scrollbars are hidden globally.

The entry page does only three things

With this language in place, the entry page was easy to design. Its job is plain: let users in, let them recognise a report they did not finish last time, and let them find the login. So there are no feature cards, no "claim in three steps" diagram, and no claim-type selection cards. There is one input in the middle with the hint Tell us what happened, and above it the brand line Understand insurance. Understand you better. I kept the two apart on purpose: the brand line is an attitude and the input hint is an action; merged into one long piece of copy, both get weaker. The entry page adds no new tokens and reuses the system above.

Signed-in users skip this page and go straight to the workspace. The page serves only people who are not signed in, and it has four states:

When the user types and presses Enter, the input slides smoothly from the centre to the bottom of the page, as on the Claude and ChatGPT web apps, the page becomes the workspace, and the Agent sends the first opening message. Users who are not signed in can chat normally in the workspace and the right field panel works as usual; the conversation history column on the left becomes a placeholder with a lock icon, saying history is available after signing in.

How it works is not a separate onboarding link either; it reuses the position of the hint next to the input. Clicked before a report has started, it opens the tutorial page directly; clicked inside the workspace, it makes the Agent send an explanatory message ending with See more →, which links to the same tutorial page.

Behind this is a division of labour:

The page handles only static, structural things; guiding words are left to the Agent in the conversation. The reason is still the persona: what greets you should be a person listening carefully, and marketing copy cannot stand in for that person.

The summary card has three actions: continue, sign in to save, and start a new claim. I did not make "start again" weak. Many products like to turn the option they would rather you not click into small grey text, but in front of someone who has just had an accident, any design that makes them wonder "did I click the wrong thing?" is unnecessary pressure.

What the visual draft and the backend contract each own

The design first existed as a static HTML sketch. When it was carried over into the repository's front end, I set a boundary: visual structure, layout, spacing and tone follow the sketch; business behaviour, fields, states, permissions and API calls follow the repository's existing code, specs and backend contracts without exception.

I drew the line because what a sketch can draw, the backend may not support. The sketch's input bar, for example, had buttons for files, voice and accessibility, and some of them had no backend capability yet. Such controls may appear in the interface, but they must be clearly marked as unavailable, with the reason. Passing off a static demo effect as an implemented feature is not allowed. The visual draft owns "what it should look like", the contract owns "what it can really do now", and when the two conflict, the interface must honestly reflect the latter.

Later

The spec later moved into code as the front end's shared token file, and some values were adjusted during implementation; the green, for instance, became a little lighter. But the way of discussing never changed. When someone proposes adding a colour, an animation or a card, the question people now ask is a different one: would the client manager in the oatmeal sweater do this?

That is the biggest use of giving an interface a persona. It lets every visual decision give its reasons, and it gives the team a shared reference when they argue.